TCP vs UDP : quelles différences ?
Deux protocoles de transport, deux philosophies opposées. Fiabilité contre vitesse — et pourquoi le web moderne a besoin des deux.
Quand vous regardez une vidéo YouTube en streaming, votre navigateur reçoit des milliers de petits paquets de données envoyés par les serveurs de Google. Si un paquet est perdu en chemin, YouTube ne met pas la vidéo en pause pour le redemander — il l'ignore et continue. Vous perdez quelques millisecondes d'image, mais la lecture reste fluide.
Quand vous téléchargez ce même fichier vidéo, chaque paquet perdu est réclamé et retransmis jusqu'à ce qu'il arrive. Le téléchargement peut être plus lent, mais le fichier final est intact à l'octet près.
Ce comportement opposé n'est pas une question de configuration. C'est la différence fondamentale entre UDP et TCP.
La couche transport du modèle OSI
TCP et UDP opèrent tous les deux à la couche 4 du modèle OSI — la couche transport. Cette couche a une responsabilité précise : acheminer les données d'une application sur une machine vers une application sur une autre machine, via des ports.
En dessous (couche réseau), IP s'occupe de router les paquets d'une machine à l'autre. IP ne garantit rien : les paquets peuvent arriver dans le désordre, être dupliqués, ou disparaître. C'est à TCP ou UDP de gérer ça — ou de ne pas le gérer, selon le cas.
Application (HTTP, DNS, SSH, jeu...)
↓
Transport (TCP ou UDP) ← on est ici
↓
Réseau (IP)
↓
Liaison (Ethernet, Wi-Fi)
↓
Physique (câble, ondes)TCP : la livraison garantie
TCP — Transmission Control Protocol — est le protocole de la fiabilité. Il garantit que chaque octet envoyé arrive, dans le bon ordre, sans corruption.
Pour ça, TCP établit d'abord une connexion via le three-way handshake avant d'envoyer le moindre octet de données.
Le three-way handshake
Client Serveur
│ │
│──── SYN ────────────────►│ "Je veux me connecter"
│◄─── SYN-ACK ────────────│ "OK, je suis prêt"
│──── ACK ────────────────►│ "Reçu, on commence"
│ │
│══════ données ══════════►│
│◄═════ données ══════════│
│ │
│──── FIN ────────────────►│ "J'ai fini"
│◄─── FIN-ACK ────────────│ "OK, fermeture"SYN = synchronize, ACK = acknowledge. Ce handshake établit les numéros de séquence des deux côtés — c'est ce qui permet à TCP de reordonner les paquets et de détecter les pertes.
Ce que TCP garantit
Livraison : chaque paquet envoyé reçoit un accusé de réception (ACK). Si l'ACK n'arrive pas dans un délai donné, le paquet est retransmis.
Ordre : chaque paquet a un numéro de séquence. Le destinataire les reordonne avant de les passer à l'application.
Intégrité : un checksum vérifie que les données n'ont pas été corrompues en transit.
Contrôle de flux : TCP adapte le débit d'envoi à la capacité du récepteur — pas d'inondation si l'autre bout ne suit pas.
Contrôle de congestion : TCP réduit son débit si le réseau est congestionné (algorithmes CUBIC, BBR...).
L'en-tête TCP
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
├─────────────────────────┬───────────────────────────────────────┤
│ Port source │ Port destination │
├─────────────────────────────────────────────────────────────────┤
│ Numéro de séquence │
├─────────────────────────────────────────────────────────────────┤
│ Numéro d'acquittement │
├────────┬───────┬────────────────────────────────────────────────┤
│Offset │Flags │ Fenêtre │
├─────────────────────────┬───────────────────────────────────────┤
│ Checksum │ Pointeur urgent │
└─────────────────────────┴───────────────────────────────────────┘L'en-tête TCP fait 20 à 60 octets selon les options. C'est son coût — toute cette infrastructure de fiabilité a un prix en overhead.
UDP : la vitesse sans garanties
UDP — User Datagram Protocol — fait le strict minimum. Il prend vos données, les envoie, et n'attend aucune confirmation. Pas de connexion préalable, pas d'accusé de réception, pas de retransmission.
L'en-tête UDP
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
├─────────────────────────┬───────────────────────────────────────┤
│ Port source │ Port destination │
├─────────────────────────┬───────────────────────────────────────┤
│ Longueur │ Checksum │
└─────────────────────────┴───────────────────────────────────────┘8 octets. C'est tout. Comparé aux 20 minimum de TCP, c'est négligeable. Chaque datagramme UDP est indépendant — le protocole n'a aucune notion d'ordre ou de session.
Ce qu'UDP apporte
Latence minimale : pas de handshake, pas d'attente d'ACK. Le paquet part immédiatement.
Moins de CPU : pas de suivi de séquence, pas de gestion de la fenêtre de congestion.
Broadcast et multicast : UDP peut envoyer un paquet à plusieurs destinataires simultanément. TCP est strictement point-à-point.
Liberté applicative : l'application peut implémenter exactement la fiabilité dont elle a besoin — ni plus, ni moins.
Comparaison directe
| Critère | TCP | UDP |
|---|---|---|
| Connexion | Oui (handshake) | Non |
| Fiabilité | Garantie | Aucune |
| Ordre des paquets | Garanti | Non garanti |
| Retransmission | Oui | Non |
| En-tête | 20–60 octets | 8 octets |
| Latence | Plus élevée | Minimale |
| Débit | Variable (congestion) | Constant |
| Broadcast/Multicast | Non | Oui |
| Cas d'usage | HTTP, SSH, email, BDD | DNS, jeux, streaming, VoIP |
Qui utilise quoi — et pourquoi
TCP
HTTP/HTTPS — chaque requête web doit arriver complète et dans l'ordre. Une page web avec un paquet manquant est une page cassée.
SSH — une commande shell corrompue ou désordonnée est une commande fausse. L'intégrité est non-négociable. L'administration SSH distante repose entièrement sur TCP port 22.
Bases de données — PostgreSQL, MySQL, Redis : une transaction de base de données avec des paquets manquants serait catastrophique.
Email (SMTP, IMAP) — un email tronqué n'est pas un email.
Transferts de fichiers (FTP, SFTP) — chaque bit doit arriver.
UDP
DNS — une requête DNS tient dans un seul petit paquet. Si la réponse n'arrive pas en quelques millisecondes, le client renvoie la question. Inutile d'établir une connexion TCP pour ça.
Streaming vidéo (live, VoIP, WebRTC) — une image perdue est remplacée par la suivante. Un délai de retransmission TCP rendrait la conversation téléphonique inutilisable.
Jeux en ligne — la position d'un joueur à la milliseconde passée est obsolète. Mieux vaut l'ignorer que d'attendre sa retransmission.
DHCP — attribuer une IP à une machine qui n'en a pas encore. TCP nécessiterait une IP source pour établir la connexion — paradoxe.
DNS sur UDP — les requêtes DNS standard utilisent UDP port 53. Les transferts de zone DNS (AXFR) basculent sur TCP quand la réponse dépasse 512 octets. Pour comprendre le protocole DNS en profondeur — enregistrements, DNSSEC, diagnostic dig — le guide complet du protocole DNS détaille tout.
VPN — WireGuard utilise UDP par défaut. OpenVPN propose les deux modes, mais UDP est recommandé pour les performances. Les VPN UDP sont généralement plus rapides et moins sujets aux problèmes de "TCP over TCP" (double couche de retransmission). Pour choisir entre les protocoles VPN, le comparatif NordVPN / ExpressVPN / Surfshark aborde ce point.
Le cas QUIC / HTTP/3 : UDP fiable
HTTP/3 — la dernière version du protocole web — tourne sur QUIC, un protocole construit sur UDP. C'est en apparence un paradoxe : HTTP a besoin de fiabilité, mais il utilise UDP.
QUIC réimplémente les garanties de TCP (livraison, ordre, contrôle de flux) directement dans la couche applicative, en évitant les problèmes historiques de TCP :
Head-of-line blocking : en TCP, un paquet perdu bloque tous les paquets suivants d'une même connexion, même s'ils concernent des ressources indépendantes. QUIC gère plusieurs flux dans la même connexion UDP — un flux bloqué n'affecte pas les autres.
0-RTT : QUIC peut envoyer des données dès le premier paquet sur une connexion déjà connue — le handshake est fusionné avec les premières données.
Connexion resiliente : un changement de réseau (Wi-Fi → 4G) brise une connexion TCP (l'IP change). QUIC identifie la connexion par un ID, pas par le couple IP:port — la connexion survit au changement de réseau.
C'est l'argument le plus fort pour UDP : il donne aux développeurs la liberté d'implémenter exactement ce dont ils ont besoin, sans les contraintes figées de TCP.
Observer TCP et UDP en pratique
Sur Linux, ss liste toutes les connexions actives. Parmi les 50 commandes Linux indispensables, c'est l'une des plus utiles pour diagnostiquer des problèmes réseau.
# Voir tous les ports en écoute — TCP et UDP
ss -tuln
# Avec le processus associé
ss -tulnp
# Connexions TCP établies
ss -tn state established
# Connexions UDP actives
ss -unNetid State Local Address:Port Peer Address:Port
tcp LISTEN 0.0.0.0:22 0.0.0.0:* # SSH (TCP)
tcp LISTEN 0.0.0.0:80 0.0.0.0:* # HTTP (TCP)
tcp LISTEN 0.0.0.0:443 0.0.0.0:* # HTTPS (TCP)
udp UNCONN 0.0.0.0:53 0.0.0.0:* # DNS (UDP)
udp UNCONN 0.0.0.0:51820 0.0.0.0:* # WireGuard (UDP)Filtrer par protocole avec UFW
Quand vous définissez des règles de pare-feu, TCP et UDP se configurent séparément. UFW permet de les cibler explicitement :
sudo ufw allow 80/tcp # HTTP — TCP seulement
sudo ufw allow 443/tcp # HTTPS — TCP seulement
sudo ufw allow 53/udp # DNS — UDP seulement
sudo ufw allow 51820/udp # WireGuard — UDP seulement
sudo ufw allow 22/tcp # SSH — TCP seulementOuvrir un port sans préciser le protocole ouvre les deux — souvent inutile et légèrement moins sécurisé.
# Voir les règles avec protocoles
sudo ufw status verboseRésumé mental
Une façon de retenir la différence :
TCP c'est un appel téléphonique. Vous décrochez (handshake), vous parlez, vous attendez que l'autre réponde, vous raccrochez proprement. Rien n'est perdu, tout est ordonné.
UDP c'est envoyer des lettres. Vous écrivez, vous envoyez, vous ne savez pas si elles arrivent. Mais vous pouvez en envoyer mille par heure sans attendre de réponse.
Les deux ont leur place. HTTP/3 montre que la frontière n'est pas aussi figée qu'elle en a l'air — avec assez d'ingénierie, UDP peut devenir aussi fiable que TCP, tout en évitant ses limitations historiques.
TCP et UDP sont deux pièces d'un puzzle plus large — comment fonctionne Internet dans son ensemble couvre DNS, HTTP, TLS et CDN pour voir comment ces protocoles s'assemblent.