Pourquoi la latence DNS rend-elle une application de serveur domestique lente sur un réseau local ?

Une application de serveur domestique peut sembler lente sur un LAN rapide parce que le client doit peut-être résoudre son nom d'hôte avant de pouvoir démarrer une nouvelle connexion. Si cette recherche attend un cache vide, un résolveur indisponible ou un chemin de secours, la pause se produit avant que l'application ait la chance de répondre.

Cela ne signifie pas que DNS s'exécute avant chaque requête HTTP ni ne réduit le débit d'une connexion établie. DNS est le plus visible lorsqu'un client a besoin d'un nouveau résultat d'adresse ou d'une nouvelle connexion, c'est pourquoi le premier chargement peut sembler lent alors que la navigation ultérieure paraît normale.

La latence DNS retarde le démarrage de la connexion, pas chaque requête d'application

Lorsqu'un navigateur ou un client ouvre un nom d'hôte, son résolveur doit retourner une adresse que la pile réseau peut utiliser. Le modèle de résolveur DNS permet que cette réponse provienne d'informations en cache ou d'un ou plusieurs serveurs de noms, donc le temps de recherche peut varier même si le serveur de destination ne change jamais.

Une fois qu'une adresse et une connexion sont disponibles, les requêtes ultérieures peuvent les réutiliser. HTTP/2, par exemple, associe les échanges de requêtes et réponses à des flux indépendants sur une connexion ; ce multiplexage de flux HTTP/2 est une des raisons pour lesquelles de nombreuses ressources ne nécessitent pas chacune une nouvelle connexion et une nouvelle recherche DNS.

Un LAN facilite la distinction. Le transfert de charge utile et les allers-retours serveur peuvent être brefs, tandis qu'une nouvelle tentative ou un chemin de secours du résolveur reste une attente distincte devant eux. L'utilisateur ressent le temps combiné et peut blâmer l'application, le stockage ou le réseau même si le retard s'est produit avant le début du trafic applicatif.

Comment un nom d'hôte de serveur domestique est résolu sur un LAN

Caches du navigateur et du système d'exploitation

Le client peut déjà détenir un résultat d'adresse utilisable. Un succès de cache peut éliminer le besoin d'un échange DNS sur le réseau, tandis qu'une entrée expirée ou absente envoie la requête plus loin dans le chemin de résolution. Les caches du navigateur, du système d'exploitation et du résolveur récursif sont des couches distinctes, donc leur état ne change pas toujours simultanément.

Le résolveur LAN configuré

Lorsque les données du cache local ne sont pas disponibles, un client interroge généralement un résolveur configuré, qui peut être un routeur, un service DNS local dédié ou un autre résolveur récursif. Ce résolveur peut répondre à partir d'une zone locale autoritaire, répondre depuis son propre cache ou poursuivre la requête ailleurs. Le fait que le serveur soit sur le LAN ne garantit pas que chaque résolveur impliqué soit également proche ou en bon état.

Domaines de recherche, mDNS et chemins de secours

Les noms d'hôtes courts et les noms se terminant par .local peuvent suivre des mécanismes différents. Les règles multicast DNS pour les noms .local dirigent ces requêtes vers le multicast local, tandis que les implémentations peuvent également utiliser d'autres mécanismes simultanément. Les suffixes de recherche et le comportement de secours peuvent donc ajouter des tentatives que les descriptions DNS unicast ordinaires ne capturent pas.

Les échecs de cache et les délais d'attente du résolveur produisent des pauses différentes

Un échec de cache n'est pas automatiquement une faute. Cela signifie que la réponse doit être obtenue d'une autre source, donc la première recherche peut prendre plus de temps qu'une recherche mise en cache. Un délai d'attente est différent : le résolveur n'a pas reçu de réponse utile dans sa période d'attente et peut réessayer un autre serveur ou transport.

Les directives actuelles sur les échecs et nouvelles tentatives DNS distinguent les échecs, les serveurs inaccessibles, les nouvelles tentatives et les échecs mis en cache. Elles notent également que des questions identiques en attente peuvent être combinées plutôt qu'émises comme requêtes indépendantes en amont, ce qui explique pourquoi les délais DNS ne doivent pas être multipliés mécaniquement par le nombre de ressources de l'application.

Le modèle visible est souvent plus informatif qu'une moyenne unique. Un délai de premier chargement constamment faible, un délai de cache froid et une pause longue irrégulière indiquent des états différents et ne doivent pas être regroupés sous une étiquette générique « DNS lent ».

Un écran d'application peut impliquer plusieurs noms d'hôtes

Un tableau de bord local peut charger son document principal depuis un nom d'hôte tout en contactant d'autres noms pour une API, un point de terminaison WebSocket, un service d'identité, un plugin, une police, une image de couverture ou une vérification de mise à jour. Seule l'application principale doit être locale pour que l'écran ait l'air local ; son graphe de dépendances peut toujours traverser plusieurs origines.

Chaque nouvelle origine peut créer une autre opportunité de résolution et de connexion, mais les délais ne s'additionnent pas nécessairement de manière linéaire. Les navigateurs peuvent exécuter des tâches simultanément, les résolveurs peuvent mettre en cache ou combiner des questions similaires, et plusieurs ressources de même origine peuvent partager une connexion.

La question pratique n'est donc pas « Combien de fichiers sont sur la page ? » mais « Combien de noms distincts et de nouveaux chemins de connexion sont nécessaires avant que l'interface devienne utilisable ? » Une petite dépendance API bloquante peut avoir plus d'importance que de nombreuses images chargées plus tard en parallèle.

Pourquoi le premier chargement peut être lent mais les rafraîchissements semblent rapides

