Couche 4 : TCP, UDP et les ports — le guide complet

Quatrième étage, et un changement de nature. Jusqu’ici, tout ce qu’on a construit — le câble, les adresses MAC, l’IP et le routage — partage un aveu, celui sur lequel s’est terminé l’article précédent : le réseau ne promet rien. Un paquet IP peut être perdu, dupliqué, ou arriver dans le désordre. IP fait au mieux et s’en lave les mains.

Pourtant, votre fichier de 4 Go arrive intact. Votre page web s’affiche dans le bon ordre. Votre apt upgrade ne télécharge jamais un paquet à moitié corrompu sans s’en apercevoir.

Ce miracle a un étage : la couche 4. C’est ici qu’on répond à deux questions que les couches du dessous ignorent superbement :

1. Ce paquet, il est pour quelle application ? Le port.
2. Est-ce qu’on garantit l’arrivée, ou pas ? TCP contre UDP.

L’essentiel en 30 secondes

• IP livre à une machine. La couche 4 livre à une application. Le port est le numéro d’appartement.
• Une connexion, c’est 4 valeurs : IP source, port source, IP dest, port dest. C’est ce quadruplet qui l’identifie, pas le seul port.
• TCP promet (arrivée, ordre, intégrité). UDP ne promet rien — et c’est parfois exactement ce qu’on veut.
• Le three-way handshake (SYN, SYN-ACK, ACK) n’échange aucune donnée. Il se met d’accord sur les numéros de séquence.
• TIME_WAIT n’est pas un bug. Un serveur qui en a des milliers, c’est normal. C’est même sain.
• Le port n’est pas une sécurité : un service sur un port « discret » se trouve en une passe de scan.
• ss -tulpn remplace netstat. Apprenez-le.

Le port : à quelle application livrer ?

La couche 3 sait amener un paquet jusqu’à 192.168.1.50. Bien. Mais sur cette machine tournent un serveur web, un serveur SSH, un serveur de mail et trois autres choses. Le paquet est pour lequel ?

IP n’en a aucune idée — ce n’est pas son travail. Il faut un deuxième niveau d’adressage, à l’intérieur de la machine. C’est le port : un nombre sur 16 bits, donc de 0 à 65535.

L’analogie qui tient : l’adresse IP est l’immeuble, le port est le numéro d’appartement. Le facteur (IP) vous amène au bon immeuble ; l’interphone (le port) désigne la bonne porte. Sans le numéro d’appartement, le courrier arrive dans le hall et n’y trouve personne.

Les 65536 ports se répartissent en trois zones (IANA) :

Le détail qui a des conséquences de sécurité concrètes : sous Unix, ouvrir un port sous 1024 exige les droits root. C’est pour ça qu’un serveur web tourne démarré en root (pour saisir le port 80) puis abandonne ses privilèges aussitôt après. Et c’est pour ça qu’une application non privilégiée écoute sur 8080 plutôt que 80 : elle n’a pas le droit d’en faire moins.

Les ports à connaître par cœur

Un TSSR les reconnaît sans réfléchir — ils tombent en diagnostic, en règle de pare-feu, en lecture de logs.

Le 53 est particulier et mérite qu’on s’y arrête, parce qu’il illustre toute la suite : le DNS utilise UDP pour les requêtes ordinaires (rapide, une question une réponse) mais bascule sur TCP pour les réponses volumineuses et les transferts de zone. Un même service, les deux transports, choisis selon le besoin. Retenez-le : ça revient dès qu’on débogue un DNS, et ça surprend toujours celui qui n’a ouvert que l’UDP sur son pare-feu.

Une connexion, ce n’est pas un port — c’est quatre valeurs

Voici l’erreur mentale la plus répandue sur la couche 4, et la corriger débloque tout le reste.

On dit « la connexion sur le port 443 ». C’est un raccourci trompeur. Une connexion n’est pas identifiée par un port, mais par un quadruplet (le 4-tuple) :

  IP source  +  port source  +  IP dest  +  port dest
192.168.1.10 :    51234       93.184.x.x :    443

C’est la combinaison des quatre qui identifie une connexion de façon unique. Conséquence directe, et elle règle une question que tout le monde se pose un jour :

Comment un serveur web gère-t-il des milliers de clients sur le seul port 443 ?

Parce que le port destination (443) est le même pour tous, mais le couple IP source + port source diffère à chaque client. Le serveur ne voit pas « 5000 connexions sur le 443 » ; il voit 5000 quadruplets distincts. Le port 443 n’est pas un goulot — c’est juste une des quatre coordonnées.

