Couche 4 du modèle OSI (transport) : TCP, UDP et ports expliqués

TL;DRLa couche transport fait le lien entre le réseau et les programmes : elle choisit le bon port et décide si la livraison doit être garantie. Voici TCP, UDP, QUIC et les ports expliqués simplement, avec des commandes à essayer et un relevé réel sur websource.fr.

📌 La couche transport en une phrase#

La couche 4 (layer 4) du modèle OSI, la couche transport, organise le dialogue entre deux programmes qui tournent sur deux machines. La couche 3 (layer 3) sait amener un paquet jusqu'au bon ordinateur grâce à son adresse IP ; la couche 4 l'amène jusqu'au bon programme sur cet ordinateur, grâce à un numéro de port, et décide du niveau de garantie de la livraison.

Deux protocoles dominent cette couche sur Internet : TCP, qui garantit que tout arrive, dans l'ordre, et UDP, qui envoie vite, sans garantie.

Le modèle OSI (ISO/IEC 7498-1, ITU-T X.200) est un modèle de référence ; Internet repose en pratique sur le modèle TCP/IP (RFC 1122). Pour une fois, les deux se correspondent bien : TCP et UDP sont des protocoles de transport dans l'un comme dans l'autre.

📌 Segments, datagrammes et ports#

📌 Le nom des morceaux#

À la couche 4, TCP découpe le flux en segments, et UDP envoie des datagrammes. Chaque segment ou datagramme porte un petit en-tête, puis est glissé dans un paquet IP, lui-même transporté dans une trame par la couche 2 (layer 2), puis converti en signaux par la couche 1 (layer 1).

📌 Le port : le numéro de porte du programme#

L'adresse IP est l'adresse de l'immeuble ; le port est le numéro du bureau. Un même serveur peut héberger un site web, une messagerie et une base de données : chacun « écoute » sur son propre port. Un port est un nombre compris entre 0 et 65535, écrit dans l'en-tête TCP ou UDP, avec un port source et un port de destination.

Une connexion TCP est identifiée par quatre valeurs (IP et port du client, IP et port du serveur) : vos onglets ouverts sur un même site ne se mélangent donc pas.

📌 Bien connus, enregistrés, éphémères#

L'IANA, l'organisme qui gère les numéros d'Internet, tient le registre officiel des ports. La RFC 6335 découpe la plage en trois zones :

• 0 à 1023, les ports système (dits « bien connus ») : attribués aux grands services, comme 80 pour HTTP ou 443 pour HTTPS. Sur Linux, seul un programme privilégié peut les ouvrir.
• 1024 à 49151, les ports utilisateur (dits « enregistrés ») : déclarés auprès de l'IANA pour des logiciels précis, comme 3306 pour MySQL.
• 49152 à 65535, les ports dynamiques (ou « éphémères ») : jamais attribués, ils servent de port source temporaire au client le temps d'une connexion.

En pratique, chaque système choisit sa plage éphémère. Sur notre serveur Linux, le réglage net.ipv4.ip_local_port_range vaut 32768 60999, la valeur par défaut du noyau Linux : elle ne coïncide pas avec celle recommandée par la RFC 6335.

📌 TCP : la livraison garantie#

TCP, aujourd'hui décrit par la RFC 9293, est un protocole orienté connexion : avant d'échanger la moindre donnée, les deux machines se mettent d'accord.

📌 La poignée de main en trois temps#

1. SYN : le client demande l'ouverture d'une connexion et annonce son numéro de séquence de départ.
2. SYN-ACK : le serveur accepte, accuse réception et annonce son propre numéro de départ.
3. ACK : le client confirme. La connexion est ouverte, les données peuvent circuler dans les deux sens.

Cet échange coûte un aller-retour réseau avant le premier octet utile ; c'est pourquoi les navigateurs réutilisent une connexion ouverte pour plusieurs requêtes.

📌 Fiabilité, ordre et retransmission#

Chaque octet envoyé porte un numéro de séquence. Le destinataire renvoie des accusés de réception (ACK) indiquant jusqu'où il a tout reçu. Si un accusé n'arrive pas à temps, l'émetteur retransmet le segment manquant. Le destinataire, lui, remet les segments dans l'ordre avant de les transmettre au programme. Résultat : une page web ou un e-mail arrivent complets, même si le réseau a perdu ou mélangé des paquets.

