UDP, TCP et comportements de transport

UDP, TCP et comportements de transport

Au-dessus d’IP, deux protocoles de transport portent l’essentiel du trafic : UDP (User Datagram Protocol), qui envoie des datagrammes sans rien promettre, et TCP (Transmission Control Protocol), qui établit une connexion et garantit l’ordre et la livraison. Leurs comportements expliquent une bonne part des symptômes rencontrés en exploitation : délais dépassés, connexions refusées, débits décevants sur longue distance, services saturés par des demandes jamais terminées. Cette fiche décrit leurs mécanismes, la manière de les observer et les attaques qui les exploitent.

Explication de la marmotte

Il existe deux façons d’envoyer du courrier : la carte postale glissée dans la boîte sans savoir si elle arrivera, et la lettre recommandée avec accusé de réception, plus lente mais suivie. Les ordinateurs utilisent les deux selon les besoins, et chacune a ses faiblesses que les malveillants savent exploiter.

→ Lire l’explication complète de la marmotte

Ports et sockets

Une adresse IP désigne une machine ; un port, nombre de 16 bits, désigne un service sur cette machine. L’IANA (Internet Assigned Numbers Authority) répartit l’espace en trois plages (RFC 6335) : ports bien connus de 0 à 1023 (53 pour le DNS, 443 pour HTTPS), ports enregistrés de 1024 à 49151, ports dynamiques de 49152 à 65535. Le client, lui, utilise un port éphémère choisi par son système : de 49152 à 65535 sous Windows, de 32768 à 60999 par défaut sous Linux (sysctl net.ipv4.ip_local_port_range).

Une socket est l’extrémité d’une communication, identifiée par une adresse et un port. Une connexion TCP est entièrement définie par son quadruplet adresse source, port source, adresse destination, port destination (plus le protocole). C’est ce qui permet à un serveur de servir des milliers de clients sur le seul port 443.

UDP sans promesse de livraison

Datagramme et absence d’état

UDP, défini par le RFC 768 en 1980, tient en un en-tête de 8 octets : port source, port destination, longueur, somme de contrôle. Chaque datagramme est indépendant : pas de connexion, pas d’accusé de réception, pas de renvoi, pas de remise en ordre. Si un datagramme se perd, personne n’est prévenu ; c’est à l’application de s’en soucier, ou pas.

Cette frugalité convient aux échanges courts et aux flux où une donnée en retard ne vaut plus rien. Le DNS (Domain Name System) envoie une question, attend une réponse, et réessaie au bout d’un délai. La voix et la vidéo en temps réel préfèrent perdre un fragment de 20 ms plutôt que d’attendre sa retransmission. Les protocoles de découverte (DHCP, mDNS, SSDP) diffusent sur le réseau local. Et QUIC, le transport de HTTP/3 normalisé par le RFC 9000, s’appuie sur UDP pour réimplémenter en espace utilisateur fiabilité, contrôle de congestion et chiffrement, sans dépendre des évolutions du noyau ni des équipements intermédiaires (voir QUIC et HTTP moderne).

Penser qu’UDP est toujours plus rapide est une erreur : UDP n’est pas plus rapide, il est plus simple. Une application qui doit tout livrer reconstruit sur UDP une fiabilité qui, mal faite, sera plus lente que celle de TCP.

Diagnostic et filtrage difficiles

L’absence d’état complique tout. Un port UDP fermé répond en principe par un message ICMP (Internet Control Message Protocol) « port injoignable » (type 3, code 3) ; un port ouvert, souvent par rien du tout, si la requête ne ressemble pas à ce qu’attend le service. Le silence ne distingue donc pas un service ouvert, un filtrage et une perte. Les pare-feu, pour autoriser les réponses, créent un pseudo-état fondé sur le quadruplet et une temporisation (souvent 30 à 180 secondes selon les équipements) : trop courte, elle coupe les flux lents ; trop longue, elle remplit la table d’états.

TCP comme contrat de fiabilité

Établissement : la poignée de main en trois temps

TCP, décrit aujourd’hui par le RFC 9293 (2022, qui remplace le RFC 793 de 1981), établit une connexion avant tout échange de données :