C’est aussi ce qui explique le fonctionnement du PAT vu à la couche 3 : le routeur peut multiplexer des milliers de conversations derrière une seule IP publique précisément parce qu’il joue sur le port source pour les distinguer.

TCP contre UDP : deux philosophies

Le cœur de la couche 4 n’est pas « deux protocoles ». C’est deux réponses opposées à une même question : faut-il garantir la livraison ?

TCP répond oui, et en paie le prix. UDP répond non, et en récolte les bénéfices. Aucun des deux n’a raison dans l’absolu — ils répondent à des besoins différents.

L’analogie de la dernière ligne est la plus utile. TCP est un appel téléphonique : on décroche, on vérifie qu’on s’entend (« allô ? — oui je t’entends »), on parle en sachant que l’autre suit, on raccroche proprement. UDP est une carte postale : on l’écrit, on la poste, et on ne saura jamais si elle est arrivée — mais c’est instantané et ça ne coûte presque rien.

Quand UDP, sans garantie, est le bon choix

Le réflexe du débutant est « TCP c’est fiable donc TCP c’est mieux ». Faux, et voici pourquoi.

Prenez un appel vidéo. Un paquet d’image se perd. Avec TCP, le protocole s’arrêterait pour le retransmettre — et le temps qu’il arrive, il serait vieux d’une demi-seconde. Vous auriez une image parfaite… mais figée, saccadée, en retard sur le son. Avec UDP, le paquet perdu est simplement abandonné, l’image a un micro-défaut d’un seizième de seconde que personne ne remarque, et le flux continue en temps réel.

Pour tout ce qui est temps réel, la fraîcheur prime sur l’exactitude. Une donnée en retard vaut moins qu’une donnée manquante. C’est le domaine d’UDP : voix (VoIP), vidéo, jeu en ligne, DNS (une requête, une réponse, pas besoin d’établir une conversation), et la supervision (SNMP, syslog — si un log se perd, tant pis, on ne va pas ralentir la production pour ça).

Le tableau de décision, une fois pour toutes :

Le three-way handshake : se mettre d’accord avant de parler

TCP « oriente connexion ». Concrètement, ça veut dire qu’avant d’échanger la moindre donnée utile, les deux parties négocient. Cette négociation, c’est le fameux three-way handshake, en trois temps.

Trois drapeaux de l’en-tête TCP entrent en jeu : SYN (synchronize, j’ouvre), ACK (acknowledge, j’accuse réception), et plus tard FIN (finish, je ferme).

CLIENT                                      SERVEUR
   │                                           │
   │  ──────────  SYN (seq=x)  ─────────────▶  │   « je veux parler, mon compteur démarre à x »
   │                                           │
   │  ◀────  SYN-ACK (seq=y, ack=x+1)  ──────  │   « d'accord, le mien démarre à y, j'ai bien reçu x »
   │                                           │
   │  ──────────  ACK (ack=y+1)  ───────────▶  │   « bien reçu y — on est synchronisés »
   │                                           │
   │  ═══════════  connexion établie  ═══════  │

Le point que tout le monde rate : ce handshake n’échange aucune donnée utile. Pas un octet du fichier, pas une lettre de la requête HTTP. Il ne sert qu’à une chose — se mettre d’accord sur les numéros de séquence de départ (x et y), tirés aléatoirement de chaque côté.

Pourquoi ces numéros comptent-ils autant ? Parce que ce sont eux qui permettent, ensuite, de remettre les segments dans l’ordre et de détecter les manquants. Chaque octet envoyé est numéroté ; le récepteur accuse réception en disant « j’ai tout jusqu’à N, envoie la suite ». C’est le mécanisme entier de la fiabilité TCP qui se met en place ici, dans ces trois messages. Sans handshake, pas de numéros communs ; sans numéros communs, pas de fiabilité.

Le tirage aléatoire des numéros de départ n’est pas cosmétique non plus : s’ils étaient prévisibles, un attaquant pourrait injecter des segments dans une connexion existante en devinant le prochain numéro. C’est une vieille faille (l’IP spoofing de la couche 3 devient inoffensif sur TCP précisément parce qu’on ne peut plus deviner la séquence). L’aléatoire est une mesure de sécurité.

La fermeture : quatre temps, et un fantôme

