Prednji proxy ne čuva granice TCP segmenata
Razdvojite TCP segmentaciju, čitanja soketa i HTTP uokviravanje kada pregledate saobraćaj sa obe strane prednjeg proxyja.
Pretpostavimo da se HTTP odgovor pojavi u nekoliko snimljenih TCP segmenata nakon prolaska kroz Squid. To može biti uobičajeno TCP ponašanje, a ne dokaz da je odgovor pogrešno podeljen.
Prednji proxy obično ima dve veze:
client ⇄ TCP connection A ⇄ proxy ⇄ TCP connection B ⇄ originSvaka veza ima sopstveno TCP stanje, redne brojeve i paketizaciju. Proxy može čitati podatke sa jedne veze i pisati ih na drugu bez čuvanja izvornih veličina segmenata. Baferisanje, vreme slanja, zagušenje i ograničenja veličine puta mogu proizvesti drugačije grupisanje.
Tri granice koje valja držati odvojeno
| Granica | Šta je određuje |
|---|---|
| TCP segment | Transportni i mrežni put |
| Rezultat čitanja soketa | Dostupni bajtovi toka i bafer pozivaoca |
| HTTP poruka ili okvir | Pravila uokviravanja HTTP protokola |
Jedno čitanje može sadržati deo zaglavlja, celo zaglavlje zajedno sa bajtovima tela ili podatke koji prelaze više od jedne granice aplikacionog nivoa. TCP ne vezuje „kraj HTTP odgovora“ za kraj uspešnog čitanja.
Zato HTTP/1.1 parser nakuplja zaglavlja i primenjuje važeća pravila uokviravanja tela, uključujući dužinu, prenosno kodiranje ili dozvoljeno zatvaranje veze. HTTP/2 okvir je protokolna struktura koja i sama može preći TCP segmente; to nije drugi naziv za mrežni paket.
Uspešan CONNECT tunel čuva tunelirani tok bajtova, ali i dalje koristi dve TCP deonice. Njegove granice segmenata mogu se razlikovati čak i kada proxy nije promenio bajtove unutar tunela.
Kada istražujete oštećenje, uporedite ponovo sastavljene aplikacione podatke. Poređenje broja paketa ili očekivanje identičnih dužina paketa sa obe strane traži od TCP-a garanciju granica koju on ne pruža.