Un proxy direct ne conserve pas les frontières des segments TCP
Distinguez la segmentation TCP, les lectures de socket et le cadrage HTTP lorsque vous examinez le trafic de part et d’autre d’un proxy direct.
Supposons qu’une réponse HTTP apparaisse dans plusieurs segments TCP capturés après avoir traversé Squid. Cela peut être un comportement TCP ordinaire, et non la preuve que la réponse a été découpée incorrectement.
Un proxy direct possède normalement deux connexions :
client ⇄ TCP connection A ⇄ proxy ⇄ TCP connection B ⇄ originChaque connexion a son propre état TCP, ses numéros de séquence et sa paquétisation. Le proxy peut lire des données sur une connexion et les écrire sur l’autre sans conserver les tailles de segment d’origine. La mise en tampon, le moment d’envoi, la congestion et les limites de taille du chemin peuvent produire un autre regroupement.
Trois frontières à ne pas confondre
| Frontière | Ce qui la détermine |
|---|---|
| Segment TCP | Le chemin de transport et de réseau |
| Résultat d’une lecture de socket | Les octets disponibles du flux et le tampon de l’appelant |
| Message ou trame HTTP | Les règles de cadrage du protocole HTTP |
Une seule lecture peut contenir une partie d’en-tête, un en-tête entier suivi d’octets de corps, ou des données franchissant plus d’une frontière applicative. TCP ne rattache pas « fin de la réponse HTTP » à la fin d’une lecture réussie.
Un analyseur HTTP/1.1 accumule donc les en-têtes et applique les règles de cadrage du corps applicables, notamment la longueur, le codage de transfert ou la fermeture de connexion autorisée. Une trame HTTP/2 est une structure de protocole qui peut elle-même franchir des segments TCP ; ce n’est pas un autre nom pour un paquet réseau.
Un tunnel CONNECT réussi conserve le flux d’octets tunnellisé tout en utilisant encore deux segments TCP. Ses frontières de segment peuvent différer même lorsque le proxy n’a pas modifié les octets à l’intérieur du tunnel.
Lorsque vous enquêtez sur une corruption, comparez les données applicatives réassemblées. Comparer des nombres de paquets ou attendre des longueurs identiques des deux côtés demande à TCP une garantie de frontières qu’il n’offre pas.