TCP et UDP : différences, cas d'utilisation et diagnostic
TCP garantit la livraison ordonnée des données, UDP privilégie la légèreté. Comprendre leurs mécanismes permet de choisir le bon protocole et de diagnostiquer une connexion qui échoue.
TCP et UDP sont les deux protocoles de transport historiques de la pile TCP/IP. Tous deux utilisent des numéros de port pour identifier les applications, mais leurs garanties sont opposées. TCP est défini aujourd'hui par la RFC 9293 ; UDP par la RFC 768, l'une des plus courtes spécifications d'Internet.
Objectif : comprendre ce qu'apporte chaque protocole, savoir lequel est utilisé par les services courants, et diagnostiquer les échecs de connexion.
Vue d'ensemble
| Critère | TCP | UDP |
|---|---|---|
| Connexion | Établie avant l'échange | Aucune |
| Fiabilité | Accusés de réception, retransmissions | Aucune garantie |
| Ordre | Garanti | Non garanti |
| Contrôle de flux et de congestion | Oui | Non (à la charge de l'application) |
| En-tête | 20 octets minimum | 8 octets |
| Unité | Segment | Datagramme |
| Exemples | HTTPS, SSH, SMTP, IMAP, BGP | DNS (le plus souvent), DHCP, NTP, SNMP, syslog, VoIP (RTP), QUIC |
Comment fonctionne TCP
La poignée de main en trois temps
Avant tout échange, client et serveur synchronisent leurs numéros de séquence :
- Le client envoie un segment SYN avec un numéro de séquence initial.
- Le serveur répond SYN-ACK : il accuse réception et propose son propre numéro.
- Le client confirme avec un ACK. La connexion est établie.
La fermeture se fait normalement par l'échange de segments FIN et ACK dans chaque sens. Un segment RST interrompt brutalement la connexion : c'est notamment ce que renvoie un hôte lorsqu'aucun service n'écoute sur le port demandé.
Séquences, accusés et retransmissions
Chaque octet transmis est numéroté. Le récepteur indique, dans ses ACK, le prochain octet attendu. Si un accusé n'arrive pas à temps, l'émetteur retransmet. Les récepteurs modernes utilisent aussi les accusés sélectifs (SACK, RFC 2018) pour signaler précisément les blocs reçus.
Contrôle de flux et de congestion
- Contrôle de flux : le récepteur annonce une fenêtre indiquant combien d'octets il peut encore accepter. Une fenêtre à zéro suspend l'émission.
- Contrôle de congestion : l'émetteur adapte son débit en fonction des pertes ou des délais observés sur le réseau (algorithmes comme CUBIC, défini par la RFC 9438, ou BBR selon les systèmes).
Ces mécanismes expliquent pourquoi le débit d'un transfert TCP dépend fortement de la latence : sur un lien à forte latence, il faut une grande fenêtre pour remplir la capacité disponible.
Comment fonctionne UDP
UDP se contente d'ajouter ports source et destination, une longueur et une somme de contrôle aux données. Pas de connexion, pas d'accusé de réception, pas de retransmission.
Cette simplicité est un atout :
- Faible latence : idéale pour la voix, la vidéo en temps réel ou les jeux, où une donnée arrivée en retard est inutile.
- Échanges courts : une requête DNS tient souvent dans un seul datagramme ; établir une connexion TCP coûterait un aller-retour supplémentaire.
- Diffusion et multidiffusion : impossibles avec TCP, possibles avec UDP (DHCP utilise la diffusion).
Les applications qui ont besoin de fiabilité au-dessus d'UDP l'implémentent elles-mêmes. C'est le cas de QUIC (RFC 9000), utilisé par HTTP/3, qui offre chiffrement, multiplexage et retransmissions sur UDP.
DNS utilise UDP pour la plupart des requêtes, mais bascule sur TCP lorsque la réponse est trop volumineuse ou pour les transferts de zone. Le port 53 doit donc être ouvert en UDP et en TCP vers vos résolveurs (RFC 7766).
Diagnostiquer une connexion
Voir les ports en écoute et les connexions
Sous Linux :
ss -tulpn # ports TCP/UDP en écoute et processus associés
ss -tan state established
Sous Windows :
Get-NetTCPConnection -State Listen
netstat -ano | findstr :443
Tester l'ouverture d'un port TCP
Test-NetConnection -ComputerName srv-web01 -Port 443
nc -vz srv-web01 443 # selon la variante de netcat installée
curl -v https://srv-web01/
Interprétation des résultats :
| Observation | Signification probable |
|---|---|
| Connexion établie | Un service écoute et le chemin est ouvert |
| « Connection refused » (RST reçu) | Hôte joignable, aucun service sur ce port (ou rejet actif) |
| Délai dépassé (timeout) | Paquets filtrés silencieusement, hôte injoignable ou route de retour absente |
Tester UDP
Tester UDP est plus délicat : l'absence de réponse peut signifier « port ouvert sans réponse applicative » ou « paquet filtré ». Le plus fiable est d'utiliser le protocole applicatif lui-même :
dig @10.0.0.53 exemple.fr # DNS
ntpdate -q 10.0.0.123 # NTP (selon les outils disponibles)
Si un port UDP est fermé, l'hôte renvoie généralement un message ICMP « port unreachable », sauf si un pare-feu le bloque.
Capturer le trafic
sudo tcpdump -ni eth0 'tcp port 443 and host 10.0.0.15'
sudo tcpdump -ni eth0 'tcp[tcpflags] & (tcp-syn|tcp-rst) != 0'
Une série de SYN sans réponse indique un filtrage ou un problème de route. Des SYN suivis de RST indiquent un port fermé. Des retransmissions nombreuses révèlent des pertes sur le chemin.
Cas d'usage : quel protocole pour quel besoin ?
- Transfert de fichiers, Web, messagerie, administration : TCP, car l'intégrité prime.
- Résolution DNS, synchronisation horaire, supervision SNMP, journaux syslog : UDP, pour la légèreté (syslog peut aussi utiliser TCP ou TLS lorsque la perte de messages est inacceptable).
- Voix et vidéo temps réel : UDP (RTP), car la retransmission arriverait trop tard.
- Tunnels VPN : WireGuard utilise UDP ; OpenVPN peut fonctionner en UDP ou en TCP, UDP étant généralement préférable pour éviter l'empilement de deux mécanismes de retransmission.
Erreurs courantes
- Ouvrir un port en TCP seulement alors que le service utilise UDP (ou les deux).
- Conclure qu'un port UDP est fermé parce qu'aucune réponse n'est reçue.
- Ignorer les pare-feu à états : une règle qui autorise l'aller sans suivi de session bloque les réponses.
- Attribuer à TCP une lenteur qui vient de la latence ou d'une MTU mal ajustée. Voir MTU, MSS et fragmentation des paquets.
Implications de sécurité
TCP est exposé aux inondations de SYN, atténuées par les SYN cookies et les protections des pare-feu. UDP, sans poignée de main, permet d'usurper facilement l'adresse source : il est exploité dans les attaques par amplification (DNS, NTP, memcached mal configurés). N'exposez jamais un résolveur DNS ouvert ou un service UDP inutile sur Internet, et filtrez les ports selon le principe du moindre privilège. Voir Pare-feu : règles de filtrage et bonnes pratiques.
Conclusion
TCP apporte la fiabilité au prix de la latence et de l'état ; UDP apporte la légèreté au prix des garanties. Pour diagnostiquer, retenez la grille simple : refused = joignable mais fermé, timeout = filtré ou injoignable. La liste des ports usuels est disponible dans la référence des ports TCP/UDP.
