Perché la latenza DNS fa sembrare lenta un'app per server domestico su una LAN?

Un’app server domestica può sembrare lenta su una LAN veloce perché il client potrebbe dover risolvere il suo nome host prima di poter avviare una nuova connessione. Se quella ricerca attende una cache vuota, un resolver non disponibile o un percorso di fallback, la pausa avviene prima che l’app abbia la possibilità di rispondere.

Questo non significa che il DNS venga eseguito prima di ogni richiesta HTTP o riduca la velocità di una connessione stabilita. Il DNS è più visibile quando un client ha bisogno di un nuovo risultato di indirizzo o di una nuova connessione, motivo per cui il primo caricamento può sembrare lento mentre la navigazione successiva appare normale.

La latenza DNS ritarda l’avvio della connessione, non ogni richiesta dell’app

Quando un browser o un client apre un nome host, il suo resolver deve restituire un indirizzo che lo stack di rete può usare. Il modello di resolver DNS consente che la risposta provenga da informazioni in cache o da uno o più server dei nomi, quindi il tempo di ricerca può variare anche quando il server di destinazione non cambia mai.

Una volta che un indirizzo e una connessione sono disponibili, le richieste successive possono riutilizzarli. HTTP/2, per esempio, associa gli scambi di richiesta e risposta a stream indipendenti su una connessione; questo multiplexing degli stream HTTP/2 è una delle ragioni per cui molte risorse non richiedono ciascuna una nuova connessione e una nuova ricerca DNS.

Una LAN rende più facile notare il contrasto. Il trasferimento del payload e i round trip del server possono essere brevi, mentre un ritentativo o fallback del resolver rimane un’attesa separata davanti a loro. L’utente percepisce il tempo combinato e può incolpare l’app, lo storage o la rete anche se il ritardo è avvenuto prima che il traffico dell’applicazione iniziasse.

Come viene risolto un nome host di un server domestico su una LAN

Cache del browser e del sistema operativo

Il client potrebbe già avere un risultato di indirizzo utilizzabile. Un colpo in cache può eliminare la necessità di uno scambio DNS in rete, mentre una voce scaduta o assente invia la richiesta più avanti nel percorso di risoluzione. Le cache del browser, del sistema operativo e del resolver ricorsivo sono livelli separati, quindi il loro stato non cambia sempre contemporaneamente.

Il resolver LAN configurato

Quando i dati della cache locale non sono disponibili, un client solitamente interroga un resolver configurato, che può essere un router, un servizio DNS locale dedicato o un altro resolver ricorsivo. Quel resolver può rispondere da una zona locale autorevole, rispondere dalla propria cache o inoltrare la query altrove. Il fatto che il server sia sulla LAN non garantisce che ogni resolver coinvolto sia altrettanto vicino o funzionante.

Domini di ricerca, mDNS e percorsi di fallback

Gli hostname brevi e i nomi che terminano con .local possono seguire meccanismi diversi. Le regole multicast DNS per i nomi .local indirizzano quelle query al multicast link-local, mentre le implementazioni possono anche usare altri meccanismi contemporaneamente. I suffissi di ricerca e il comportamento di fallback possono quindi aggiungere tentativi che le descrizioni DNS unicast ordinarie non catturano.

Cache miss e timeout del resolver producono pause diverse

Un cache miss non è automaticamente un errore. Significa che la risposta deve essere ottenuta da un'altra fonte, quindi la prima ricerca può richiedere più tempo di una ricerca in cache. Un timeout è diverso: il resolver non ha ricevuto una risposta utile entro il periodo di attesa e può ritentare con un altro server o trasporto.

Le attuali linee guida su fallimenti e ritentativi DNS distinguono tra fallimenti, server irraggiungibili, ritentativi e fallimenti memorizzati nella cache. Notano anche che domande identiche in sospeso possono essere combinate anziché emesse come query indipendenti a monte, motivo per cui i ritardi DNS non dovrebbero essere moltiplicati meccanicamente per il numero di risorse dell'app.

Il modello visibile è spesso più informativo di una singola media. Un ritardo costantemente piccolo al primo caricamento, un ritardo da cache fredda e una pausa lunga irregolare indicano stati diversi e non dovrebbero essere raggruppati sotto un'unica etichetta generica di “DNS lento”.

Una schermata dell'app può coinvolgere diversi hostname

Una dashboard locale può caricare il suo documento principale da un hostname mentre contatta altri nomi per un'API, un endpoint WebSocket, un servizio di identità, un plugin, un font, un'immagine di copertina o un controllo aggiornamenti. Solo l'app principale deve essere locale affinché lo schermo appaia locale; il suo grafo di dipendenze può comunque attraversare diverse origini.

Ogni nuova origine può creare un'altra opportunità di risoluzione e connessione, ma i ritardi non si sommano necessariamente in linea retta. I browser possono eseguire lavori contemporaneamente, i resolver possono memorizzare nella cache o combinare domande corrispondenti, e più risorse della stessa origine possono condividere una connessione.

La domanda pratica quindi non è “Quanti file ci sono nella pagina?” ma “Quanti nomi distinti e nuovi percorsi di connessione sono necessari prima che l'interfaccia diventi utilizzabile?” Una piccola ma bloccante dipendenza API può contare più di molte immagini caricate successivamente in parallelo.

Perché il primo caricamento può essere lento ma gli aggiornamenti sembrano veloci

La prima visita può includere una ricerca DNS, una nuova connessione TCP, una stretta di mano TLS, l'autenticazione e il lavoro iniziale dell'applicazione. Un aggiornamento può beneficiare contemporaneamente di cache degli indirizzi, connessioni esistenti, voci di cache HTTP e dati applicativi riscaldati.