Fermer une connexion TCP est plus subtil que l’ouvrir, parce que chaque sens se ferme indépendamment. Il faut quatre messages (FIN, ACK, FIN, ACK) : chaque partie annonce « j’ai fini d’émettre » de son côté, et l’autre en accuse réception.

Et il reste, après la fermeture, un état qui déroute tous les débutants : TIME_WAIT. On y revient plus bas, parce qu’il génère à lui seul une quantité déraisonnable de fausses alertes.

Les états d’une connexion TCP

Une connexion TCP est une machine à états. Chaque connexion, à tout instant, est dans un état précis — et savoir les lire, c’est savoir diagnostiquer. C’est exactement ce que vous affiche ss ou netstat.

Les états qu’il faut reconnaître :

Deux états sont des outils de diagnostic à eux seuls.

SYN-RECV en grande quantité → quelqu’un envoie des SYN sans jamais compléter le handshake. C’est la signature exacte du SYN flood (plus bas). Une pile de SYN-RECV qui gonfle, c’est une attaque en cours, ou un réseau qui perd les ACK.

CLOSE-WAIT qui s’accumule → et là, c’est presque toujours votre application qui a un bug. CLOSE-WAIT signifie « l’autre bout a fermé la connexion, et mon programme n’a toujours pas appelé close() ». Des centaines de CLOSE-WAIT figés = une application qui fuit ses sockets, qui ne ferme pas ce qu’elle ouvre. Ce n’est pas un problème réseau : c’est un problème de code. Ce diagnostic-là vaut de l’or, parce qu’il pointe le coupable du doigt alors que tout le monde accuse le réseau.

TIME_WAIT : le faux problème le plus courant du métier

Il mérite sa propre section, parce que je l’ai vu déclencher des tickets « urgents » qui n’auraient jamais dû exister.

Quand vous fermez une connexion (côté qui envoie le premier FIN), elle ne disparaît pas. Elle passe en TIME_WAIT et y reste typiquement 60 secondes (2× le MSL — Maximum Segment Lifetime). Pendant ce temps, le quadruplet reste réservé.

Pourquoi cette attente ? Pour deux raisons solides :

1. Un segment retardataire de la connexion qui vient de se fermer pourrait encore traîner dans le réseau. TIME_WAIT garantit qu’il sera reconnu comme appartenant à l’ancienne connexion, et non injecté par erreur dans une nouvelle qui réutiliserait le même quadruplet.
2. Si le dernier ACK se perd, l’autre bout retransmettra son FIN — et il faut que notre côté soit encore là pour y répondre.

Le faux problème : un serveur web très sollicité affiche des milliers de connexions en TIME_WAIT. Un admin le découvre, panique, et cherche à « corriger ». Il n’y a rien à corriger. C’est le signe d’un serveur qui travaille, qui ouvre et ferme proprement des connexions à haute cadence. TIME_WAIT est la preuve d’une fermeture correcte, pas d’une fuite.

Le seul cas où ça devient un vrai sujet, c’est l’épuisement des ports éphémères côté client, quand une seule machine initie des dizaines de milliers de connexions sortantes vers la même destination (un proxy, un load balancer qui tape un backend). Là, on ajuste — tcp_tw_reuse sous Linux, ou du connection pooling côté application, qui est la vraie solution. Mais on ne « désactive » pas TIME_WAIT : on arrête d’ouvrir autant de connexions.

Retenez la formule : TIME_WAIT côté serveur est un symptôme de bonne santé. Ne le soignez pas.

Contrôle de flux et de congestion : les deux freins de TCP

TCP ne se contente pas de garantir l’arrivée. Il régule le débit, avec deux mécanismes qu’on confond systématiquement parce qu’ils font tous les deux ralentir — mais pour des raisons opposées.

Le contrôle de flux protège le récepteur. Un serveur costaud qui envoie à fond peut noyer un client modeste dont le tampon de réception déborde. TCP l’empêche via la fenêtre de réception (receive window) : à chaque ACK, le récepteur annonce « il me reste tant de place, ne dépasse pas ». L’émetteur s’adapte. C’est une conversation entre les deux bouts, sur la capacité du destinataire à encaisser.

Le contrôle de congestion protège le réseau. Là, le problème n’est pas le récepteur mais tout ce qu’il y a entre les deux : les routeurs, les liens, la bande passante partagée. TCP n’a aucun moyen direct de connaître l’état du réseau — alors il le déduit de la perte de paquets. Un paquet perdu = le réseau est probablement saturé = je ralentis. C’est la fameuse logique slow start puis congestion avoidance : on accélère prudemment, et à la moindre perte, on lève le pied brutalement.