Chaque extrémité choisit un numéro de séquence initial imprévisible, que l’autre acquitte augmenté de un, ce qui empêche un tiers d’injecter des segments à l’aveugle.

Séquence, acquittement, retransmission

Chaque octet envoyé est numéroté. Le récepteur renvoie un ACK (acknowledgement) qui indique le prochain octet attendu ; un ACK de 7001 signifie « tout reçu jusqu’à 7000 ». Si l’acquittement n’arrive pas avant le RTO (Retransmission Timeout), calculé à partir du RTT (Round-Trip Time) mesuré, le segment est renvoyé et le délai doublé. Trois ACK dupliqués déclenchent une retransmission rapide sans attendre le RTO. L’option SACK (Selective Acknowledgment) permet de signaler les blocs reçus au-delà d’un trou.

Fermeture et TIME-WAIT

La fermeture se fait par un échange de FIN acquittés dans chaque sens, chaque côté pouvant fermer son sens d’émission indépendamment. Celui qui ferme le premier passe par FIN-WAIT-1, FIN-WAIT-2 puis TIME-WAIT, état qu’il conserve deux fois la durée de vie maximale d’un segment (60 secondes sous Linux) pour absorber les segments retardataires. L’autre passe par CLOSE-WAIT puis LAST-ACK. Des centaines de sockets en CLOSE-WAIT signalent presque toujours une application qui oublie de fermer ses connexions ; des milliers en TIME-WAIT, un client qui en ouvre et en ferme à cadence élevée.

Refus, délai dépassé, réinitialisation

Trois symptômes, trois causes, à ne jamais confondre :

Symptôme	Ce qui se passe	Cause probable
Connexion refusée (refused)	le SYN reçoit un RST immédiat	la machine répond, mais aucun service n’écoute sur ce port
Délai dépassé (timeout)	le SYN ne reçoit rien, le client réessaie puis abandonne	filtrage silencieux (DROP), machine éteinte, route absente
Réinitialisation (reset)	un RST arrive au milieu d’une connexion établie	application qui s’arrête, équipement intermédiaire qui coupe, état perdu

Un refus est une bonne nouvelle relative : le réseau fonctionne jusqu’à la machine. Un pare-feu configuré en REJECT plutôt qu’en DROP renvoie un RST ou un ICMP, et donne donc l’apparence d’un refus.

Backlog

Un serveur qui appelle listen() dispose de deux files : celle des connexions à moitié ouvertes (SYN reçu, ACK final attendu) et celle des connexions établies que l’application n’a pas encore acceptées, dont la taille est bornée par le paramètre backlog et, sous Linux, par net.core.somaxconn. Si l’application n’accepte pas assez vite, la file déborde et les nouveaux clients subissent des délais, alors que le serveur semble en bonne santé.

Fenêtres, RTT et performance

Le récepteur annonce une fenêtre : la quantité de données qu’il accepte sans acquittement. C’est le contrôle de flux, qui protège le destinataire. Le champ ne fait que 16 bits (65 535 octets) ; l’option de mise à l’échelle (window scaling, RFC 7323) l’étend jusqu’à 1 Gio.

Le débit maximal d’une connexion vaut à peu près fenêtre divisée par RTT. Avec une fenêtre de 64 Kio et un RTT de 100 ms, le plafond est de 65 536 × 8 / 0,1 ≈ 5,2 Mbit/s, quelle que soit la capacité du lien. Pour remplir un lien de 1 Gbit/s à 100 ms, il faut une fenêtre égale au produit débit-délai : 10⁹ × 0,1 / 8 = 12,5 Mo. C’est pourquoi un transfert transatlantique rampe sur une fibre pourtant vide, et pourquoi la moindre perte coûte cher sur longue distance.

Sécurité et performance

Congestion et longue distance

Le contrôle de congestion protège le réseau, et non le destinataire. L’émetteur tient une fenêtre de congestion : démarrage lent (slow start) qui la double à chaque RTT, puis croissance prudente, et réduction à chaque perte détectée. Le débit effectif est borné par le minimum des deux fenêtres. Sous Linux, l’algorithme par défaut est CUBIC (RFC 9438), qui interprète la perte comme signal de congestion ; BBR (Bottleneck Bandwidth and Round-trip propagation time), proposé par Google en 2016, estime plutôt le débit du goulot et le RTT minimal, et résiste mieux aux pertes non liées à la congestion. L’algorithme actif se lit avec sysctl net.ipv4.tcp_congestion_control.