Questo rende un aggiornamento più veloce un indizio utile, non la prova che il DNS sia stata l'unica causa. Per isolare il DNS, la fase di ricerca deve essere separata dall'instaurazione della connessione e dalla risposta del server invece di trattare l'intera differenza del primo caricamento come tempo del resolver.

La posizione del resolver è più importante quando il nome è locale

Un nome host interno necessita di un meccanismo di risoluzione che comprenda il suo namespace. Una zona autorevole locale, una configurazione split DNS o un nome mDNS possono mantenere la risposta associata alla LAN, mentre un resolver pubblico generale potrebbe non avere alcun record per quel nome interno.

Questo non significa che ogni nome host locale inviato a un resolver esterno faccia un viaggio lento e alla fine abbia successo. A seconda del nome e della configurazione, il risultato può essere una risposta negativa immediata, un nuovo tentativo o un fallback a un altro meccanismo. La posizione del resolver è importante perché cambia quale sistema può rispondere correttamente, non semplicemente perché un server è fisicamente più vicino.

Il DNS non è l'unica causa di una prima risposta lenta

L'avvio dell'applicazione, le query al database, l'I/O di archiviazione, il routing del reverse proxy, l'autenticazione e TLS possono tutti ritardare la prima risposta visibile dopo che la risoluzione del nome è terminata. Se il nome host e un test controllato basato sull'indirizzo sono ugualmente lenti, il collo di bottiglia è meno probabilmente il DNS.

Un confronto basato sull'indirizzo ha anche dei limiti. I certificati HTTPS e l'hosting virtuale dipendono dai nomi, e un reverse proxy può indirizzare lo stesso IP a diverse applicazioni in base al nome host richiesto. Un test basato sull'indirizzo fallito o con comportamento diverso non è un benchmark DNS pulito.

Usa con attenzione il confine dei sintomi: il DNS è plausibile quando i ritardi si concentrano attorno all'uso di nomi non memorizzati nella cache, al fallimento del resolver o a nuovi percorsi di connessione. È meno plausibile quando il tempo di ricerca è trascurabile ma il tempo al primo byte rimane alto.

Separare il tempo DNS dal tempo TCP, TLS e dell'applicazione

La catena di latenza utile è la ricerca DNS, la configurazione della connessione, la configurazione della connessione sicura quando applicabile, l'inizio della richiesta, l'inizio della risposta e il trasferimento del contenuto. Il modello di fase Navigation Timing del W3C espone timestamp separati per la ricerca del dominio e la connessione, incluso il caso in cui le informazioni sul dominio provengano dalla cache.

Per le singole risorse di pagina, l'interfaccia Resource Timing separa le fasi di lookup, connessione, richiesta e risposta. Le regole di privacy cross-origin possono nascondere alcuni dettagli, quindi i campi di temporizzazione mancanti non sono automaticamente prova di latenza zero.

Ping e larghezza di banda per copia file rispondono a domande diverse. Ping misura la raggiungibilità e il comportamento del round-trip di rete; un grande trasferimento misura un percorso dati stabilito. Nessuno dei due isola la risoluzione del nome host che può avvenire prima che un'app apra la sua prima connessione.

FAQ

Il DNS influisce su ogni clic all'interno di un'app server domestica?

No. Il DNS è importante quando il client ha bisogno di risolvere un nome per un risultato nuovo o scaduto. Indirizzi memorizzati nella cache, connessioni persistenti e richieste multiplexate possono permettere a molte interazioni di procedere senza una nuova query DNS di rete.

Perché l'app si carica più velocemente tramite indirizzo IP che tramite nome host?

Bypassare il nome host può rimuovere la risoluzione dei nomi da quel percorso di test, quindi la differenza può indicare il DNS. Non è conclusivo perché certificati, host virtuali, reindirizzamenti e regole di reverse-proxy possono far comportare diversamente il percorso dell'indirizzo.

mDNS può essere più lento del DNS locale normale?

Può comportarsi diversamente perché utilizza multicast link-local e può coesistere con altri meccanismi di ricerca. Se è più lento dipende dal client, dalla rete, dal nome, dalla cache e dal comportamento di fallback, non da una penalità universale di mDNS.

Cambiare il DNS pubblico velocizzerà la risoluzione dei nomi di un server domestico locale?

Solo se quel resolver pubblico fa effettivamente parte del percorso di successo o di errore. Un nome mantenuto in una zona locale o risolto tramite mDNS necessita del meccanismo locale appropriato; cambiare un resolver pubblico non correlato potrebbe non fare nulla.

Perché l'app diventa di nuovo lenta dopo un riavvio o un lungo periodo di inattività?

Un riavvio o un lungo periodo di inattività possono rimuovere i dati degli indirizzi memorizzati nella cache e chiudere le connessioni riutilizzabili, mentre l'app stessa può perdere le cache riscaldate. Il caricamento successivo può quindi ripetere diverse fasi di avvio, non solo il DNS.

Il DNS modifica il tempo di avvio dell'app, non la larghezza di banda del NAS domestico

La risoluzione dei nomi a bassa latenza e affidabile può rendere le prime connessioni e le nuove dipendenze delle app più reattive, ma non aumenta la velocità del disco né la larghezza di banda di un trasferimento LAN già avviato. Diagnostica il DNS nel suo contesto prima dell'inizio della connessione, quindi misura separatamente la risposta TCP, TLS e dell'applicazione prima di incolpare il server domestico.