La distinction, en une phrase : le contrôle de flux, c’est « mon interlocuteur suit-il ? » ; le contrôle de congestion, c’est « la route est-elle saturée ? ». Deux freins, deux capteurs différents.

Cette mécanique a une conséquence de terrain énorme et contre-intuitive : une perte de paquets légère détruit le débit TCP de façon disproportionnée. Parce que TCP interprète chaque perte comme un signal de congestion et ralentit, un lien qui perd « seulement » 1 à 2 % des paquets peut voir son débit s’effondrer bien au-delà de ces 2 %. C’est le lien direct avec la couche 1 : un câble médiocre, un connecteur mal serti, une paire détorsadée, ne se traduisent pas par « un peu plus lent ». Ils se traduisent par un débit TCP en chute libre, sans le moindre message d’erreur. Le voyant est éteint, mais le moteur cale. C’est pour ça qu’on ne néglige jamais la couche 1 : elle remonte vous hanter en couche 4.

L’en-tête TCP, vite fait

Pour situer les mécanismes dans le paquet :

┌────────────────────┬────────────────────┐
│    Port source     │    Port dest       │
├────────────────────┴────────────────────┤
│         Numéro de séquence               │
├──────────────────────────────────────────┤
│      Numéro d'acquittement (ACK)         │
├──────┬──────────────┬────────────────────┤
│ Offs │ URG ACK PSH  │   Fenêtre          │
│      │ RST SYN FIN  │  (contrôle de flux)│
├──────┴──────────────┼────────────────────┤
│      Checksum        │  Pointeur urgent  │
└──────────────────────┴────────────────────┘

Les drapeaux (flags) sont les commandes de la connexion. Cinq à connaître :

• SYN — ouvre (handshake).
• ACK — accuse réception. Présent sur quasiment tous les segments après le premier.
• FIN — ferme proprement.
• RST — ferme brutalement. « Cette connexion n’existe pas / n’est plus valide, dégage. » C’est le RST qu’on reçoit en tapant un port fermé qui refuse activement, par opposition au silence d’un port filtré par un pare-feu — distinction capitale pour le scan, juste en dessous.
• PSH — « pousse ces données à l’application tout de suite, n’attends pas ».

Le comportement RST vs silence est l’un des diagnostics les plus utiles du métier : un port fermé répond par un RST (« personne n’écoute, mais je suis là ») ; un port filtré par un pare-feu ne répond rien (le paquet est jeté en silence). C’est la différence entre « connection refused » (immédiat) et « connection timed out » (après une longue attente). Le premier vous dit « le service est éteint » ; le second vous dit « un pare-feu te bloque ». Deux messages radicalement différents, et c’est exactement là-dessus que joue un scanner de ports.

La sécurité de la couche 4

Même refrain que les couches précédentes, appliqué au transport.

Le scan de ports

Le principe : avant d’attaquer, on fait l’inventaire. Un scan de ports envoie des sondes sur une plage de ports et écoute les réponses, en exploitant précisément la distinction RST / silence vue plus haut.

Les grands classiques, avec nmap :

• SYN scan (-sS, dit half-open) — envoie un SYN, observe la réponse (SYN-ACK = ouvert ; RST = fermé), et ne complète jamais le handshake. La connexion n’est pas établie, donc souvent pas journalisée par l’application. Discret, rapide, la référence.
• Connect scan (-sT) — établit la connexion complète. Plus bruyant, mais ne nécessite pas les privilèges root.
• UDP scan (-sU) — le parent pauvre, lent et incertain, parce qu’UDP ne répond pas « ouvert ». On déduit l’état de l’absence de réponse ou d’un ICMP port unreachable (le type 3 code 3 de la couche 3 — tout se recoupe).

La parade réaliste : on ne « bloque » pas un scan, on réduit la surface. Le vrai principe, c’est que le port n’est pas une sécurité — mettre SSH sur 2222 au lieu de 22 ne le cache de personne, un scan complet le trouve en quelques secondes. Ce qui protège, dans l’ordre : fermer tout ce qui n’a pas à être ouvert (un service qui n’écoute pas ne se scanne pas), un pare-feu à états qui n’autorise que le nécessaire, et de l’authentification forte sur ce qui reste exposé. Le port discret ralentit les bots opportunistes qui ne scannent que le 22 ; c’est du confort de logs, pas de la sécurité.

