TCP, UDP et sockets

Objectifs

À la fin de cette leçon, vous saurez :

• expliquer ce que TCP garantit — et par quel mécanisme ;
• situer UDP et ses cas d'usage légitimes ;
• définir socket, port et connexion, et prédire combien de clients un serveur peut servir simultanément ;
• relier IP → transport → application dans le voyage d'une requête web.

🔗 Pour vous rafraîchir la mémoire : comment deux machines communiquent

Où nous en sommes : la couche qui manquait

Le chapitre précédent s'est achevé sur une frustration assumée : IP achemine des paquets de son mieux, mais sans garantie — perte possible, désordre possible, doublons possibles. Or votre navigateur ne tolérerait pas de recevoir une image HTML dont 3 % des octets manquent ou arrivent mélangés.

Il faut donc une couche au-dessus d'IP qui transforme « livraison au mieux » en service utilisable : le transport. Deux protocoles dominent, deux philosophies opposées :

TCP : je construis une conversation FIABLE (tout arrive, dans l'ordre)
UDP : j'envoie vite et je m'assume (perte possible, pas de session)

TCP : comment on fabrique la fiabilité

TCP (Transmission Control Protocol) ne fait pas de miracle : il ajoute de l'intelligence aux deux extrémités pour compenser les caprices du réseau. Ses trois garanties, et leurs mécanismes :

Garantie	Mécanisme
Tout arrive	chaque segment est numéroté et accusé ; pas d'ACK à temps → retransmission
Dans l'ordre	le destinataire réordonne selon les numéros avant de livrer
Sans noyer l'autre	contrôle de flux : le récepteur annonce ce qu'il peut absorber

L'image juste : TCP est un courrier recommandé numéroté avec accusés de réception automatiques. Si la lettre n°7 n'a pas été acquittée, elle repart — pendant que les lettres 8, 9, 10 attendent sagement leur tour d'être remises dans l'ordre.

L'établissement de connexion : le triple poignée de main

Avant tout échange, les deux côtés se mettent d'accord :

client                          serveur
  │ ─── SYN  (« je veux parler, voici mon point de départ ») ──→  │
  │ ←── SYN-ACK  (« ok, moi aussi, voici LE MIEN ») ────────────   │
  │ ─── ACK  (« bien reçu, c'est parti ») ────────────────────→    │
                    connexion établie : les deux côtés sont synchronisés

Pourquoi trois messages ? Chacun sert à confirmer UNE direction : SYN/ACK confirme que client→serveur fonctionne, ACK que serveur→client fonctionne. Les deux sens sont validés avant que le premier octet utile parte. Vous verrez cette poignée de main en pratique dès la prochaine leçon (ss affiche SYN-SENT, ESTAB...).

À la fin, fermeture propre avec FIN/ACK des deux côtés — contrairement à une coupure brutale qui laisserait l'autre côté dans l'incertitude.

HTTP, SSH, PostgreSQL circulent sur TCP : tout ce qui exige que chaque octet arrive, dans l'ordre.

UDP : renoncer aux garanties, gagner en simplicité

UDP (User Datagram Protocol) n'ouvre aucune session : il emballe le message dans un datagramme adressé et le jette sur le réseau. Pas de numérotation, pas d'ACC, pas de retransmission. En échange : overhead minuscule et latence minimale — pas de poignée de main, pas d'attente.

Trois usages où ce compromis est gagnant :

1. DNS (chapitre suivant) : une question, une réponse, quelques dizaines d'octets. Ouvrir une session TCP coûterait plus cher que la requête elle-même ; si la réponse se perd, on relance — simple ;
2. Streaming vidéo / visio : mieux vaut perdre une frame (petite scintillure) que retarder tout le flux en attendant sa retransmission ;
3. Jeux en ligne : la position du joueur il y a 200 ms ne sert plus à rien — inutile de la faire retransmettre.

Tableau de décision :

	TCP	UDP
Session préalable	oui (SYN/SYN-ACK/ACK)	non
Ordre garanti	oui	non
Perte	retransmission	abandon assumé
Coût fixe par connexion	oui	zéro
Usages web	HTTP, bases de données	DNS, streaming, temps réel

Règle de choix : si une donnée perdue doit être récupérée (une page web, une transaction SQL), TCP. Si une donnée tardive est inutile (une frame vidéo, une position de joueur), UDP. Et notez que le monde moderne mélange : QUIC, le socle de HTTP/3, reconstruit la fiabilité de TCP par-dessus UDP.

Socket et port : l'adressage des processus

Souvenez-vous du chapitre 2 : un paquet arrive à une MACHINE. Mais dans cette machine, quel processus doit le recevoir ? C'est le rôle de deux notions :

Une socket est le point de terminaison logiciel d'une communication — l'objet détenu par un processus, qui lit et écrit sur le réseau :

processus Node
     ↓ crée une socket
socket liée au port 3000
     ↓
TCP 192.168.1.10:3000 ← les paquets à destination de ce couple arrivent ICI

Un port est simplement un numéro (0–65535) attaché à la socket — le numéro d'appartement dans l'immeuble-machine. Conventions à connaître par cœur :

Port	Service
22	SSH
53	DNS
80	HTTP
443	HTTPS
5432	PostgreSQL
3000–3001	vos serveurs Node de dev

Sous 1024 : ports « privilégiés » réservés aux services système (nécessitent des droits).

Le quadruplet : pourquoi mille clients cohabitent

La clé de voûte du web : une connexion est identifiée par quatre valeurs, pas deux :

(IP source, port source) ↔ (IP destination, port destination)

navigateur A : 192.168.1.20:51234 ↔ 93.184.216.34:443
navigateur B : 192.168.1.21:49882 ↔ 93.184.216.34:443
navigateur A (2e onglet) : 192.168.1.20:51235 ↔ 93.184.216.34:443

Le serveur écoute TOUJOURS sur le même port (443) ; mais chaque client choisit un port source éphémère aléatoire (>1024). Trois connexions distinctes coexistent parce que trois quadruplets distincts existent — même destination commune. C'est ainsi qu'un seul serveur sert des milliers d'utilisateurs simultanés.

Et côté serveur, la contrainte symétrique : un seul processus peut être en écoute sur un couple adresse/port donné. Tenter d'en lancer un second produit l'erreur EADDRINUSE (address already in use) que vous apprendrez à diagnostiquer dès demain.

La pile complète d'une requête web

Réassemblons toutes les couches vues jusqu'ici :

navigateur
  ↓ « GET / HTTP/1.1 »            APPLICATION (HTTP — chapitre 11)
  ↓ encapsulé + ports             TRANSPORT (TCP)
  ↓ encapsulé + adresses          RÉSEAU (IP)
  ↓ routage hop by hop            (passerelle, NAT, Internet)
serveur : dépile IP → TCP → remonte au processus qui écoute le port 443

Chaque couche ajoute ses informations d'adressage (enveloppe dans enveloppe) ; chaque couche du destinataire dépille dans l'ordre inverse. Retenez cette image d'oignon : elle explique pourquoi un problème peut vivre à n'importe quel étage — et pourquoi nos outils de diagnostic se répartissent par couche (ping = IP, ss = transport, curl = application).

Exercice

1. Pourquoi DNS utilise-t-il UDP alors que HTTP utilise TCP ?
2. Un flux vidéo en direct devrait-il utiliser TCP ? Justifiez avec le compromis latence/complétude.
3. Deux services peuvent-ils écouter simultanément sur le port 3000 de la même machine ? Sur 3000 et 3001 ?
4. Combien de connexions simultanées vers example.com depuis UN SEUL navigateur peuvent exister ?
5. Dessinez la pile complète d'un clic sur un lien https:// : de l'appui sur Entrée à l'affichage, nommez chaque couche et son rôle.

Résumé

• Transport = garanties au-dessus d'IP. TCP : fiabilité par numérotation + accusés + retransmission ; UDP : zéro session, zéro promesse.
• Triple poignée de main = validation des deux sens avant le premier octet utile.
• Socket = extrémité dans un processus ; port = son numéro ; connexion = quadruplet.
• Mille clients cohabitent grâce aux ports sources éphémères ; un port d'écoute = un seul propriétaire (EADDRINUSE sinon).

1. APPLICATION  : le navigateur fabrique « GET / HTTP/2 » + en-têtes
2. TRANSPORT    : TCP découpe, numérote, ouvre la session (SYN...)
3. RÉSEAU       : IP adresse les paquets (source/destination)
4. LIEN/PHYSIQUE: passerelle → NAT → routeurs hop by hop
5. SERVEUR      : NAT inverse → TCP réordonne et accuse → HTTP remonte
                  au processus qui écoute 443 → réponse en sens inverse