A továbbító proxy nem őrzi meg a TCP-szegmensek határait

Tegyük fel, hogy egy HTTP-válasz több rögzített TCP-szegmensben jelenik meg, miután áthaladt a Squidon. Ez lehet a TCP szokásos viselkedése, és nem bizonyítéka annak, hogy a választ hibásan osztották fel.

A továbbító proxynak általában két kapcsolata van:

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

Minden kapcsolatnak saját TCP-állapota, sorszámai és csomagolása van. A proxy az egyik kapcsolatból olvashat adatot, és a másikba írhatja, anélkül hogy megőrizné az eredeti szegmensméreteket. A pufferelés, a küldés időzítése, a torlódás és az útvonal méretkorlátai más csoportosítást eredményezhetnek.

Három határ, amelyet érdemes külön tartani

Egy olvasás tartalmazhatja egy fejléc egy részét, egy teljes fejlécet a törzs bájtjaival, vagy egynél több alkalmazásszintű határt átlépő adatot. A TCP nem kapcsolja a „HTTP-válasz végét” egy sikeres olvasás végéhez.

Ezért a HTTP/1.1 elemző fejléceket halmoz fel, és az alkalmazandó törzs-keretezési szabályokat alkalmazza, köztük a hosszt, az átviteli kódolást vagy a megengedett kapcsolatlezárást. A HTTP/2 keret olyan protokollszerkezet, amely maga is átléphet TCP-szegmenseket; nem a hálózati csomag másik neve.

A sikeres CONNECT-alagút megőrzi az alagutazott bájtfolyamot, miközben továbbra is két TCP-szakaszt használ. Szegmenshatárai akkor is eltérhetnek, ha a proxy nem változtatta meg az alagúton belüli bájtokat.

Sérülés vizsgálatakor hasonlítsa össze az újra összeállított alkalmazásadatokat. A csomagszámok összehasonlítása vagy azonos csomaghosszúságok elvárása mindkét oldalon olyan határgaranciát kér a TCPről, amelyet az nem ad.