Un segment TCP unique peut-il transporter deux requêtes HTTP ? Non — Voici pourquoi

Non. Un seul segment TCP ne peut pas transporter deux messages de requête HTTP distincts. C'est une propriété fondamentale de l'interaction HTTP/TCP.

Empilement protocolaire

Application: Requête HTTP 1 | Requête HTTP 2 | Requête HTTP 3 ...
Transport: Segment TCP 1 | Segment TCP 2 | Segment TCP 3 ...
Réseau: Paquet IP 1 | Paquet IP 2 | Paquet IP 3 ...

Pourquoi pas ?

1. Frontières messages HTTP ≠ Frontières segments TCP

• Messages HTTP sont unités couche application avec cadrage explicite (Content-Length, Transfer-Encoding: chunked)
• Segments TCP sont unités couche transport dimensionnées par MSS (Max Segment Size), MTU chemin, fenêtre congestion
• Une requête HTTP typique s'étale sur plusieurs segments TCP (ligne requête + en-têtes + corps > 1460 octets)
• Inversement, un segment TCP peut transporter parties de plusieurs messages HTTP seulement si pipelining + petits messages + algorithme Nagle alignent — mais jamais deux requêtes complètes et distinctes

2. Pipelining HTTP/1.1 (Contexte historique)

Clients pouvaient envoyer plusieurs requêtes sans attendre réponses (pipelining). Mais :

• Requêtes toujours envoyées séquentiellement sur le fil
• Segments TCP transportent octets, pas messages — frontières segments ne s'alignent pas sur frontières requêtes
• Pipelining déprécié cause head-of-line blocking ; retiré HTTP/2

3. HTTP/2 & HTTP/3 : Multiplexage, pas empaquetage segments

• HTTP/2 : Trames (HEADERS, DATA) multiplexées sur une connexion TCP. Trames de flux différents s'entrelacent. Toujours : trames ≠ segments TCP.
• HTTP/3 (QUIC) : Flux sur UDP. Paquets QUIC portent trames. Pas de TCP du tout.

4. Mathématiques MSS maximum

• MSS typique = 1460 octets (MTU Ethernet 1500 – 20 IP – 20 TCP)
• GET HTTP minimal : ~200 octets (tient dans un segment)
• Mais : Deux GET minimaux = 400 octets. Pourraient tenir dans un segment si algorithme Nagle les coalesce.
• Cependant : Ils restent deux messages HTTP distincts. Le segment transporte un flux d'octets contenant les deux. Le parseur HTTP récepteur les sépare via cadrage protocole — pas frontières segments.

La distinction critique

TCP est un protocole flux d'octets. Il livre octets ordonnés. HTTP est un protocole messages. Il définit frontières messages à l'intérieur de ce flux d'octets.

• Émetteur : Écrit octets requête HTTP dans socket → TCP les segmente arbitrairement
• Récepteur : TCP réassemble flux octets → Parseur HTTP trouve frontières messages (Content-Length / chunked)

Frontières segments sont invisibles pour HTTP. Ce sont optimisations transport, pas frontières sémantiques.

Implication pratique

Ne jamais concevoir logique applicative supposant « un segment = une requête » ou vice versa. Toujours parser HTTP par ses propres règles cadrage. Utiliser Content-Length ou Transfer-Encoding: chunked.

Exception : HTTP/1.0 sans Keep-Alive

Chaque requête sur nouvelle connexion → chaque connexion a ses propres segments TCP. Toujours : une requête → plusieurs segments typiquement.

En résumé : TCP segmente octets ; HTTP cadre messages. Ils opèrent à couches différentes avec frontières différentes.