SYN flood

Un attaquant envoie des SYN en rafale, souvent avec des adresses source usurpées, et ne termine jamais la poignée de main. La file des connexions à moitié ouvertes se remplit et les clients légitimes ne passent plus. La parade principale est le SYN cookie : quand la file déborde, le serveur encode l’état de la connexion dans son numéro de séquence initial et ne réserve rien tant que l’ACK final n’est pas revenu (net.ipv4.tcp_syncookies, activé par défaut sur les distributions courantes).

Usurpation UDP et amplification

Comme UDP ne vérifie pas l’expéditeur, un attaquant peut envoyer une petite requête en usurpant l’adresse de sa victime vers un service qui répond beaucoup plus gros. Le facteur d’amplification est le rapport entre la taille de la réponse et celle de la requête : quelques dizaines pour un résolveur DNS ouvert interrogé en ANY, plusieurs centaines pour l’ancienne commande monlist de NTP, et des valeurs bien supérieures pour memcached exposé en UDP sur le port 11211, utilisé en 2018 dans une attaque de 1,35 Tbit/s contre GitHub. Les remèdes sont connus : ne pas exposer ces services à tout internet, limiter le débit des réponses, et appliquer chez les opérateurs le filtrage des adresses source usurpées décrit par le BCP 38 (RFC 2827).

Épuisement de ports

Une machine qui ouvre beaucoup de connexions sortantes vers la même destination (un proxy, une passerelle NAT, un client d’API) est limitée par sa plage éphémère : avec la plage Linux par défaut, environ 28 000 connexions simultanées par couple adresse et port de destination, TIME-WAIT compris. Au-delà, les nouvelles connexions échouent avec une erreur d’adresse indisponible. On élargit la plage, on réutilise les connexions (keep-alive applicatif, pools) ou on multiplie les adresses source.

Keepalive et timeouts

Le keepalive TCP envoie des sondes sur une connexion inactive pour vérifier que l’autre extrémité existe encore. Sous Linux, les valeurs par défaut sont lentes : première sonde après 7 200 secondes, puis 9 sondes espacées de 75 secondes. Or un pare-feu ou une passerelle NAT oublie souvent une connexion inactive en quelques minutes ; une connexion longue et silencieuse (base de données, session SSH) meurt alors sans que les deux extrémités le sachent, et le premier paquet suivant reçoit un RST ou se perd. Régler le keepalive applicatif en deçà de la temporisation du pare-feu évite ces coupures mystérieuses.

Transport, pare-feu et journaux

Un pare-feu à états suit précisément les états TCP : il n’accepte un segment que s’il appartient à une connexion connue. Ses journaux, tout comme ceux du noyau, distinguent tentatives refusées, connexions établies et réinitialisations. Un scan TCP classique (nmap -sS) envoie des SYN et classe les ports selon la réponse : SYN-ACK pour ouvert, RST pour fermé, rien pour filtré. Un scan UDP (nmap -sU) est beaucoup plus lent, faute de réponse fiable. Un port ouvert n’est pas pour autant un service légitime : seul l’inventaire dit si ce qui écoute devrait écouter.

Ateliers commentés

Capturer une poignée de main

sudo tcpdump -ni eth0 'tcp port 443 and (tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0)'
curl -sI https://exemple.org >/dev/null

La capture montre le SYN du client depuis un port éphémère, le SYN-ACK, puis plus tard les FIN ou un RST. Dans Wireshark, le filtre tcp.flags.syn == 1 isole les ouvertures et la colonne de temps entre SYN et SYN-ACK donne directement le RTT.

Distinguer refused, timeout et reset

nc -vz 192.0.2.10 8080     # "Connection refused" : RST immédiat
nc -vz -w 5 192.0.2.10 22  # silence pendant 5 s : filtrage ou route absente

Un SYN sans retour place le problème en aval ; un RST vient de la machine ou d’un équipement qui répond à sa place.

Lire les sockets

