Vantaggi delle prestazioni

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Introduzione: cause e mitigazioni della latenza DNS

Man mano che le pagine web diventano più complesse, facendo riferimento a risorse utilizzate da numerosi domini, le ricerche DNS possono diventare un collo di bottiglia significativo nell'esperienza di navigazione. Ogni volta che un client deve eseguire una query su un resolver DNS sulla rete, la latenza introdotta può essere significativa a seconda della vicinanza e del numero di server dei nomi su cui il resolver deve eseguire query (più di due sono rari, ma possono verificarsi). Ad esempio, il seguente screenshot mostra i tempi segnalati dallo strumento di misurazione delle prestazioni web Velocità della pagina. Ogni barra rappresenta una risorsa a cui viene fatto riferimento nella pagina; i segmenti neri indicano le ricerche DNS. In questa pagina vengono eseguite 13 ricerche nei primi 11 secondi in cui viene caricata la pagina. Sebbene diverse ricerche vengano eseguite in parallelo, lo screenshot mostra che sono necessari cinque tempi di ricerca seriale, tenendo conto di diversi secondi dei tempi di caricamento totali della pagina di 11 secondi.

La latenza DNS è composta da due componenti:

  • La latenza tra il client (utente) e il server di risoluzione DNS. Nella maggior parte dei casi, questo è principalmente dovuto ai vincoli di tempo di round trip (RTT) nei sistemi in rete: distanza geografica tra le macchine client e server; congestione di rete; perdita di pacchetti e lunghi ritardi di ritrasmissione (un secondo in media); server sovraccarichi, attacchi denial of service e così via.
  • Latenza tra i server di risoluzione e altri server dei nomi. Questa origine della latenza è causata principalmente dai seguenti fattori:
    • Errori della cache. Se una risposta non può essere fornita dalla cache del resolver, ma richiede query ricorrenti su altri server dei nomi, la latenza di rete aggiunta è considerevole, soprattutto se i server autorevoli sono geograficamente remoti.
    • Sottoprovisioning. Se i resolver DNS sono sovraccarico, devono mettere in coda le richieste e le risposte DNS per la risoluzione e possono iniziare a eliminare e ritrasmettere i pacchetti.
    • Traffico dannoso. Anche se il provisioning di un servizio DNS viene eseguito in eccesso, il traffico DoS può comunque causare un carico indebito sui server. Allo stesso modo, gli attacchi in stile Kaminsky possono includere resolver inondazione con query che possono garantire di aggirare la cache e di richiedere richieste di risoluzione in uscita.

Riteniamo che il fattore di perdita della cache sia la causa più dominante della latenza DNS e discuti ulteriormente di seguito.

Errori della cache

Anche se un resolver ha grandi risorse locali, i ritardi fondamentali associati alla comunicazione con i server dei nomi remoti sono difficili da evitare. In altre parole, supponendo che il resolver venga eseguito un provisioning sufficientemente corretto in modo che i successi della cache non richiedano alcun tempo sul lato server, i fallimenti della cache restano molto costosi in termini di latenza. Per gestire una mancanza, un resolver deve parlare con almeno uno, ma spesso due o più server dei nomi esterni. Utilizzando il web crawler Googlebot, abbiamo osservato un tempo medio di risoluzione di 130 ms per i server dei nomi che rispondono. Tuttavia, il 4-6% di richieste scade semplicemente a causa di una perdita di pacchetti UDP e di server non raggiungibili. Se prendiamo in considerazione errori come la perdita di pacchetti, i server dei nomi non funzionanti, gli errori di configurazione DNS e così via, il tempo medio per la risoluzione end-to-end effettiva è di 300-400 ms. Tuttavia, la latenza è elevata e la coda lunga.

Anche se il tasso di errore della cache può variare a seconda dei server DNS, è difficile evitarlo per i seguenti motivi:

  • Dimensioni e crescita di Internet. In sostanza, con la crescita di Internet, sia mediante l'aggiunta di nuovi utenti sia mediante la creazione di nuovi siti, la maggior parte dei contenuti presenta un interesse marginale. Sebbene alcuni siti (e di conseguenza i nomi DNS) siano molto popolari, la maggior parte di essi sono interessanti solo per pochi utenti e sono accessibili di rado, pertanto la maggior parte delle richieste genera errori della cache.
  • Valori della durata (TTL) bassi. La tendenza verso valori TTL DNS più bassi significa che le risoluzioni richiedono ricerche più frequenti.
  • Isolamento della cache. In genere, i server DNS vengono implementati dietro bilanciatori del carico che assegnano le query a macchine diverse in modo casuale. In questo modo, ogni singolo server mantiene una cache separata anziché essere in grado di riutilizzare le risoluzioni memorizzate nella cache da un pool condiviso.