📋 Contrôle de flux et contrôle de congestion#

• Le contrôle de flux protège le destinataire : il annonce une « fenêtre », la quantité de données qu'il peut encore recevoir. L'émetteur ne la dépasse pas, pour ne pas noyer un appareil plus lent.
• Le contrôle de congestion protège le réseau : l'émetteur commence prudemment, accélère tant que tout va bien, et ralentit dès qu'il détecte des pertes, signe que la route est saturée (RFC 5681). C'est ce qui permet à de nombreuses connexions de partager les mêmes liens.

À la fin, la connexion se ferme proprement par un échange de segments FIN, ou brutalement par un segment RST, celui que vous recevez quand vous contactez un port fermé.

📌 UDP : envoyer sans attendre#

UDP, défini par la RFC 768, est sans connexion : pas de poignée de main, pas d'accusé de réception, pas de retransmission, pas de remise en ordre. Il ajoute les ports et une somme de contrôle, puis envoie. Si un datagramme se perd, c'est à l'application de s'en occuper, ou de l'ignorer.

C'est un avantage quand la rapidité compte plus que la perfection :

• Le DNS : traduire un nom de domaine en adresse tient le plus souvent en une question et une réponse. Ouvrir une connexion TCP pour cela serait plus long que l'échange lui-même. Le DNS utilise donc UDP sur le port 53, et TCP pour les réponses volumineuses.
• La voix et la visioconférence : une syllabe arrivée en retard ne sert plus à rien. Mieux vaut un micro-blanc qu'une conversation qui se décale.
• Les jeux en ligne et la vidéo en direct : seule l'information la plus récente compte ; renvoyer l'ancienne serait inutile.

📌 QUIC : le transport moderne bâti sur UDP#

QUIC, normalisé en 2021 par la RFC 9000, reprend les garanties de TCP (fiabilité, ordre, contrôle de congestion) mais les implémente au-dessus d'UDP, en intégrant directement le chiffrement TLS 1.3. Il ouvre la connexion plus vite et évite qu'un paquet perdu bloque tous les échanges en cours. QUIC sert de base à HTTP/3 (RFC 9114) : quand votre navigateur charge un site en HTTP/3, il utilise donc le port 443 en UDP, et non en TCP. Ce cas montre que la frontière entre les couches est parfois floue : QUIC assure un travail de couche 4 tout en s'appuyant sur un autre protocole de couche 4.

📌 TCP ou UDP : le comparatif#

📌 Les ports courants à connaître#

Pour aller plus loin sur trois d'entre eux, consultez nos articles sur le port 80, le port 443 et le port MySQL 3306.

📌 Pare-feu et filtrage par port#

La plupart des pare-feu raisonnent en couche 4 : ils autorisent ou bloquent le trafic selon le protocole (TCP ou UDP) et le numéro de port. La règle la plus saine consiste à tout refuser par défaut en entrée, puis à n'ouvrir que les ports nécessaires : 80 et 443 pour un site, 22 pour l'administration, idéalement réservé à quelques adresses.

Votre box internet fait de même : rien n'entre depuis Internet sauf si vous créez une « redirection de port », pour une caméra par exemple. Chaque port ouvert est une porte de plus à surveiller.

Bon à savoir : une base de données comme MySQL n'a presque jamais besoin d'être joignable depuis Internet. Quand le site et la base sont sur le même serveur, la base peut n'écouter que sur l'adresse locale 127.0.0.1, invisible de l'extérieur. Fermer un port vaut mieux que le protéger par un mot de passe.

📌 Le répartiteur de charge de couche 4#

Un répartiteur de charge peut, lui aussi, travailler en couche 4. Il ne voit que des adresses IP, des ports et des connexions, et envoie chaque connexion entière vers l'un des serveurs. C'est simple, rapide, compatible avec tout protocole (bases de données, messagerie) et sans déchiffrer le TLS. Pour router selon l'adresse demandée, il faut au contraire un répartiteur de couche 7 (layer 7). Notre article sur le load balancing compare les deux approches.

📌 Ce que l'on observe sur websource.fr#

🌐 Les ports qui écoutent sur notre serveur#

La commande ss liste les sockets ouverts. Avec les options -t (TCP), -l (en écoute) et -n (numéros plutôt que noms), elle montre les ports qui attendent des connexions :

