Le modèle TCP/IP et ses quatre couches

Le modèle TCP/IP organise les communications réseau en quatre couches : liaison, internet, transport et application. C'est le découpage décrit par la RFC 1122 d'octobre 1989, et celui que suit réellement votre machine, là où les sept couches du modèle OSI restent un vocabulaire de travail.

Sommaire

Quatre couches, pas sept

Votre navigateur émet une requête HTTP. Le noyau la découpe en segments TCP, leur attribue un numéro de séquence et un port source, puis passe le résultat à la pile IP qui choisit une route et ajoute les adresses source et destination. La carte réseau termine le travail en fabriquant une trame Ethernet portant les adresses MAC du saut suivant, pas celles du serveur final. Quatre traitements successifs, quatre couches.

Chaque couche ignore délibérément ce que fabrique celle du dessus.

Cette indifférence fait la solidité du modèle. IP ne sait pas s'il transporte une résolution DNS ou un flux vidéo, ce qui a permis de déployer QUIC (RFC 9000, mai 2021) sans reconfigurer un seul routeur de transit. Dans l'autre sens, TCP se comporte de la même façon sur fibre, sur 4G ou sur Wi-Fi puisqu'il ne voit jamais le support.

Le découpage remonte à l'article de Vint Cerf et Bob Kahn de 1974, où TCP et IP ne formaient encore qu'un seul protocole. La séparation en deux date de 1978, et l'ARPANET a basculé de NCP vers TCP/IP le 1er janvier 1983. La formalisation en quatre couches, elle, n'arrive qu'avec la RFC 1122.

Application : le protocole que manipule le logiciel, HTTP, DNS, SMTP, SSH. C'est la seule couche que voit un développeur la plupart du temps.
Transport : TCP (RFC 9293, qui remplace la RFC 793 depuis août 2022) pour un flux ordonné et fiable, UDP (RFC 768) pour l'envoi sec. Les deux identifient l'application par un port codé sur 16 bits, donc de 0 à 65535.
Internet : IPv4 (RFC 791) et IPv6 (RFC 8200) acheminent le paquet de bout en bout, avec le routage et la fragmentation. ICMP y vit aussi.
Liaison : Ethernet, 802.11, PPP. Elle ne sait livrer que sur le lien local, d'un équipement au voisin direct.

L’encapsulation : pourquoi 1460 octets de données pèsent 1514 sur le câble

Chaque couche ajoute son en-tête devant les données reçues de la couche supérieure, sans jamais y toucher. Une requête HTTP de 1460 octets devient un segment TCP de 1480 octets, puis un paquet IPv4 de 1500 octets, puis une trame Ethernet de 1514 octets telle que l'affiche tcpdump (le FCS de 4 octets est retiré par la carte avant remontée, la trame réelle sur le fil fait 1518 octets).

Soit 54 octets d'emballage minimum par paquet sur un lien Ethernet.

Ce calcul n'est pas académique : c'est lui qui fixe le MSS. Avec un MTU de 1500, un hôte IPv4 annonce dans son SYN un MSS de 1460 octets (1500 moins 20 d'en-tête IP moins 20 d'en-tête TCP). Derrière un accès PPPoE dont le MTU tombe à 1492, le MSS descend à 1452. Vous vérifiez la valeur négociée avec `ss -ti` sur une connexion active, ou en lisant le SYN dans une capture.

Couche	Unité	En-tête ajouté	Protocoles
Application	Données	Variable selon le protocole	HTTP, DNS, SMTP, SSH
Transport	Segment ou datagramme	20 octets (TCP sans option), 8 octets (UDP)	TCP, UDP
Internet	Paquet	20 octets (IPv4 sans option), 40 octets (IPv6)	IPv4, IPv6, ICMP
Liaison	Trame	14 octets + 4 octets de FCS (Ethernet)	Ethernet, 802.11, PPP

TCP/IP ou OSI : la confusion permanente

La question tombe à chaque formation réseau : pourquoi deux modèles ?

Le modèle OSI (ISO/IEC 7498-1, publié en 1984) a été conçu par un comité de normalisation avant d'avoir des protocoles à décrire, et sa pile propre n'a jamais percé. Le modèle TCP/IP fait l'inverse : il documente après coup ce qui tournait déjà sur ARPANET. La RFC 1122 le dit sans détour en énumérant quatre couches, sans couche physique séparée, sans session ni présentation.

Les couches 5 et 6 d'OSI n'ont donc aucun équivalent dédié côté TCP/IP. TLS en est l'illustration la plus fréquente : beaucoup le placent en couche 6 par analogie, alors qu'il s'exécute dans la couche application au-dessus d'un socket TCP ordinaire, port 443 compris. De la même façon, un pare-feu vendu comme étant de couche 7 filtre simplement sur le contenu applicatif.

Certains manuels enseignent un modèle hybride à cinq couches, qui scinde la liaison en physique et liaison de données. Il n'est normalisé nulle part, mais il est courant en cours.

Servez-vous de la correspondance ci-dessous pour parler la même langue que vos collègues, pas pour décrire la structure d'une pile logicielle.

