TCP vs UDP : connexion, fiabilité, ordre, contrôle de congestion, en-tête, latence, usages

TCP et UDP sont deux protocoles de la couche transport qui fonctionnent au-dessus d’IP et utilisent des numéros de port pour identifier les applications. Avant d’envoyer des données, TCP établit une connexion par une poignée de main en trois temps ; il confirme la livraison par des acquittements (ACK), renvoie les données perdues et remet les données à l’application réceptrice dans l’ordre d’envoi. Il ajuste aussi la quantité envoyée à l’espace libre dans le tampon du récepteur (contrôle de flux) et à la congestion du réseau (contrôle de congestion). UDP ne fait rien de tout cela : il envoie simplement les données sous forme de datagrammes, si bien que son en-tête est petit et qu’il n’y a aucune attente avant l’envoi. On utilise TCP lorsque la fiabilité de la livraison compte, et UDP lorsque la faible latence compte et que l’application gère elle-même ce dont elle a besoin par ailleurs.

CritèreTCPUDP
Établissement de la connexionOrienté connexion : les données suivent une poignée de main en trois temps (SYN → SYN+ACK → ACK), d’où une attente initiale d’un aller-retour (RTT)Sans connexion : les données peuvent être envoyées immédiatement, sans établissement
Acquittement et renvoiLa livraison est confirmée par des ACK ; la perte est détectée par l’expiration d’un délai ou par des ACK dupliqués, et les données perdues sont renvoyéesNi acquittement ni renvoi ; les données perdues le restent
OrdreLes numéros de séquence servent à remettre les données en ordre et à les livrer dans l’ordre d’envoi ; les doublons sont supprimésLes données sont livrées dans l’ordre d’arrivée ; des inversions et des doublons peuvent survenir
Frontières des messagesUn flux d’octets sans frontières ; l’application décide où commencent et finissent les messagesChaque envoi devient un datagramme : les frontières des messages sont donc préservées
Contrôle de flux et de congestionOui : la fenêtre de réception empêche le débordement du tampon du récepteur, et la fenêtre de congestion adapte la quantité envoyée à la congestionAucun ; si nécessaire, l’application ajuste elle-même son débit d’envoi
Taille d’en-tête20 octets sans options (jusqu’à 60 octets avec options)8 octets (ports source et destination, longueur, somme de contrôle)
LatenceL’établissement de la connexion coûte un aller-retour ; après une perte, les données suivantes attendent aussi l’arrivée du renvoiNi établissement ni attente de renvoi, donc une faible latence, mais certaines données peuvent manquer
Types de destinatairesUn à un (unicast) uniquementUnicast, mais aussi diffusion (broadcast) et multicast
Usages typiquesLe web en HTTP/1.1 et HTTP/2, la diffusion vidéo sur HTTP, la messagerie (SMTP), SSH, le transfert de fichiersLes requêtes DNS, DHCP, le trafic temps réel comme les appels vocaux et la vidéo en direct, les jeux en ligne, et QUIC utilisé par HTTP/3

Les valeurs indiquées sont des ordres de grandeur typiques et varient selon la génération de procédé et le produit.

Quand choisir l'un ou l'autre ?

TCP
Lorsque des données manquantes ou désordonnées poseraient problème. C’est le choix par défaut de la plupart des applications : pages web, fichiers, messagerie, connexions aux bases de données, etc.
UDP
Pour le trafic temps réel, où mieux vaut perdre un peu que d’arriver en retard, et pour les échanges courts d’une seule requête et d’une seule réponse. Il sert aussi à la diffusion et au multicast, et lorsque l’application construit sa propre fiabilité, comme le fait QUIC.

Questions fréquentes

UDP n’étant pas fiable, faut-il l’éviter ?