$ ss -tln
State   Recv-Q  Send-Q  Local Address:Port  Peer Address:Port
LISTEN  0       511                 *:443              *:*
LISTEN  0       511                 *:80               *:*
LISTEN  0       511         127.0.0.1:6379       0.0.0.0:*
...

Relevé le 22 octobre 2026, sortie volontairement abrégée. On y retrouve notamment les ports 22, 25, 587, 80, 443 et 993 du tableau ci-dessus. La colonne Local Address est la plus instructive : *:443 accepte les connexions sur toutes les adresses du serveur, tandis que Redis (port 6379) n'écoute que sur 127.0.0.1, donc uniquement pour les programmes du serveur lui-même. Pour UDP, utilisez ss -uln.

📌 Une connexion TCP en direct#

L'outil nc (netcat) avec l'option -z tente seulement la poignée de main TCP, sans rien envoyer :

$ nc -vz www.websource.fr 443
Connection to www.websource.fr (2606:4700:3033::6815:2272) 443 port [tcp/https] succeeded!

« succeeded » signifie que les trois temps SYN, SYN-ACK et ACK ont abouti : quelque chose écoute bien sur le port 443 en TCP. L'adresse affichée appartient à Cloudflare, notre proxy : c'est avec lui que la connexion TCP s'établit. Sur un port fermé, vous obtiendriez « Connection refused », la traduction du segment RST.

Pour voir la suite, curl -v détaille chaque étape :

$ curl -v -o /dev/null https://www.websource.fr/
*   Trying [2606:4700:3033::6815:2272]:443...
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
...
* Connected to www.websource.fr (...) port 443
* ALPN: server accepted h2
< HTTP/2 200

La ligne Trying ...:443 correspond à l'ouverture de la connexion TCP. Viennent ensuite la négociation TLS, puis la réponse HTTP, empilées sur cette connexion de couche 4.

📌 Bien héberger, c'est aussi bien ouvrir ses ports#

Ports ouverts au strict nécessaire, accès SSH maîtrisé : ces réglages de couche 4 font partie du travail d'un hébergeur. Websource héberge un grand nombre de sites et accompagne ses clients dès la commande. Nos offres d'hébergement web démarrent dès 4,99 € HT/mois, avec le premier mois offert.

Dans le prochain article de la série, nous monterons d'un cran avec la couche 5 (layer 5), la couche session, l'une des plus difficiles à distinguer dans le modèle TCP/IP.

❓ Questions fréquentes#

📌 Quelle est la différence entre TCP et UDP ?#

TCP établit une connexion avant d'envoyer et garantit que les données arrivent complètes et dans l'ordre, en retransmettant ce qui se perd. UDP envoie directement, sans connexion ni garantie, ce qui le rend plus rapide pour le DNS, la voix ou les jeux.

📌 À quoi sert un port réseau ?#

Un port désigne le programme destinataire sur une machine. L'adresse IP amène les données jusqu'au serveur, le port les remet au bon service : 443 pour le site en HTTPS, 587 pour l'envoi d'e-mails, 3306 pour MySQL.

📌 Qu'est-ce qu'un port éphémère ?#

C'est un port temporaire choisi par votre ordinateur comme port source quand il ouvre une connexion vers un serveur. Il est libéré à la fin de la connexion. La RFC 6335 recommande la plage 49152 à 65535, mais Linux utilise par défaut 32768 à 60999.

📌 HTTP/3 utilise-t-il TCP ou UDP ?#

HTTP/3 repose sur QUIC, qui fonctionne au-dessus d'UDP. Un site en HTTP/3 utilise donc le port 443 en UDP, alors que HTTP/1.1 et HTTP/2 utilisent le port 443 en TCP.

🌐 Comment savoir quels ports sont ouverts sur mon serveur Linux ?#

La commande ss -tln liste les ports TCP en écoute, et ss -uln les ports UDP. Regardez la colonne de l'adresse locale : 127.0.0.1 signifie que le service n'est joignable que depuis le serveur lui-même.

Article publié le 04/11/2026 sous la signature de Jonathan Gutierrez, rédigé à partir des sources citées ci-dessus, puis relu avant publication. Une information vous semble inexacte ou datée ? Signalez-le nous, nous corrigeons.