En videresendende proxy bevarer ikke TCP-segmentgrenser
Skille TCP-segmentering, socket-lesinger og HTTP-innramming når du undersøker trafikk på hver side av en videresendende proxy.
Anta at en HTTP-respons dukker opp i flere fangede TCP-segmenter etter å ha passert Squid. Det kan være normal TCP-atferd, ikke bevis for at responsen ble delt feil.
En videresendende proxy har vanligvis to tilkoblinger:
client ⇄ TCP connection A ⇄ proxy ⇄ TCP connection B ⇄ originHver tilkobling har sin egen TCP-tilstand, sekvensnumre og pakking. Proxyen kan lese data fra én tilkobling og skrive dem til den andre uten å bevare de opprinnelige segmentstørrelsene. Bufring, sendetidspunkt, trengsel og stiens størrelsesgrenser kan gi en annen gruppering.
Tre grenser det er verdt å holde atskilt
| Grense | Hva som bestemmer den |
|---|---|
| TCP-segment | Transport- og nettverksstien |
| Resultatet av en socket-lesing | Tilgjengelige strømbytes og kallerens buffer |
| HTTP-melding eller -ramme | HTTP-protokollens innrammingsregler |
Én lesing kan inneholde en del av en header, en hel header pluss body-bytes, eller data som krysser mer enn én grense på applikasjonsnivå. TCP knytter ikke «slutt på HTTP-respons» til slutten av en vellykket lesing.
En HTTP/1.1-parser samler derfor headere og bruker de gjeldende reglene for body-innramming, blant annet lengde, overføringskoding eller tillatt lukking av tilkoblingen. En HTTP/2-ramme er en protokollstruktur som selv kan krysse TCP-segmenter; det er ikke et annet navn for en nettverkspakke.
En vellykket CONNECT-tunnel bevarer den tunnelerte bytestrømmen, men bruker fortsatt to TCP-ben. Segmentgrensene kan være forskjellige selv når proxyen ikke har endret bytene inne i tunnelen.
Når du undersøker korrupsjon, sammenlign de gjenoppbygde applikasjonsdataene. Å sammenligne pakketall eller forvente identiske pakkelengder på begge sider krever en grensegaranti av TCP som den ikke gir.