Cela dépend de l’usage. Ce qu’UDP laisse de côté, ce sont la confirmation de livraison et le renvoi, l’ordre et l’ajustement du débit. Lorsque ces fonctions ne sont pas nécessaires, ou que l’application veut les gérer à sa façon, UDP convient bien. Dans un appel vocal, par exemple, un son qui arrive en retard est inutile : mieux vaut continuer qu’attendre un renvoi. Les applications qui envoient de grandes quantités de données sur UDP doivent toutefois contrôler elles-mêmes leur débit pour ne pas congestionner le réseau.

Pourquoi QUIC est-il construit au-dessus d’UDP ?

QUIC (RFC 9000) est un protocole de transport qui combine renvoi, ordre, contrôle de congestion et chiffrement TLS 1.3. Un protocole entièrement nouveau transporté directement sur IP passe souvent mal les NAT et les pare-feu du chemin, et devrait en outre attendre sa prise en charge par les systèmes d’exploitation. S’appuyer sur UDP lui permet de traverser les réseaux existants et d’être implémenté et mis à jour dans l’application. HTTP/3 fonctionne sur QUIC.

DNS n’utilise-t-il qu’UDP ?

Les requêtes de noms ordinaires utilisent le port UDP 53 et se font en une requête et une réponse. Lorsqu’une réponse est trop grande pour UDP, ainsi que pour les transferts de zone, on utilise TCP, et les implémentations DNS doivent aussi prendre en charge TCP (RFC 7766).

En quoi le contrôle de flux et le contrôle de congestion de TCP diffèrent-ils ?

Le contrôle de flux évite le débordement du tampon du récepteur : celui-ci annonce son espace libre sous forme de fenêtre de réception. Le contrôle de congestion évite de surcharger le réseau sur le chemin : l’émetteur déduit la congestion des pertes de paquets et de signes similaires, et agrandit ou réduit sa fenêtre de congestion. La quantité réellement envoyable est fixée par la plus petite des deux fenêtres.

Vérifier vos connaissances

Dans le modèle TCP/IP à 4 couches, à quelle couche appartiennent TCP et UDP ?

  1. ACouche application
  2. BCouche Internet
  3. CCouche transport
Afficher la réponse et l'explication

Réponse : C. Couche transport

