Antaŭa prokura servilo ne konservas la limojn de TCP-segmentoj
Apartigu TCP-segmentadon, legadojn de ingo kaj HTTP-kadrigon kiam vi esploras trafikon ambaŭflanke de antaŭa prokura servilo.
Supozu, ke HTTP-respondo aperas en pluraj kaptitaj TCP-segmentoj post pasado tra Squid. Tio povas esti ordinara TCP-konduto, ne pruvo ke la respondo estis malĝuste dividita.
Antaŭa prokura servilo kutime havas du konektojn:
client ⇄ TCP connection A ⇄ proxy ⇄ TCP connection B ⇄ originĈiu konekto havas sian propran TCP-staton, sinsekvajn numerojn kaj paketadon. La prokura servilo povas legi datumojn el unu konekto kaj skribi ilin al la alia sen konservi la originajn segmentgrandojn. Bufrado, sendotempo, kongesto kaj la grandlimoj de la vojo povas produkti alian grupigon.
Tri limoj indaj je apartigo
| Limo | Kio ĝin difinas |
|---|---|
| TCP-segmento | La transporta kaj reta vojo |
| Rezulto de legado de ingo | La disponeblaj fluaj bajtoj kaj la bufro de la alvokanto |
| HTTP-mesaĝo aŭ -kadro | La kadrigaj reguloj de la HTTP-protokolo |
Unu legado povas enhavi parton de kaplinio, tutan kaplinion kune kun korpaj bajtoj, aŭ datumojn transirantajn pli ol unu limon de apliknivelo. TCP ne ligas “finon de HTTP-respondo” al la fino de sukcesa legado.
Tial HTTP/1.1-analizilo amasigas kapliniojn kaj aplikas la taŭgajn regulojn de korpa kadrigo, inkluzive longon, transportan kodadon aŭ permesitan fermon de la konekto. HTTP/2-kadro estas protokola strukturo, kiu mem povas transiri TCP-segmentojn; ĝi ne estas alia nomo por reta paketo.
Sukcesa CONNECT-tunelo konservas la tunelitan bajtfluon, sed ĝi ankoraŭ uzas du TCP-krurojn. Ĝiaj segmentlimoj povas diferenci eĉ kiam la prokura servilo ne ŝanĝis la bajtojn ene de la tunelo.
Kiam vi esploras difekton, komparu la rekunmetitajn aplikdatumojn. Kompari pakaĵkvantojn aŭ atendi identajn pakaĵlongojn ambaŭflanke petas de TCP limgarantion, kiun ĝi ne donas.