Protocoles TCP/IP : couches, ports et fonctionnement

Les protocoles TCP/IP désignent la famille de protocoles qui fait circuler les données sur Internet et sur la plupart des réseaux locaux : IP adresse et achemine les paquets, TCP et UDP les remettent aux applications, et des dizaines de protocoles comme DNS, HTTP, ARP ou ICMP s’appuient dessus. Le nom vient des deux protocoles historiques de la suite, TCP (RFC 793, aujourd’hui RFC 9293) et IP (RFC 791), normalisés en 1981 et adoptés par l’ARPANET le 1er janvier 1983.

Sommaire

Une suite de protocoles, pas un seul

« TCP/IP » n’est pas un protocole, c’est un nom de famille. Le terme officiel est Internet Protocol Suite, et il regroupe tout ce qu’une machine doit savoir faire pour envoyer un paquet à une autre machine qu’elle ne voit pas directement. IP (RFC 791 pour la version 4, RFC 8200 pour la version 6) donne une adresse à chaque interface et achemine les paquets de routeur en routeur. TCP (RFC 793 de 1981, remplacée par la RFC 9293 en 2022) et UDP (RFC 768) livrent ces paquets au bon programme sur la machine d’arrivée.

Le duo a donné son nom à l’ensemble parce qu’il a été le premier à fonctionner à grande échelle : l’ARPANET a basculé en TCP/IP le 1er janvier 1983, et tout ce qui a suivi, DNS, SMTP, HTTP, s’est construit par-dessus. La RFC 1122 de 1989 fixe ce qu’un hôte doit implémenter au minimum et décrit l’architecture en quatre couches encore utilisée aujourd’hui.

Confusion fréquente : le modèle OSI. OSI compte sept couches et sert de vocabulaire commun dans les cours et les fiches produit. TCP/IP en compte quatre et c’est lui qui tourne réellement dans votre noyau Linux, votre iPhone ou votre box. Quand un commercial parle de « couche 3 » ou de « couche 7 », il utilise la numérotation OSI pour désigner respectivement IP et les applications.

Les quatre couches et ce qu’on y trouve

Chaque couche encapsule la précédente : le message applicatif est glissé dans un segment TCP, le segment dans un paquet IP, le paquet dans une trame Ethernet. À la réception, chaque couche retire son en-tête et passe le reste à la suivante. Ce mécanisme explique pourquoi un paquet HTTP d’un seul octet pèse au minimum 40 octets sur le fil en IPv4 (20 octets d’en-tête IP plus 20 octets d’en-tête TCP), et pourquoi le MSS par défaut d’une connexion sur Ethernet est de 1460 octets : 1500 de MTU moins ces 40 octets.

ARP est un cas limite : il sert IP mais manipule des adresses MAC, et la RFC 1122 le range dans la couche liaison. ICMP, lui, voyage dans des paquets IP mais appartient à la couche Internet : un routeur qui renvoie « TTL exceeded » ne remonte jamais jusqu’au transport, c’est le noyau qui traite le message.

Couche (RFC 1122)	Rôle	Protocoles	Unité de donnée
Application	Dialogue entre programmes	HTTP, DNS, SMTP, SSH, TLS, DHCP	Message
Transport	Livraison au bon processus, fiabilité éventuelle	TCP, UDP, SCTP, QUIC (au-dessus d’UDP)	Segment ou datagramme
Internet	Adressage et routage de bout en bout	IPv4, IPv6, ICMP, ICMPv6, IGMP	Paquet
Liaison	Transmission sur le support physique	Ethernet, Wi-Fi 802.11, PPP, ARP, NDP	Trame

TCP ou UDP : la différence qui compte au quotidien

TCP ouvre une connexion avant d’envoyer quoi que ce soit. Le client émet un segment SYN, le serveur répond SYN-ACK, le client confirme par ACK : trois échanges, soit un aller-retour complet perdu avant le premier octet utile. En contrepartie, chaque octet est numéroté, acquitté et retransmis s’il manque, et la fenêtre de réception empêche d’écraser un destinataire lent. Le contrôle de congestion (RFC 5681, puis les algorithmes CUBIC et BBR) ralentit l’émetteur dès que le réseau perd des paquets.

UDP ne fait rien de tout cela. Son en-tête tient en 8 octets : port source, port destination, longueur, somme de contrôle. Pas de connexion, pas d’ordre, pas de retransmission. C’est l’application qui gère, ou qui accepte la perte. Le DNS, le DHCP, le NTP et la voix sur IP tournent sur UDP pour cette raison : une requête DNS tient dans un seul datagramme, l’alourdir d’un handshake n’a pas de sens. QUIC (RFC 9000), qui porte HTTP/3, est construit sur UDP et réimplémente la fiabilité en espace utilisateur précisément pour se passer du handshake TCP.

Critère	TCP	UDP
RFC	793, remplacée par 9293	768
En-tête minimal	20 octets	8 octets
Connexion	Oui, handshake en 3 segments	Non
Ordre et retransmission	Garantis par le protocole	À la charge de l’application
Usages typiques	HTTP/1.1, HTTP/2, SSH, SMTP, IMAP	DNS, DHCP, NTP, VoIP, QUIC et HTTP/3

Ports et sockets : comment les applications se retrouvent

Une adresse IP identifie une machine, pas un programme. Le port, un nombre de 16 bits entre 0 et 65535, désigne le processus qui écoute. Le quadruplet IP source, port source, IP destination, port destination identifie une connexion TCP de façon unique : c’est ce qu’on appelle un socket, et c’est pour cela qu’un serveur web peut servir des milliers de clients sur le seul port 443.

