Cette page a été traduite par l'API Cloud Translation.

Avantages liés aux performances

Introduction: causes et mesures d'atténuation de la latence DNS

À mesure que les pages Web deviennent plus complexes et référencent des ressources provenant de nombreux domaines, les résolutions DNS peuvent constituer un goulot d'étranglement important pour l'expérience de navigation. Chaque fois qu'un client doit interroger un résolveur DNS sur le réseau, la latence peut être importante, en fonction de la proximité et du nombre de serveurs de noms qu'il doit interroger (plus de deux solutions sont rares, mais cela peut arriver). À titre d'exemple, la capture d'écran suivante présente les temps enregistrés par l'outil de mesure des performances Web Page Speed. Chaque barre représente une ressource référencée depuis la page. Les segments noirs indiquent les résolutions DNS. Sur cette page, 13 recherches sont effectuées au cours des 11 premières secondes de chargement de la page. Bien que plusieurs recherches soient effectuées en parallèle, la capture d'écran montre que cinq temps de recherche en série sont nécessaires, ce qui représente plusieurs secondes du temps de chargement total de la page (11 secondes).

La latence DNS comporte deux composants:

Latence entre le client (utilisateur) et le serveur de résolution DNS. Dans la plupart des cas, cela est principalement dû aux contraintes habituelles de délai aller-retour (DAR) dans les systèmes en réseau: distance géographique entre les machines clientes et de serveurs, congestion du réseau, perte de paquets et retards de retransmission longs (une seconde en moyenne), serveurs surchargés, attaques par déni de service, etc.
Latence entre les serveurs de résolution et les autres serveurs de noms. Cette source de latence est principalement due aux facteurs suivants :
- Cache manquant. Si une réponse ne peut pas être diffusée à partir d'un cache de résolveur, mais qu'elle nécessite d'interroger de manière récursive d'autres serveurs de noms, la latence réseau supplémentaire est considérable, en particulier si les serveurs faisant autorité sont géographiquement distants.
- Sous-provisionnement. Si les résolveurs DNS sont surchargés, ils doivent mettre en file d'attente les requêtes et les réponses de résolution DNS, et peuvent commencer à supprimer et à retransmettre des paquets.
- Trafic malveillant. Même si un service DNS est surprovisionné, le trafic DoS peut entraîner une charge excessive sur les serveurs. De même, les attaques de style Kaminsky peuvent impliquer des résolveurs d'inondations avec des requêtes garantissant le contournement du cache et nécessitant des requêtes sortantes de résolution.

Nous pensons que le facteur de défaut de cache est la cause la plus dominante de la latence DNS, que nous allons aborder plus en détail ci-dessous.

Cache manquant

Même si un résolveur dispose de nombreuses ressources locales, les retards fondamentaux associés à la communication avec les serveurs de noms distants sont difficiles à éviter. En d'autres termes, en supposant que le résolveur soit provisionné suffisamment bien pour que les succès de cache ne prennent aucun temps côté serveur, les défauts de cache restent très coûteux en termes de latence. Pour résoudre un défaut, un résolveur doit communiquer avec au moins un, mais souvent plusieurs serveurs de noms externes. En exécutant le robot d'exploration Googlebot, nous avons constaté une résolution moyenne de 130 ms pour les serveurs de noms qui répondent. Toutefois, 4 à 6% des requêtes expirent simplement en raison de la perte de paquets UDP et de l'inaccessibilité des serveurs. Si nous prenons en compte les défaillances telles que la perte de paquets, les serveurs de noms morts, les erreurs de configuration DNS, etc., le temps de résolution de bout en bout réel est de 300 à 400 ms. Il existe toutefois une variance élevée et une longue traîne.

Bien que le taux de défauts de cache peut varier selon les serveurs DNS, il est fondamentalement difficile d'éviter ces défauts pour les raisons suivantes:

taille et croissance d'Internet. Tout simplement parce qu'Internet se développe grâce à l'ajout de nouveaux utilisateurs et de nouveaux sites. La plupart des contenus présentent donc un intérêt marginal. Bien que quelques sites (et donc noms DNS) soient très populaires, la plupart présentent un intérêt pour quelques utilisateurs et sont rarement consultés. La majorité des requêtes entraînent donc des défauts de cache.
Valeurs TTL (Time To Live). La tendance à des valeurs TTL DNS inférieures signifie que les résolutions nécessitent des recherches plus fréquentes.
Isolation du cache. Les serveurs DNS sont généralement déployés derrière des équilibreurs de charge qui attribuent des requêtes à différentes machines de manière aléatoire. Ainsi, chaque serveur conserve un cache distinct plutôt que de pouvoir réutiliser les résolutions mises en cache à partir d'un pool partagé.

Atténuation

Dans le DNS public de Google, nous avons implémenté plusieurs approches permettant d'accélérer les recherches DNS. Certaines de ces approches sont assez standards, d'autres sont expérimentales:

Provisionner les serveurs de manière adéquate pour gérer la charge du trafic client, y compris le trafic malveillant
Prévention des attaques DoS et d'amplification Bien qu'il s'agisse principalement d'un problème de sécurité qui affecte moins les résolveurs fermés que les solutions ouvertes, la prévention des attaques DoS offre également un avantage en termes de performances, car elle élimine la charge de trafic supplémentaire imposée aux serveurs DNS. Pour en savoir plus sur les approches que nous utilisons pour réduire les risques d'attaques, consultez la page sur les avantages de sécurité.
Équilibrage de charge pour la mise en cache partagée, afin d'améliorer le taux d'accès au cache agrégé sur l'ensemble du cluster de diffusion.
Couverture mondiale pour la proximité de tous les utilisateurs.

Provisionner les clusters de diffusion de manière adéquate

Les résolveurs DNS de mise en cache doivent effectuer des opérations plus coûteuses que les serveurs de noms faisant autorité, car de nombreuses réponses ne peuvent pas être diffusées depuis la mémoire. À la place, elles nécessitent une communication avec d'autres serveurs de noms et nécessitent donc beaucoup d'entrées/sorties réseau. De plus, les résolveurs ouverts sont très vulnérables aux tentatives d'empoisonnement du cache, qui augmentent le taux d'échec du cache (de telles attaques envoient spécifiquement des requêtes de faux noms qui ne peuvent pas être résolus à partir du cache) et aux attaques DoS, qui alourdit la charge de trafic. Si les résolveurs ne sont pas provisionnés de manière adéquate et ne peuvent pas suivre la charge, cela peut avoir un impact très négatif sur les performances. Les paquets sont supprimés et doivent être retransmis, les requêtes de serveur de noms doivent être mises en file d'attente, etc. Tous ces facteurs augmentent les retards.

Par conséquent, il est important que les résolveurs DNS soient provisionnés pour les entrées/sorties volumineuses. Cela inclut la gestion des éventuelles attaques DDoS, pour lesquelles la seule solution efficace consiste à surprovisionner plusieurs machines. Toutefois, il est important de ne pas réduire le taux de succès de cache lorsque vous ajoutez des machines. Vous devez pour cela mettre en œuvre une stratégie d'équilibrage de charge efficace, que nous aborderons ci-dessous.

Équilibrage de charge pour la mise en cache partagée

Le scaling de l'infrastructure du résolveur en ajoutant des machines peut en réalité se déclencher et réduire le taux de succès de cache si l'équilibrage de charge n'est pas effectué correctement. Dans un déploiement classique, plusieurs machines sont placées derrière un équilibreur de charge qui répartit équitablement le trafic entre elles, à l'aide d'un algorithme simple tel que l'interrogation à répétition alternée. En conséquence, chaque machine gère son propre cache indépendant, de sorte que le contenu mis en cache est isolé. Si chaque requête entrante est distribuée sur une machine aléatoire, en fonction de la nature du trafic, le taux de défaut de cache effectif peut être augmenté proportionnellement. Par exemple, pour les noms comportant des valeurs TTL longues qui sont interrogées à plusieurs reprises, le taux d'échec du cache peut être augmenté par le nombre de machines dans le cluster. (Pour les noms comportant des valeurs TTL très courtes, qui sont interrogées très rarement ou qui entraînent des réponses ne pouvant pas être mises en cache (0 valeur TTL et erreurs), le taux de défauts de cache n'est pas réellement affecté par l'ajout de machines.

Pour améliorer le taux de succès des noms pouvant être mis en cache, il est important d'équilibrer la charge des serveurs pour que le cache ne soit pas fragmenté. Le DNS public de Google comporte deux niveaux de mise en cache. Dans un pool de machines, très proche de l'utilisateur, un petit cache par machine contient les noms les plus populaires. Si une requête ne peut pas être satisfaite à partir de ce cache, elle est envoyée à un autre pool de machines qui partitionnent le cache par noms. Pour ce cache de deuxième niveau, toutes les requêtes portant le même nom sont envoyées à la même machine, où le nom est mis en cache ou il n'est pas mis en cache.

Distribuer des clusters d'inférence pour une couverture géographique étendue

Pour les résolveurs fermés, il ne s'agit pas vraiment d'un problème. Pour les résolveurs ouverts, plus vos serveurs se trouvent à proximité de vos utilisateurs, moins ils présentent de latence au niveau du client. En outre, une couverture géographique suffisante peut améliorer indirectement la latence de bout en bout, car les serveurs de noms renvoient généralement des résultats optimisés pour l'emplacement du résolveur DNS. Autrement dit, si un fournisseur de contenu héberge des sites en miroir dans le monde entier, les serveurs de noms de ce fournisseur renvoient l'adresse IP la plus proche du résolveur DNS.

Le DNS public de Google est hébergé dans des centres de données du monde entier et utilise le routage Anycast pour diriger les utilisateurs vers le centre de données le plus proche géographiquement.

De plus, le DNS public de Google est compatible avec le sous-réseau client EDNS (ECS), une extension de protocole DNS permettant aux résolveurs de transmettre l'emplacement du client aux serveurs de noms, qui peut renvoyer des réponses sensibles à la position et optimisées pour l'adresse IP réelle du client plutôt que pour l'adresse IP du résolveur. Pour en savoir plus, consultez ces questions fréquentes. Le DNS public de Google détecte automatiquement les serveurs de noms compatibles avec le sous-réseau client EDNS.