Suposem que una resposta HTTP apareix en diversos segments TCP capturats després de passar per Squid. Això pot ser un comportament normal de TCP, no una prova que la resposta s’hagi dividit incorrectament.

Un proxy directe normalment té dues connexions:

client ⇄ TCP connection A ⇄ proxy ⇄ TCP connection B ⇄ origin

Cada connexió té el seu propi estat TCP, números de seqüència i paquetització. El proxy pot llegir dades d’una connexió i escriure-les a l’altra sense conservar les mides originals dels segments. L’emmagatzematge en memòria intermèdia, el moment d’enviament, la congestió i els límits de mida del camí poden produir una agrupació diferent.

Tres fronteres que val la pena separar

FronteraQuè la determina
Segment TCPEl camí de transport i de xarxa
Resultat d’una lectura de socketEls bytes disponibles del flux i el búfer del cridador
Missatge o trama HTTPLes regles d’emmarcament del protocol HTTP

Una lectura pot contenir part d’una capçalera, una capçalera sencera amb bytes del cos o dades que travessen més d’una frontera de nivell d’aplicació. TCP no lliga «final de la resposta HTTP» al final d’una lectura correcta.

Per això un analitzador HTTP/1.1 acumula capçaleres i aplica les regles d’emmarcament del cos que corresponguin, incloent-hi la longitud, la codificació de transferència o el tancament de connexió permès. Una trama HTTP/2 és una estructura de protocol que pot travessar ella mateixa segments TCP; no és un altre nom per a un paquet de xarxa.

Un túnel CONNECT correcte conserva el flux de bytes tunelitzat tot i utilitzar dues potes TCP. Les seves fronteres de segment poden diferir fins i tot quan el proxy no ha canviat els bytes dins del túnel.

Quan investigueu una corrupció, compareu les dades d’aplicació reconstruïdes. Comparar recomptes de paquets o esperar longituds idèntiques a banda i banda demana a TCP una garantia de fronteres que no ofereix.

Articles relacionats