Le modèle TCP/IP se décrit en 4 couches, de bas en haut : la couche liaison (couche d'accès réseau), la couche Internet, la couche transport et la couche application. TCP et UDP sont des protocoles de la couche transport ; ils utilisent les numéros de port pour distinguer à quelle application du terminal une communication est destinée. IP, dans la couche Internet, se charge d'acheminer les paquets d'un terminal à un autre. HTTP et DNS sont des protocoles de la couche application. Rapportée au modèle OSI, la couche transport correspond à la couche 4 et la couche Internet à la couche 3.

Quelle description d'UDP est correcte ?

  1. AIl n'établit pas de connexion et ne gère ni les retransmissions ni l'ordre des données ; son en-tête est donc petit et il n'y a aucune attente avant l'envoi
  2. BIl établit une connexion, retransmet les données qui ne sont pas arrivées et remet les données dans l'ordre côté récepteur
  3. CIl remet les données au terminal destinataire uniquement à l'aide des adresses MAC, sans adresses IP
Afficher la réponse et l'explication

Réponse : A. Il n'établit pas de connexion et ne gère ni les retransmissions ni l'ordre des données ; son en-tête est donc petit et il n'y a aucune attente avant l'envoi

UDP est un protocole léger qui ajoute seulement des numéros de port et une détection d'erreurs simple (somme de contrôle) au-dessus d'IP ; son en-tête fait 8 octets (celui de TCP, 20 octets sans options). Sans procédure de connexion, sans confirmation de réception ni retransmission, il sert aux appels vocaux et à la vidéo en direct, où une petite perte vaut mieux qu'un retard, ainsi qu'à DNS, qui se contente d'une seule requête et d'une seule réponse. Si la fiabilité est nécessaire, c'est l'application qui la fournit : QUIC, utilisé par HTTP/3, implémente par exemple les retransmissions et le chiffrement au-dessus d'UDP. L'établissement de connexion, les retransmissions et le contrôle de l'ordre relèvent de TCP.

Dans le three-way handshake (établissement en trois temps) qui ouvre une connexion TCP, quel est l'ordre correct des paquets échangés ?

  1. ASYN → ACK → FIN
  2. BACK → SYN → SYN+ACK
  3. CSYN → SYN+ACK → ACK
Afficher la réponse et l'explication

Réponse : C. SYN → SYN+ACK → ACK

Dans le three-way handshake, le client demande d'abord une connexion avec un SYN et annonce le premier numéro des données qu'il enverra (son numéro de séquence initial). Le serveur répond par un SYN+ACK : il en accuse réception (ACK) et annonce en même temps son propre numéro de séquence initial. Enfin, le client renvoie un ACK, et les deux sens de communication sont prêts. Confirmer les numéros dans les deux sens en 3 échanges évite par exemple des connexions erronées dues à d'anciens paquets arrivés en retard. Par conséquent, TCP a besoin d'au moins un temps aller-retour (RTT) avant que les données puissent commencer à circuler. FIN sert à fermer une connexion.

  1. Dans le contrôle de flux de TCP, à quoi sert l'annonce par le récepteur de sa taille de fenêtre (fenêtre de réception) à l'émetteur ?
  2. Quelle description de l'idée de base du contrôle de congestion de TCP est correcte ?
  3. Qu'est-ce qui amène un émetteur TCP à conclure qu'un segment a été perdu et à le retransmettre ?

Questions d'entraînement sur Bases des réseaux informatiques

Termes clés expliqués

Three-way handshake (établissement en trois temps)
Procédure qui établit une connexion TCP. 3 échanges, le SYN du client, le SYN+ACK du serveur et l'ACK du client, confirment le numéro de séquence initial de chaque partie.
Numéro de port
Nombre de 0 à 65535 utilisé par TCP et UDP pour indiquer à quelle application d'un terminal une communication est destinée. Les ports 0 à 1023, comme 80 pour HTTP, 443 pour HTTPS et 53 pour DNS, sont appelés ports bien connus (well-known ports).
Modèle OSI (modèle de référence OSI)
Modèle qui organise les fonctions de communication en 7 couches : physique, liaison de données, réseau, transport, session, présentation et application. Il sert de vocabulaire commun pour raisonner séparément sur le rôle de chaque couche.
DNS (Domain Name System)
Système, géré de façon distribuée par des serveurs du monde entier, qui associe des noms de domaine comme www.example.com aux adresses IP utilisées pour la communication.
DHCP (Dynamic Host Configuration Protocol)
Protocole qui attribue automatiquement, pour une durée limitée, aux terminaux qui se connectent à un réseau une adresse IP, un masque de sous-réseau, une passerelle par défaut, des serveurs DNS et d'autres paramètres.
TLS (Transport Layer Security)
Protocole qui chiffre la communication, détecte les falsifications et authentifie les serveurs à l'aide de certificats. HTTPS est HTTP protégé par TLS.
HTTP (Hypertext Transfer Protocol)
Protocole de la couche application qui sert à échanger du HTML, des images et des données entre un navigateur web et un serveur web, entre autres. Le client envoie une requête composée d'une méthode, d'une URL, d'en-têtes et d'un corps, et le serveur renvoie une réponse composée d'un code d'état, d'en-têtes et d'un corps. Le protocole est sans état : un état comme la connexion d'un utilisateur est conservé au moyen de cookies, entre autres. HTTP/1.1 utilise un format texte et des connexions persistantes, HTTP/2 multiplexe plusieurs flux sur une seule connexion TCP, et HTTP/3 utilise QUIC sur UDP. HTTP protégé par TLS s'appelle HTTPS.

Comparatifs associés