Mitigazioni

In Google Public DNS, abbiamo implementato diversi approcci per velocizzare i tempi di ricerca DNS. Alcuni di questi approcci sono abbastanza standard, altri sono sperimentali:

Provisioning adeguato dei cluster di pubblicazione

I resolver DNS di memorizzazione nella cache devono eseguire operazioni più costose rispetto ai server dei nomi autoritativi, poiché molte risposte non possono essere pubblicate dalla memoria. Richiedono invece di comunicare con altri server dei nomi e quindi richiedono una grande quantità di input/output di rete. Inoltre, i resolver aperti sono altamente vulnerabili ai tentativi di avvelenamento della cache, che aumentano il tasso di errore della cache (questi attacchi inviano in modo specifico richieste di nomi fasulli che non possono essere risolti dalla cache) e ad attacchi DoS, che si aggiungono al carico del traffico. Se i resolver non vengono forniti correttamente e non riescono a tenere il passo con il carico, questo può avere un impatto molto negativo sulle prestazioni. I pacchetti vengono ignorati e devono essere ritrasmessi, le richieste dei server dei nomi devono essere messe in coda e così via. Tutti questi fattori incidono su ritardi.

Pertanto, è importante eseguire il provisioning dei resolver DNS per l'input/output ad alto volume. Questo include la gestione di possibili attacchi DDoS, per i quali l'unica soluzione efficace è l'over-provisioning con molte macchine. Allo stesso tempo, tuttavia, è importante non ridurre il tasso di successo della cache quando si aggiungono macchine; ciò richiede l'implementazione di un efficace criterio di bilanciamento del carico, di cui parleremo di seguito.

Bilanciamento del carico per la memorizzazione nella cache condivisa

La scalabilità dell'infrastruttura del resolver aggiungendo macchine può effettivamente eseguire il backfire e ridurre la percentuale di successo della cache se il bilanciamento del carico non viene eseguito correttamente. In un deployment tipico, più macchine si trovano dietro un bilanciatore del carico che distribuisce equamente il traffico a ciascuna macchina, utilizzando un semplice algoritmo come il round robin. Il risultato è che ogni macchina mantiene una propria cache indipendente, in modo che i contenuti memorizzati nella cache vengano isolati tra le varie macchine. Se ogni query in entrata viene distribuita a una macchina casuale, a seconda della natura del traffico, il tasso di successo della cache effettiva può essere aumentato in modo proporzionale. Ad esempio, per i nomi con TTL lunghi che vengono cercati ripetutamente, il tasso di errore della cache può essere aumentato del numero di macchine nel cluster. Per i nomi con TTL molto brevi, che vengono sottoposti a query molto raramente o che generano risposte non memorizzabili nella cache (0 TTL ed errori), il tasso di errore della cache non è davvero influenzato dall'aggiunta di macchine.

Per aumentare la percentuale di hit per i nomi memorizzabili nella cache, è importante che i server bilanciano il carico in modo che la cache non sia frammentata. In Google Public DNS abbiamo due livelli di memorizzazione nella cache. In un pool di macchine, molto vicino all'utente, una piccola cache per ogni macchina contiene i nomi più popolari. Se una query non può essere soddisfatta da questa cache, viene inviata a un altro pool di macchine che esegue la partizione della cache per nome. Per questa cache di secondo livello, tutte le query per lo stesso nome vengono inviate alla stessa macchina, dove il nome viene memorizzato nella cache oppure non lo è.

Distribuzione di cluster di pubblicazione per un'ampia copertura geografica

Per i risolutori chiusi, questo non è un problema reale. Per i resolver aperti, più i server sono vicini ai tuoi utenti, minore sarà la latenza che vedranno all'estremità del client. Inoltre, avere una copertura geografica sufficiente può migliorare indirettamente la latenza end-to-end, dato che i server dei nomi in genere restituiscono risultati ottimizzati per la località del resolver DNS. In altre parole, se un provider di contenuti ospita siti con mirroring in tutto il mondo, i server dei nomi di quel provider restituiranno l'indirizzo IP nelle vicinanze del resolver DNS.

Google Public DNS è ospitato nei data center di tutto il mondo e utilizza il routing anycast per indirizzare gli utenti al data center geograficamente più vicino.

Inoltre, Google Public DNS supporta la subclient client (ESS), un'estensione del protocollo DNS che consente ai resolver di inoltrare la posizione del client ai server dei nomi, che può restituire risposte sensibili alla posizione ottimizzate per l'indirizzo IP client effettivo, anziché l'indirizzo IP del resolver. Per informazioni dettagliate, leggi queste domande frequenti. Google Public DNS rileva automaticamente i server dei nomi che supportano la subnet client EDNS.