Le SYN flood

Le principe : l’attaquant exploite le handshake lui-même. Il envoie des milliers de SYN, souvent avec une IP source usurpée, et ne renvoie jamais l’ACK final. Chaque SYN oblige le serveur à allouer des ressources et à ouvrir une connexion à moitié établie (l’état SYN-RECV vu plus haut), en attendant un ACK qui ne viendra pas. La table de connexions se remplit de fantômes, et le serveur finit par refuser les vraies connexions. C’est un déni de service.

Sa signature est limpide : une montagne de SYN-RECV. Vous savez maintenant la lire.

La parade : les SYN cookies. L’idée est astucieuse — plutôt que de stocker chaque connexion à moitié ouverte (ce qui est précisément la ressource qu’on épuise), le serveur encode l’état de la connexion dans le numéro de séquence qu’il renvoie dans le SYN-ACK, calculé cryptographiquement. Il n’alloue rien. Si un vrai ACK revient, le numéro qu’il contient permet de reconstruire l’état ; s’il ne revient jamais (le cas du flood), aucune ressource n’a été gaspillée. Le serveur devient insensible au flood parce qu’il a cessé de mémoriser ce qu’on cherche à saturer.

sysctl -w net.ipv4.tcp_syncookies=1     # activé par défaut sur les Linux modernes

C’est activé par défaut à peu près partout aujourd’hui — mais savoir pourquoi ça marche, c’est comprendre le handshake pour de bon.

Le RST spoofing (reset injection)

Le principe : puisque le drapeau RST tue une connexion sur-le-champ, quelqu’un capable d’injecter un segment avec le bon quadruplet et un numéro de séquence plausible peut couper des connexions à volonté. C’est utilisé pour de la censure (couper les connexions vers certains sites) et du sabotage.

Ce qui rend l’attaque difficile aujourd’hui : il faut deviner le numéro de séquence courant, qui est aléatoire et se déplace vite. Ce qui rend l’attaque impossible pour de bon : le chiffrement de bout en bout (TLS), qui ne rend pas la connexion TCP inviolable — un RST bien placé la coupe toujours — mais garantit qu’on ne pourra pas injecter des données dans le flux. Contre la coupure pure, la vraie réponse est applicative : reconnexion automatique, QUIC (qui tourne sur UDP et gère sa propre session, échappant au RST TCP), et supervision.

La boîte à outils

Ce qui tombe en mise en situation, et ce qui sert tous les jours.

Voir qui écoute et qui est connecté

ss -tulpn        # LA commande. t=tcp u=udp l=listen p=process n=numérique
ss -tan          # toutes les connexions TCP, états compris
ss -s            # statistiques résumées par état
netstat -tulpn   # l'ancêtre — encore partout, mais ss est plus rapide

ss -tulpn est la commande à avoir dans les doigts. Elle répond d’un coup à « quels services écoutent, sur quels ports, et quel processus les porte ». C’est le premier réflexe pour « ce port est-il ouvert ? » et « qu’est-ce qui tourne sur cette machine ? ». Le p (processus) est ce qui la rend indispensable : elle ne dit pas seulement que le port 8080 est ouvert, elle dit quel programme l’a ouvert.

Sous Windows, l’équivalent :

netstat -abno            # -b montre l'exécutable, -o le PID
Get-NetTCPConnection     # la version PowerShell

Compter les états — le diagnostic express

ss -tan | awk '{print $1}' | sort | uniq -c | sort -rn

Cette ligne compte les connexions par état. Une avalanche de SYN-RECV → SYN flood ou perte d’ACK. Des CLOSE-WAIT qui s’empilent → une application qui fuit ses sockets. Des milliers de TIME_WAIT → un serveur qui bosse, rien à faire. Trois diagnostics dans une seule ligne de commande, et c’est souvent la première que je tape sur un serveur qui « rame sans raison ».

Tester un port depuis l’extérieur

nc -zv 192.168.1.50 443          # netcat : le port 443 est-il ouvert ?
nc -zvu 192.168.1.50 53          # -u pour tester un port UDP
curl -v telnet://192.168.1.50:22 # voir la bannière du service
telnet 192.168.1.50 25           # la vieille méthode, toujours efficace