La première visite peut inclure une recherche DNS, une nouvelle connexion TCP, une poignée de main TLS, une authentification et un travail initial d'application. Un rafraîchissement peut bénéficier simultanément des caches d'adresses, des connexions existantes, des entrées de cache HTTP et des données d'application réchauffées.

Cela fait d'un rafraîchissement plus rapide un indice utile, pas une preuve que le DNS était la seule cause. Pour isoler le DNS, la phase de recherche doit être séparée de l'établissement de la connexion et de la réponse du serveur au lieu de traiter la différence complète du premier chargement comme le temps du résolveur.

L'emplacement du résolveur est le plus important lorsque le nom est local

Un nom d'hôte interne nécessite un mécanisme de résolution qui comprend son espace de noms. Une zone autoritaire locale, une configuration DNS partagée ou un nom mDNS peut garder la réponse associée au LAN, tandis qu'un résolveur public général peut ne pas avoir d'enregistrement pour ce nom interne.

Cela ne signifie pas que chaque nom d'hôte local envoyé à un résolveur externe fait un long trajet et réussit finalement. Selon le nom et la configuration, le résultat peut être une réponse négative rapide, une nouvelle tentative ou un recours à un autre mécanisme. L'emplacement du résolveur est important car il change quel système peut répondre correctement, pas simplement parce qu'un serveur est physiquement plus proche.

Le DNS n'est pas la seule source d'une première réponse lente

Le démarrage de l'application, les requêtes de base de données, les E/S de stockage, le routage par proxy inverse, l'authentification et TLS peuvent tous retarder la première réponse visible après la résolution du nom. Si le nom d'hôte et un test contrôlé basé sur l'adresse sont également lents, le goulot d'étranglement est moins probablement le DNS.

Une comparaison basée sur l'adresse a aussi ses limites. Les certificats HTTPS et l'hébergement virtuel dépendent des noms, et un proxy inverse peut diriger la même IP vers différentes applications selon le nom d'hôte demandé. Un test d'adresse échoué ou au comportement différent n'est pas un benchmark DNS propre.

Utilisez la limite des symptômes avec précaution : le DNS est plausible lorsque les attentes se concentrent autour de l'utilisation d'un nom non mis en cache, d'un échec du résolveur ou de nouveaux chemins de connexion. Il est moins plausible lorsque le temps de recherche est négligeable mais que le temps jusqu'au premier octet reste élevé.

Séparer le temps DNS du temps TCP, TLS et application

La chaîne de latence utile comprend la recherche DNS, l'établissement de la connexion, la mise en place de la connexion sécurisée lorsque cela s'applique, le début de la requête, le début de la réponse et le transfert du contenu. Le modèle de phase Navigation Timing du W3C expose des horodatages distincts pour la recherche de domaine et la connexion, y compris le cas où les informations de domaine proviennent du cache.

Pour les ressources de page individuelles, l’interface Resource Timing sépare les phases de recherche, connexion, requête et réponse. Les règles de confidentialité cross-origin peuvent cacher certains détails, donc l'absence de champs de temporisation n'est pas automatiquement une preuve d'absence de latence.

Le ping et le débit de copie de fichiers répondent à des questions différentes. Le ping mesure la disponibilité et le comportement du trajet réseau aller-retour ; un transfert important mesure un chemin de données établi. Aucun ne permet d'isoler la résolution de nom qui peut se produire avant qu'une application ouvre sa première connexion.

FAQ

Le DNS affecte-t-il chaque clic dans une application de serveur domestique ?

Non. Le DNS est important lorsque le client a besoin d'un nom résolu pour un résultat nouveau ou expiré. Les adresses en cache, les connexions persistantes et les requêtes multiplexées peuvent permettre à de nombreuses interactions de se dérouler sans une nouvelle requête DNS réseau.

Pourquoi l'application se charge-t-elle plus rapidement par adresse IP que par nom d'hôte ?

Contourner le nom d'hôte peut retirer la résolution de nom de ce chemin de test, donc la différence peut impliquer le DNS. Ce n'est pas concluant car les certificats, hôtes virtuels, redirections et règles de reverse-proxy peuvent faire que le chemin d'adresse se comporte différemment.

Le mDNS peut-il être plus lent que le DNS local classique ?

Il peut se comporter différemment car il utilise le multicast link-local et peut coexister avec d'autres mécanismes de recherche. Sa lenteur dépend du client, du réseau, du nom, du cache et du comportement de secours plutôt que d'une pénalité universelle liée à mDNS.

Changer le DNS public accélérera-t-il la résolution de nom d'un serveur domestique local ?

Seulement si ce résolveur public fait réellement partie du chemin réussi ou échoué. Un nom détenu dans une zone locale ou résolu via mDNS nécessite le mécanisme local approprié ; changer un résolveur public non lié peut ne rien faire.

Pourquoi l'application devient-elle lente à nouveau après un redémarrage ou une longue période d'inactivité ?

Un redémarrage ou une longue période d'inactivité peut supprimer les données d'adresse en cache et fermer les connexions réutilisables, tandis que l'application elle-même peut également perdre ses caches chauds. Le chargement suivant peut donc répéter plusieurs étapes de démarrage, pas seulement le DNS.

Le DNS modifie le temps de démarrage de l'application, pas le débit du NAS domestique

Une résolution de nom à faible latence et fiable peut rendre les premières connexions et les nouvelles dépendances d'application plus réactives, mais elle n'augmente pas la vitesse du disque ni le débit d'un transfert LAN établi. Diagnostiquez le DNS à son emplacement avant le début de la connexion, puis mesurez séparément la réponse TCP, TLS et de l'application avant de blâmer le serveur domestique.