ss -tlnp                 # sockets TCP en écoute, avec le processus
ss -tan state time-wait | wc -l
ss -ti dst 192.0.2.10    # RTT, fenêtre de congestion, retransmissions

Sous Windows, netstat -ano donne l’équivalent avec l’identifiant de processus ; sous Linux, netstat a cédé la place à ss.

À ne pas confondre

TCP ne chiffre rien : la confidentialité vient de TLS (Transport Layer Security) posé au-dessus. Une connexion TCP n’est pas une session applicative : une session web survit à plusieurs connexions, et une connexion peut porter plusieurs requêtes. Enfin, contrôle de flux et contrôle de congestion se ressemblent mais ne protègent pas la même chose : le premier ménage le récepteur, le second le réseau.

🐝 Ce qui arrive si on s’en passe

Sans protection de la file des connexions à moitié ouvertes, quelques rafales de demandes jamais confirmées suffisent à rendre un service injoignable, alors que le serveur lui-même reste parfaitement en forme. Un service UDP laissé ouvert à tous sans limite devient un amplificateur au service d’attaques contre des tiers : c’est alors son adresse qui figure dans les signalements, et l’organisation découvre sa participation à une attaque par les plaintes qu’elle reçoit. Enfin, sans journaux au niveau transport, un délai dépassé et un refus se confondent dans les rapports, ce qui fait passer un filtrage malveillant pour une panne banale.

🦫 Explication de la marmotte 🍫

Deux protocoles de transport acheminent la plupart des données. UDP, le protocole de datagrammes utilisateur, envoie des messages indépendants, sans établir de connexion et sans confirmation : un message peut se perdre ou arriver dans le désordre, et rien ne le signale. Il sert à la résolution de noms, au temps réel, et à la découverte d’équipements. Comme aucun échange préalable ne vérifie l’expéditeur, son adresse peut être usurpée : un attaquant envoie une petite requête au nom de sa victime, et le serveur renvoie une grosse réponse vers elle, c’est l’amplification.

TCP, le protocole de contrôle de transmission, établit d’abord une connexion en trois messages : demande, acceptation, confirmation. Chaque morceau de données est numéroté, le destinataire accuse réception, et ce qui se perd est renvoyé. La fenêtre fixe la quantité de données envoyables avant un accusé de réception : le contrôle de flux protège le destinataire, le contrôle de congestion protège le réseau. Les ports identifient les services ; le client utilise un port temporaire. Une socket associe adresse et port.

Face à une tentative de connexion, trois réactions se distinguent : un refus immédiat si aucun service n’écoute, un délai dépassé si un filtre avale la demande, une réinitialisation si la connexion est coupée. Une rafale de demandes jamais confirmées remplit la file d’attente des connexions en cours et bloque les clients légitimes. Une machine qui ouvre trop de connexions peut aussi épuiser ses ports temporaires. TCP ne chiffre rien.

À lire aussi

• Données, signaux, latence et fiabilitéExpliquer comment une donnée devient un signal transmis, puis comment mesurer ce que le réseau fait subir aux échanges : délai, débit, perte, gigue et erreurs.
• Suivre un flux de bout en boutApprendre à raconter un échange complet depuis une action utilisateur jusqu’au service distant, en distinguant nom, adresse, chemin, transport, chiffrement et réponse applicative.
• Nmap pour cartographier un réseau, des hôtes aux services exposésFiche de l'outil nmap, de la découverte d'hôtes à la détection de services, avec ce qu'un scan révèle, ce qu'un pare-feu fausse, comment le défenseur s'en sert et comment un scan se détecte.
• Couches, normes et vocabulaire de paquetsConstruire le vocabulaire nécessaire pour lire une communication réseau : couche, protocole, encapsulation, trame, paquet, segment, datagramme, message et plans réseau.

Pages voisines

La citent

• Couches, normes et vocabulaire de paquets
• WireGuard et VPN maillés, fonctionnement, AllowedIPs et limites
• Nmap pour cartographier un réseau, des hôtes aux services exposés
• Pare-feu, architectures et NAT en une page

UDP, TCP et comportements de transport

Elle cite

• QUIC, HTTP moderne, TLS et proxys applicatifs