nc -zv (netcat) est le test « ce port répond-il ? » réduit à l’essentiel. Combiné au diagnostic RST/silence : une réponse immédiate = ouvert ou activement refusé ; un long silence avant timeout = un pare-feu vous jette. La durée de l’échec est une information.

Scanner (sur SON réseau uniquement)

nmap -sS 192.168.1.0/24          # SYN scan du sous-réseau
nmap -sV 192.168.1.50            # identifier les versions des services
nmap -p- 192.168.1.50            # les 65535 ports, exhaustif

Rappel qui n’est pas juridique pour rien : scanner un réseau qui n’est pas le vôtre, sans autorisation écrite, est répréhensible. nmap sur votre infra perso : formez-vous. nmap sur autre chose : ne le faites pas.

Observer le trafic

tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0'   # tous les SYN — voir les ouvertures
tcpdump -i eth0 'tcp[tcpflags] & tcp-rst != 0'   # tous les RST — voir les refus
tcpdump -i eth0 port 443                          # tout le trafic d'un port

Filtres Wireshark :

tcp.flags.syn == 1 && tcp.flags.ack == 0    # les SYN d'ouverture uniquement
tcp.flags.reset == 1                         # les RST — qui coupe quoi ?
tcp.analysis.retransmission                  # ← les retransmissions : de la perte quelque part
tcp.port == 443

Le filtre tcp.analysis.retransmission est un bijou de diagnostic. Wireshark détecte tout seul les segments retransmis. Beaucoup de retransmissions = de la perte sur le chemin, donc (on l’a vu) un débit qui s’effondre. C’est le lien visible entre « ça rame » et « la couche 1 ou 3 perd des paquets ». Quand un utilisateur dit « le réseau est lent » et que tout semble normal, ce filtre montre la vérité.

Les erreurs classiques

• Croire qu’une connexion = un port — c’est un quadruplet. C’est pour ça qu’un serveur tient des milliers de clients sur un seul port.
• Penser que TCP est toujours mieux qu’UDP — pour le temps réel, la garantie de TCP est un défaut, pas une qualité.
• Vouloir « corriger » TIME_WAIT — côté serveur, c’est un signe de bonne santé. Le vrai sujet, c’est l’épuisement de ports côté client.
• Ignorer CLOSE-WAIT — c’est presque toujours un bug applicatif (socket non fermée), pas un problème réseau.
• Confondre contrôle de flux et de congestion — l’un protège le récepteur, l’autre le réseau.
• Croire qu’un port discret est une sécurité — SSH sur 2222 se trouve en une passe de scan. Ce qui protège, c’est de fermer, filtrer, authentifier.
• N’ouvrir que l’UDP 53 pour le DNS — les grosses réponses et les transferts de zone passent en TCP.
• Confondre « connection refused » et « timed out » — le premier est un RST (service éteint), le second un silence (pare-feu). Deux diagnostics opposés.
• Utiliser encore netstat — ss fait la même chose en plus rapide. Reléguez netstat aux machines où ss manque.

En pratique : ce que je retiens

1. IP livre à une machine, la couche 4 livre à une application. Le port est le numéro d’appartement.
2. Une connexion est un quadruplet, pas un port. Toute la scalabilité des serveurs en découle.
3. TCP promet, UDP assume de ne rien promettre. Le bon choix dépend du besoin — pour le temps réel, UDP gagne.
4. Le handshake ne transporte pas de données : il synchronise les numéros de séquence. C’est là que naît la fiabilité.
5. Les états se lisent. SYN-RECV en masse = attaque ou perte ; CLOSE-WAIT en masse = bug applicatif ; TIME_WAIT en masse = serveur en bonne santé.
6. RST vs silence : refus actif contre filtrage. « refused » et « timed out » ne veulent pas dire la même chose.
7. Une perte de paquets légère effondre le débit TCP — et renvoie directement à la qualité de la couche 1.
8. ss -tulpn et le comptage d’états répondent à eux seuls à la majorité des « ça rame sans raison ».

La couche 4 sait donc livrer à la bonne application, dans l’ordre, sans perte. On a maintenant un tuyau fiable entre deux programmes.

Mais un tuyau d’octets fiable, ce n’est pas encore une conversation qui a du sens. « GET /index.html », « 220 mail.exemple.fr ESMTP », un certificat TLS qu’on négocie : tout ça vit au-dessus, dans les couches qui donnent enfin un sens aux octets qu’on s’est donné tant de mal à transporter.

C’est le haut de la pile. Prochains articles.