Prednji proxy ne čuva granice TCP segmenata
Razdvojite TCP segmentaciju, čitanja soketa i HTTP uokviravanje kada pregledate saobraćaj s obje 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 podijeljen.
Prednji proxy obično ima dvije veze:
client ⇄ TCP connection A ⇄ proxy ⇄ TCP connection B ⇄ originSvaka veza ima vlastito TCP stanje, redne brojeve i paketizaciju. Proxy može čitati podatke s jedne veze i pisati ih na drugu bez čuvanja izvornih veličina segmenata. Baferiranje, vrijeme 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 bajti toka i bafer pozivaoca |
| HTTP poruka ili okvir | Pravila uokviravanja HTTP protokola |
Jedno čitanje može sadržavati dio zaglavlja, cijelo zaglavlje zajedno s bajtima tijela ili podatke koji prelaze više od jedne granice aplikacijskog nivoa. TCP ne veže „kraj HTTP odgovora“ za kraj uspješnog čitanja.
Zato HTTP/1.1 parser nakuplja zaglavlja i primjenjuje važeća pravila uokviravanja tijela, uključujući dužinu, prijenosno kodiranje ili dozvoljeno zatvaranje veze. HTTP/2 okvir je protokolna struktura koja i sama može prelaziti TCP segmente; to nije drugi naziv za mrežni paket.
Uspješan CONNECT tunel čuva tunelirani tok bajtova, ali i dalje koristi dvije TCP dionice. Njegove granice segmenata mogu se razlikovati čak i kada proxy nije promijenio bajte unutar tunela.
Kada istražujete oštećenje, uporedite ponovo sastavljene aplikacijske podatke. Poređenje broja paketa ili očekivanje identičnih dužina paketa s obje strane traži od TCP-a garanciju granica koju on ne pruža.