Transport et résolution de noms
Ce que ce chapitre apporte
- Expliquer ce qu'un numéro de port ajoute à une adresse IP.
- Comparer les deux protocoles de transport et dire lequel convient à quel usage.
- Décrire la poignée de main en trois temps et dire ce qu'elle établit.
- Expliquer pourquoi le débit d'un transfert dépend du délai autant que du lien.
- Décrire la résolution d'un nom, du client jusqu'au serveur qui fait autorité.
- Séparer une panne de nommage d'une panne de routage en une commande.
Tout ce qui précède achemine des paquets d'une machine à une autre. C'est déjà beaucoup, et c'est encore insuffisant pour un usage réel : une machine fait tourner des dizaines de programmes à la fois, et rien dans un paquet IP ne dit auquel il s'adresse. Par ailleurs, personne ne retient d'adresses. Les deux dernières briques du module répondent à ces deux manques, et l'ordre dans lequel on les diagnostique fait gagner beaucoup de temps.
Une adresse ne suffit pas
Une adresse IP désigne une machine. Sur cette machine tournent un serveur web, un serveur de fichiers, une session à distance et vingt autres programmes. Le système doit donc pouvoir dire à qui remettre chaque paquet, et c'est le rôle du numéro de port.
Un port est un nombre de 16 bits qui identifie un programme sur une machine. Le couple adresse et port désigne un point de communication précis ; l'échange complet est identifié par le quadruplet source, port source, destination, port destination.
Les ports en dessous de 1024 sont réservés à des services connus : 22 pour la session à distance chiffrée, 25 et 587 pour le courrier sortant, 53 pour la résolution de noms, 80 et 443 pour le web, 3389 pour le bureau à distance. Le client, lui, choisit un port libre au hasard dans les numéros élevés, ce qui explique les 51000 du chapitre 7.
C'est ce couple qui rend possible la traduction d'adresses, et c'est aussi lui qu'un pare-feu examine. Une règle de filtrage ne parle presque jamais d'adresses seules.
Deux protocoles de transport
TCP établit une connexion, numérote les octets, retransmet ce qui manque, remet dans l'ordre et ralentit quand le réseau sature.
UDP envoie le datagramme et n'en reparle plus : ni connexion, ni acquittement, ni ordre, ni contrôle.
Le second n'est pas une version dégradée du premier, c'est un autre compromis. Ce que TCP apporte, il le fait payer en délai : retransmettre exige d'attendre, et attendre est parfois pire que perdre. Un flux de voix préfère une syllabe manquante à une syllabe qui arrive une demi-seconde trop tard, et une résolution de noms préfère renvoyer la question plutôt que d'ouvrir une connexion pour deux paquets.
| Besoin | Protocole | Pourquoi |
|---|---|---|
| Transfert de fichier, web, courrier | TCP | Perdre un octet corromprait le résultat |
| Voix, vidéo en direct, jeu | UDP | Une retransmission arriverait trop tard pour servir |
| Résolution de noms | UDP | Une question, une réponse : la connexion coûterait plus que l'échange |
| Journalisation vers un collecteur | UDP | Perdre une ligne vaut mieux que bloquer l'application qui l'émet |
La poignée de main
Une connexion TCP s'ouvre par trois messages, avant tout transport de données.
Les trois messages ne servent pas à demander l'autorisation mais à synchroniser deux compteurs. Chaque extrémité annonce le numéro à partir duquel elle comptera ses octets, et vérifie que l'autre l'a bien reçu. Sans cet accord initial, aucune des deux ne pourrait dire ce qui manque.
Deux conséquences pratiques. Ouvrir une connexion coûte un aller-retour complet avant la première donnée utile, ce qui pèse lourd sur un lien lointain et pour rien sur un réseau local. Et un serveur qui refuse une connexion répond immédiatement, alors qu'un pare-feu qui la jette ne répond pas du tout : la différence entre un refus rapide et une attente qui expire dit lequel des deux est en cause.
Un port fermé et un port filtré ne se comportent pas pareil. Un port fermé répond par un refus, et le client le sait aussitôt. Un port filtré ne répond rien, et le client attend jusqu'à expiration du délai. Ce délai d'attente est en soi une information : il désigne un équipement qui jette en silence, pas un service absent.
Pourquoi un lien rapide peut être lent
TCP n'envoie pas indéfiniment sans nouvelles : il envoie une fenêtre d'octets, puis attend les acquittements avant de continuer. Le débit maximal d'une connexion est donc la fenêtre divisée par le temps d'aller-retour, et le débit du lien n'y change rien.
Le résultat est frappant et explique beaucoup de plaintes. Sur une liaison intercontinentale à 100 millisecondes d'aller-retour, une connexion à fenêtre de 64 Kio plafonne à un peu plus de 5 Mbit/s, quel que soit le débit du lien. Multiplier la capacité du lien par dix n'y change rien : le facteur limitant n'est pas la largeur du tuyau mais sa longueur.
Un transfert lent sur une longue distance n'est pas forcément un problème de bande passante. Mesurer d'abord le temps d'aller-retour, puis calculer le plafond théorique, évite de commander un lien plus gros qui ne changera rien. Le remède est du côté de la fenêtre, ou du nombre de connexions parallèles.
Traduire un nom en adresse
Personne ne retient d'adresses, et une adresse change quand un service déménage. Un système de noms hiérarchique fait la traduction, en déléguant à chaque niveau.
Deux rôles bien distincts apparaissent dans cette figure, et les confondre rend tout le reste incompréhensible.
Le poste pose une question unique et attend une réponse complète : il délègue tout le travail. Le résolveur fait le travail, en interrogeant successivement des serveurs qui ne connaissent chacun qu'un niveau. Aucun serveur de la chaîne ne connaît la réponse finale, sauf le dernier ; les autres savent seulement à qui s'adresser ensuite.
Chaque réponse est accompagnée d'une durée de validité, et le résolveur la conserve pendant ce temps. C'est ce qui rend le système supportable à l'échelle du monde.
Le cache divise le trafic par le nombre de demandes, ce qui est considérable, et il a un revers exact : pendant toute la durée de validité annoncée, l'ancienne adresse continue de circuler. C'est la raison pour laquelle on abaisse cette durée quelques jours avant un déménagement prévu, et non le jour même.
Les enregistrements que l'on rencontre le plus souvent tiennent en cinq lignes.
| Type | Ce qu'il donne |
|---|---|
A | L'adresse IPv4 d'un nom |
AAAA | L'adresse IPv6 du même nom |
CNAME | Un autre nom, à résoudre à son tour |
MX | Le serveur qui reçoit le courrier du domaine |
NS | Les serveurs qui font autorité sur le domaine |
Séparer les deux pannes
C'est le geste de diagnostic le plus rentable de tout le module, et il tient en deux commandes.
Un ping vers une adresse numérique connue teste le chemin, le routage et la passerelle, sans faire intervenir la moindre traduction de nom. Un ping vers un nom teste la même chose plus la traduction.
Si le premier réussit et que le second échoue, le réseau fonctionne et le problème est dans la résolution de noms : serveur injoignable, serveur mal renseigné sur le poste, ou enregistrement absent. Si les deux échouent, la traduction n'est pas en cause, et il faut reprendre le chemin depuis la passerelle.
Le message Unknown host du chapitre 6 prend ici tout son sens. Il ne dit rien du routage : il dit que le nom n'a pas pu être traduit, et donc qu'aucun paquet n'a même été envoyé. Chercher une route à ce moment-là fait perdre du temps.
Exercices type
Exercice 1 : un transfert entre deux continents plafonne à 5 Mbit/s sur un lien à 1 Gbit/s. L'opérateur propose d'augmenter le débit. Est-ce la bonne réponse ?
Afficher la solution
Non, et le calcul le montre avant même de tester.
Une connexion ne peut pas dépasser sa fenêtre divisée par le temps d'aller-retour. Avec une fenêtre de 64 Kio et 100 millisecondes d'aller-retour, le plafond est d'environ 5 Mbit/s, quel que soit le lien. Le facteur limitant est la distance, pas la capacité.
Trois remèdes existent, et aucun ne consiste à agrandir le lien. Augmenter la fenêtre, ce que les systèmes récents font d'eux-mêmes si on les laisse faire. Ouvrir plusieurs connexions en parallèle, chacune ayant son propre plafond. Ou rapprocher les données, par un relais placé du même côté que ceux qui les lisent.
Exercice 2 : une application se connecte à un service et reste bloquée jusqu'à expiration du délai. Une autre reçoit un refus immédiat. Que conclure ?
Afficher la solution
Deux causes différentes, que la vitesse de l'échec distingue.
Le refus immédiat vient de la machine visée : elle est joignable, le paquet est arrivé, et rien n'écoute sur ce port. Le service n'est pas démarré, ou il écoute ailleurs.
L'attente jusqu'à expiration signifie qu'aucune réponse n'est revenue. Un équipement intermédiaire jette les paquets sans le dire, ou la machine visée n'est pas joignable du tout.
Le temps de l'échec est donc une information de diagnostic à part entière, et il faut l'observer avant de conclure quoi que ce soit.
Exercice 3 : après un changement d'hébergeur, une partie des visiteurs atteint le nouveau serveur et une autre l'ancien. Pourquoi ?
Afficher la solution
À cause des caches et de la durée de validité annoncée avant le changement.
Chaque résolveur ayant obtenu l'ancienne adresse la conserve pendant toute cette durée. Un résolveur qui l'a demandée cinq minutes avant la bascule servira l'ancienne adresse pendant presque une durée complète, tandis qu'un autre, qui la demande après, obtient la nouvelle.
La coexistence des deux est donc normale et temporaire. Ce qu'il fallait faire, c'est abaisser la durée de validité plusieurs jours avant le déménagement, pour que les caches se vident vite le jour venu, puis la remonter ensuite.
Dans l'intervalle, garder l'ancien serveur en service évite que la moitié des visiteurs ne tombe sur rien.
Exercice 4 : un poste ne joint aucun site, mais ping 9.9.9.9 répond. Où chercher ?
Afficher la solution
Le routage fonctionne de bout en bout, jusqu'à une adresse publique : la carte, l'adresse, le masque, la passerelle et le chemin sont tous corrects.
Il ne reste que la traduction des noms. Trois vérifications, dans cet ordre.
L'adresse du serveur de noms configurée sur le poste, souvent fournie en même temps que l'adresse et donc absente si l'attribution automatique a échoué à moitié.
La joignabilité de ce serveur, par un ping vers son adresse.
La réponse qu'il donne, en lui demandant explicitement un nom connu. Une absence de réponse et une réponse négative ne se corrigent pas au même endroit.
1.Qu'ajoute un numéro de port à une adresse IP ?
2.Pourquoi la résolution de noms emploie-t-elle UDP ?
3.À quoi servent les trois messages d'ouverture d'une connexion TCP ?
4.Une connexion plafonne à 5 Mbit/s sur un lien gigabit très long. Que faire ?
5.Une connexion échoue par expiration du délai plutôt que par un refus. Que suggère cette différence ?
6.Que garde un résolveur après avoir traduit un nom ?
7.Le ping vers une adresse numérique réussit, celui vers un nom échoue. Que conclure ?
La méthode
- Tester une adresse numérique avant un nom, pour séparer le routage de la résolution en une commande.
- Observer la vitesse d'un échec : un refus immédiat et une expiration ne désignent pas le même endroit.
- Mesurer l'aller-retour avant de conclure qu'un transfert lent vient du lien.
- Calculer le plafond que fenêtre et délai imposent, avant de commander de la bande passante.
- Abaisser la durée de validité plusieurs jours avant un changement d'adresse prévu.
- Vérifier l'adresse du serveur de noms sur le poste dès qu'un
Unknown hostapparaît.
Synthèse
- Un port désigne le programme destinataire ; le quadruplet adresse et port des deux côtés identifie l'échange.
- TCP ordonne, retransmet et ralentit ; UDP ne fait rien de tout cela, et c'est parfois exactement ce qu'il faut.
- La poignée de main en trois temps synchronise les compteurs d'octets, et coûte un aller-retour avant la première donnée.
- Le débit d'une connexion vaut la fenêtre divisée par l'aller-retour : sur une longue distance, le lien n'est pas le facteur limitant.
- La résolution de noms délègue de niveau en niveau ; le poste pose une question, le résolveur fait tout le travail.
- Le cache rend le système tenable et retarde d'autant la propagation d'un changement.
- Un
pingpar adresse puis par nom sépare une panne de routage d'une panne de nommage, en deux commandes.