Modèle OSI	Modèle TCP/IP (RFC 1122)	Exemple
7 Application, 6 Présentation, 5 Session	Application	HTTP, TLS, DNS
4 Transport	Transport	TCP, UDP
3 Réseau	Internet	IPv4, IPv6, ICMP
2 Liaison, 1 Physique	Liaison	Ethernet, 802.11

Diagnostiquer une panne en montant les couches

L'intérêt pratique du modèle tient là. Face à un service injoignable, vous ne testez pas au hasard : vous partez du bas et vous montez, en vous arrêtant à la première couche qui ne répond pas. Cinq commandes suffisent à couvrir la pile entière sur une machine Linux.

Un exemple qui revient souvent : `ping 8.8.8.8` répond en 12 ms, mais `curl https://api.exemple.fr` reste figé. La couche internet fonctionne, inutile de vérifier le câble ou la passerelle. Lancez `ss -tn state syn-sent` : si le socket reste bloqué en SYN-SENT, vos SYN partent et rien ne revient, c'est un filtrage sur le port 443 ou une route de retour absente. Si la connexion apparaît en ESTABLISHED mais qu'aucun octet ne circule, le problème est au-dessus, côté TLS, applicatif ou MTU.

Liaison : `ip link show` pour l'état de l'interface, `ip neigh` pour vérifier que la résolution ARP du voisin a abouti.
Internet : `ping` puis `traceroute -n` ou `mtr` pour localiser le saut qui perd les paquets.
Transport : `ss -tuln` pour les ports en écoute côté serveur, `nc -vz hote 443` pour tester l'ouverture depuis le client.
Application : `curl -v` ou `dig +trace`, qui montrent le dialogue protocolaire complet.
Vue globale : `tcpdump -ni eth0 tcp port 443 -c 20`, la seule façon de savoir ce qui sort vraiment de la machine.

Le cas MTU, quand la couche internet sabote la couche transport

Voici la panne qui met le mieux le modèle en défaut apparent. Un client se plaint : le site s'ouvre, la page d'accueil s'affiche, puis tout se fige dès qu'un contenu volumineux arrive. En SSH, la session s'établit, l'invite apparaît, et un `ls` sur un répertoire chargé gèle la console. Aucun message d'erreur, juste une attente qui se termine en timeout.

Le handshake passe parce qu'un SYN pèse 60 octets. Les gros paquets, eux, ne passent pas.

La cause tient dans la découverte du MTU de chemin. Un routeur intermédiaire ayant un MTU plus faible doit renvoyer un ICMP de type 3 code 4 (Fragmentation Needed) pour que l'émetteur réduise ses segments. Quand un pare-feu bloque l'ICMP en entrée par excès de zèle, ce message n'arrive jamais : l'émetteur continue d'envoyer du 1500 dans un tunnel qui n'accepte que 1400, et les paquets disparaissent en silence. On parle de trou noir PMTU.

Le test tient en une ligne : `ping -M do -s 1472 8.8.8.8` envoie exactement 1500 octets IP sans autoriser la fragmentation. Si la réponse arrive à 1472 mais pas à 1473, votre MTU utile est bien de 1500. Réduisez la taille jusqu'à trouver le seuil réel. Sur un routeur Linux qui fait suivre le trafic, le contournement classique consiste à forcer le MSS annoncé : `iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu`.

Questions fréquentes

Le modèle TCP/IP a-t-il 4 ou 5 couches ?

Quatre selon la RFC 1122, qui fait référence : application, transport, internet, liaison. La variante à cinq couches, enseignée par plusieurs manuels universitaires, sépare la couche liaison en physique et liaison de données pour se rapprocher d'OSI. Elle n'est normalisée par aucun texte de l'IETF, mais vous la croiserez en formation et en examen.

Quelle différence entre le modèle TCP/IP et la suite TCP/IP ?

Le modèle est le découpage en couches, une abstraction. La suite est l'ensemble concret des protocoles qui l'implémentent : IPv4, IPv6, TCP, UDP, ICMP, ARP, DNS, HTTP et quelques centaines d'autres. On dit aussi pile TCP/IP pour désigner le code qui tourne dans le noyau du système.

À quelle couche se situe HTTPS ?

À la couche application, comme HTTP. TLS n'est pas une couche du modèle TCP/IP : c'est un protocole applicatif qui ouvre un socket TCP classique sur le port 443, négocie ses clés, puis chiffre ce que HTTP y écrit. C'est pour cette raison qu'un routeur voit passer du HTTPS sans jamais pouvoir en lire le contenu.

Où se place ARP dans le modèle ?

Nulle part de façon nette, et c'est un cas connu. ARP traduit une adresse IP en adresse MAC, il travaille donc à cheval entre la couche internet et la couche liaison. La RFC 1122 le range dans la couche liaison. Sur un schéma de cours, on le dessine souvent entre les deux.

Pourquoi continuer à enseigner OSI si c’est TCP/IP qui tourne ?

Parce que le vocabulaire OSI est devenu la langue commune du métier. Un commutateur de couche 2, un équilibreur de charge de couche 4, un pare-feu de couche 7 : ces expressions viennent toutes d'OSI et restent utilisées quotidiennement. Le modèle TCP/IP décrit la réalité technique, OSI fournit les étiquettes.

Testez vos connaissances

Quiz rapide Question 1 sur 3

Combien de couches le modèle TCP/IP compte-t-il selon la RFC 1122 ?