La RFC 6335 découpe l’espace en trois zones : 0 à 1023 pour les services système (sous Unix, il faut être root ou disposer de CAP_NET_BIND_SERVICE pour y écouter), 1024 à 49151 pour les services enregistrés à l’IANA, 49152 à 65535 pour les ports éphémères que le client tire au hasard. Linux ne suit pas exactement ce découpage : la plage par défaut de net.ipv4.ip_local_port_range va de 32768 à 60999, soit 28 232 ports sortants possibles vers une même destination. Un proxy très chargé peut les épuiser.

22/TCP : SSH
25/TCP : SMTP entre serveurs de messagerie
53/UDP et TCP : DNS, le TCP servant aux réponses tronquées et aux transferts de zone
67 et 68/UDP : DHCP, côté serveur puis côté client
80/TCP : HTTP en clair
123/UDP : NTP
443/TCP : HTTPS, et 443/UDP pour HTTP/3
3389/TCP : Bureau à distance (RDP)

Suivre une connexion à la main

Sur Linux, la commande ss -tan liste les sockets TCP avec leur état. Une ligne en LISTEN est un serveur qui attend, ESTAB une connexion active, SYN-SENT un client qui n’a pas reçu de réponse. Un serveur dont beaucoup de lignes restent en SYN-RECV subit peut-être un SYN flood. Les lignes TIME-WAIT sont normales : Linux conserve chaque connexion fermée 60 secondes pour absorber les segments retardataires.

Pour voir passer les paquets eux-mêmes, tcpdump -ni eth0 tcp port 443 affiche une ligne par segment. Un début de connexion ressemble à ceci :

IP 192.168.1.20.51234 > 93.184.216.34.443: Flags [S], seq 1180733212, win 64240, options [mss 1460,sackOK,wscale 7], length 0

Le drapeau [S] est le SYN, win 64240 la fenêtre annoncée, mss 1460 la taille maximale de segment. Si la ligne suivante est un [S.] venant du serveur, la connexion s’ouvre. Si vous voyez un [R.] à la place, le port est fermé : c’est le « connection refused » que renvoie votre client. Si rien ne revient et que le SYN est réémis après 1 s, 3 s puis 7 s, un pare-feu jette les paquets en silence. Trancher entre refusé et filtré est la première chose à établir avant d’ouvrir un ticket.

Dernier point, souvent négligé : ICMP. Bloquer tout ICMP sur un pare-feu casse la découverte de MTU de chemin, car le message type 3 code 4 (fragmentation needed) n’atteint plus jamais l’émetteur. Symptôme classique : la connexion TCP s’ouvre, les petites réponses arrivent, mais un gros transfert se fige au bout de quelques kilo-octets. Autoriser au moins les types 3 et 11 est le compromis raisonnable.

Testez vos connaissances

Quiz rapide Question 1 sur 3

Combien d’octets occupe l’en-tête minimal d’un segment TCP ?

Questions fréquentes

TCP/IP et le modèle OSI, est-ce la même chose ?

Non. OSI est un modèle de référence à sept couches publié par l’ISO, utile comme vocabulaire mais jamais déployé tel quel. TCP/IP est la pile réellement implémentée, décrite en quatre couches par la RFC 1122. Les deux se recouvrent : la couche Internet de TCP/IP correspond à la couche 3 OSI, le transport à la couche 4, et l’application de TCP/IP absorbe les couches 5 à 7.

Où se règlent les paramètres TCP/IP dans Windows ?

Dans ncpa.cpl (Connexions réseau), clic droit sur la carte, Propriétés, puis « Protocole Internet version 4 (TCP/IPv4) ». C’est là que se choisissent l’adresse fixe ou le DHCP et les serveurs DNS. La commande ipconfig /all affiche la configuration en cours, et netsh int ip reset réinitialise la pile TCP/IP quand une carte refuse d’obtenir une adresse ; un redémarrage est nécessaire ensuite.

Le DNS fonctionne-t-il en TCP ou en UDP ?

Les deux, sur le port 53. UDP est utilisé par défaut parce qu’une requête tient dans un datagramme. Le résolveur bascule en TCP quand la réponse dépasse la taille annoncée (512 octets sans EDNS) ou pour un transfert de zone AXFR. La RFC 7766 rend le support de TCP obligatoire pour tout serveur DNS. DNS over TLS (port 853) et DNS over HTTPS (port 443) sont eux toujours en TCP.

IPv6 remplace-t-il TCP/IP ?

Non, IPv6 est simplement la nouvelle version de la couche Internet de la même suite. TCP et UDP restent identiques, à un détail près : la somme de contrôle intègre un pseudo-en-tête IPv6. Comme l’en-tête IPv6 fait 40 octets au lieu de 20, le MSS sur Ethernet descend à 1440 octets. ARP disparaît au profit de NDP (RFC 4861), qui repose sur ICMPv6.

Comment vérifier que la pile TCP/IP fonctionne sur ma machine ?

Par paliers. ping 127.0.0.1 teste la pile elle-même sans toucher au réseau : si la loopback ne répond pas, le problème est logiciel. Ensuite ping de la passerelle pour valider la couche liaison et ARP, puis ping 1.1.1.1 pour valider le routage, et enfin ping d’un nom de domaine pour valider le DNS. Le premier palier qui échoue désigne la couche fautive.