TCP fournit à une application un flux d'octets fiable et ordonné : les paquets perdus sont retransmis, les doublons éliminés et tout arrive dans l'ordre d'envoi. UDP se contente d'envoyer des datagrammes isolés et ne promet rien : ils peuvent arriver en retard, dans le désordre, en double ou pas du tout. Choisissez TCP quand chaque octet doit arriver intact (pages web, transferts de fichiers, e-mail, SSH) ; choisissez UDP quand un paquet en retard ne sert plus à rien (voix, visioconférence, jeux) ou quand l'application veut bâtir sa propre fiabilité, comme le fait QUIC.
En un coup d'œil
| Propriété | TCP | UDP |
|---|---|---|
| Connexion | Orienté connexion : poignée de main en trois temps (SYN, SYN-ACK, ACK) avant les données |
Sans connexion : le premier datagramme peut déjà porter des données |
| Livraison | Garantie : les segments perdus sont retransmis | Au mieux : les datagrammes perdus sont perdus |
| Ordre | Octets livrés dans l'ordre d'envoi | Aucun ordre ; les datagrammes arrivent dans n'importe quel ordre |
| Modèle de données | Un flux continu d'octets, sans frontières de message | Des messages distincts ; chaque send est un datagramme |
| Taille d'en-tête | 20 octets minimum, jusqu'à 60 avec options | 8 octets, toujours |
| Contrôle de flux et de congestion | Oui : ralentit quand le récepteur ou le réseau sature | Aucun ; l'application doit se discipliner |
| Diffusion et multidiffusion | Non, point à point uniquement | Oui |
| Blocage en tête de file | Oui : un segment perdu bloque tout ce qui suit | Non |
| Usages typiques | HTTP/1.1 et HTTP/2, TLS, SSH, SMTP, IMAP, FTP | Requêtes DNS, DHCP, NTP, SNMP, VoIP/RTP, jeux, QUIC (HTTP/3), WireGuard |
Les deux protocoles utilisent des numéros de port sur 16 bits (de 0 à 65535), mais leurs espaces de ports sont distincts : le port TCP 53 et le port UDP 53 sont deux points de terminaison différents. Vérifiez ce qui tourne habituellement sur un port avec la recherche de numéro de port.
TCP
TCP transforme un réseau peu fiable en quelque chose qui se comporte comme un tuyau. Chaque octet porte un numéro de séquence, le récepteur accuse réception de ce qu'il reçoit et tout ce qui n'est pas acquitté à temps est renvoyé. Une fenêtre glissante empêche un émetteur rapide de submerger un récepteur lent, et le contrôle de congestion ralentit quand le réseau lui-même perd des paquets.
Cette fiabilité a un prix. Une nouvelle connexion coûte un aller-retour pour la poignée de main avant tout transfert (plus la poignée de main TLS pour HTTPS), et un seul segment perdu retient toutes les données qui le suivent jusqu'à l'arrivée de la retransmission. Avec des allers-retours de 100 ms, cela se remarque.
Choisissez TCP quand :
- Chaque octet compte et l'ordre compte : pages web, API, téléchargements, connexions aux bases de données, e-mail, shells distants.
- Vous voulez que le système d'exploitation gère retransmission, rythme et congestion à votre place.
- Pare-feu et équipements intermédiaires doivent laisser passer le trafic sans traitement particulier ; TCP est le choix par défaut le plus sûr.
UDP
UDP n'ajoute presque rien à IP : port source, port de destination, longueur et somme de contrôle. Un datagramme arrive entier ou pas du tout ; le protocole ne découpe ni ne fusionne jamais les messages. Un datagramme UDP sur IPv4 peut transporter au plus 65 507 octets de données, mais tout ce qui dépasse la MTU du chemin (souvent environ 1 500 octets sur Ethernet) est fragmenté par IP, et la perte d'un seul fragment fait perdre tout le datagramme : les applications réelles gardent donc des datagrammes petits.
Choisissez UDP quand :
- La fraîcheur prime sur l'exhaustivité : dans un appel audio ou vidéo, un paquet qui arrive avec 300 ms de retard est inutile, le renvoyer ne fait qu'ajouter du délai.
- L'échange se résume à une petite requête et une petite réponse (DNS, NTP), où une poignée de main doublerait le coût.
- Vous avez besoin de diffusion ou de multidiffusion, comme DHCP pour trouver un serveur qu'il ne connaît pas encore.
- Vous construisez votre propre transport par-dessus. QUIC, la base de HTTP/3, fonctionne sur UDP pour éviter le blocage en tête de file entre flux et évoluer sans attendre les piles TCP des systèmes d'exploitation.
Lequel choisir ?
- Par défaut, TCP, sauf raison précise de faire autrement.
- Médias temps réel, jeux, télémétrie, où les données périmées ne valent rien : UDP.
- Petites requêtes question-réponse : UDP, avec repli sur TCP pour les grosses réponses (exactement ce que fait le DNS).
- Vous voulez les performances web modernes sans concevoir de protocole : utilisez HTTP/3 ou une bibliothèque QUIC plutôt qu'UDP brut.
- Ouverture de règles de pare-feu : précisez le protocole en plus du port ; autoriser TCP 443 n'autorise pas UDP 443. Le générateur de plages de ports TCP/UDP écrit les règles pour les deux.
Pour voir la différence sur le réseau, capturez un peu de trafic et ouvrez-le dans l'analyse forensique PCAP : les conversations TCP montrent la poignée de main, les accusés de réception et les retransmissions, tandis que les flux UDP ne sont qu'une suite de datagrammes indépendants.