TCP, UDP et ports

Un numéro de port tient sur 16 bits, il va donc de 0 à 65535. Les serveurs web en HTTPS écoutent sur le port 443.

Deux énigmes pour commencer. Pendant un appel vidéo, un petit morceau de la voix de ton ami se perd en route. Ton application doit-elle le redemander ? Maintenant, tu télécharges un fichier de devoirs et un morceau du fichier se perd. Même question. Décide pour les deux avant de lire la suite.

Deux morceaux perdus, deux réponses différentes

Si tu as dit non pour l'appel et oui pour le fichier, tu as déjà choisi entre les deux protocoles de transport. Un morceau de son qui arrive une demi-seconde trop tard ne sert à rien. La conversation a continué, il vaut donc mieux sauter ce morceau et jouer le suivant. Un fichier auquel il manque un morceau est abîmé, alors ce morceau vaut la peine d'attendre. Internet a un protocole de transport pour chaque cas : TCP attend et renvoie, UDP envoie et passe à la suite. Mais avant que l'un ou l'autre puisse aider, un paquet doit atteindre le bon programme.

Quel programme reçoit le paquet : les ports

Une adresse IP amène un paquet au bon ordinateur. Mais un ordinateur fait tourner beaucoup de programmes à la fois : un navigateur avec plusieurs onglets, une messagerie, une application de musique. Les en-têtes TCP et UDP portent tous deux un port source et un port de destination, chacun étant un nombre de 16 bits entre 0 et 65535, et le port indique à quel programme le paquet est destiné. Un programme serveur écoute sur un port convenu : 80 pour le HTTP simple, 443 pour le HTTPS, 53 pour le DNS, 25 pour le courrier entre serveurs. La RFC 6335 découpe la plage en ports système de 0 à 1023, ports utilisateur de 1024 à 49151 et ports dynamiques de 49152 à 65535. Ton ordinateur choisit un port source temporaire pour chaque conversation, souvent dans la plage dynamique. Une adresse et un port ensemble, comme 198.51.100.20:443, désignent exactement une extrémité d'une conversation.

TCP coche chaque octet

TCP (RFC 9293) transforme un flux de paquets peu fiable en une sorte de ligne téléphonique pour octets. D'abord, les deux côtés établissent une connexion par une poignée de main en trois temps : le client envoie SYN, le serveur répond SYN-ACK et le client répond ACK. À partir de là, chaque octet a un numéro de séquence. Le récepteur envoie des accusés de réception (ACK) qui disent jusqu'où il en est, et remet en place les morceaux arrivés dans le désordre. Si l'expéditeur ne reçoit aucun ACK avant la fin du délai d'attente, il renvoie les données. La RFC 6298 fixe le premier délai à 1 seconde, puis l'ajuste au temps d'aller-retour mesuré. TCP ralentit aussi quand il constate des pertes, pour ne pas inonder une liaison chargée.

UDP envoie et passe à la suite

UDP (RFC 768, 1980) en fait beaucoup moins. Son en-tête ne fait que 8 octets : deux ports, une longueur et une somme de contrôle. Pas de poignée de main, pas de numéro de séquence, pas de renvoi. Pour l'appel vidéo de la première énigme, c'est exactement ce qu'il faut. Les courtes questions DNS utilisent aussi UDP, car une question et une réponse vont plus vite sans poignée de main. QUIC, le protocole de transport sous HTTP/3, fonctionne sur UDP et ajoute par-dessus son propre système de renvoi.

Quatre nombres pour distinguer deux onglets

Quatre nombres identifient ensemble une connexion TCP : adresse source, port source, adresse de destination et port de destination. C'est ainsi qu'un serveur sur le port 443 peut parler à des milliers de navigateurs à la fois sans les confondre, et que ton ordinateur portable distingue deux onglets ouverts sur le même site, car la connexion de chaque onglet utilise un port source différent. Touche un paquet dans le simulateur et lis son en-tête. Avant la box, la source est 192.168.0.12 port 51000. Après, le NAT a changé les deux nombres, et le routeur se souvient de l'échange pour que les réponses reviennent au bon onglet.