Ein vidaresendande proxy bevarar ikkje TCP-segmentgrenser
Skil TCP-segmentering, socket-lesingar og HTTP-innramming når du granskar trafikk på kvar side av ein vidaresendande proxy.
Tenk deg at ein HTTP-respons dukkar opp i fleire fanga TCP-segment etter å ha passert Squid. Det kan vere normal TCP-åtferd, ikkje prov på at responsen vart delt feil.
Ein vidaresendande proxy har vanlegvis to tilkoplingar:
client ⇄ TCP connection A ⇄ proxy ⇄ TCP connection B ⇄ originKvar tilkopling har sin eigen TCP-tilstand, sekvensnummer og pakking. Proxyen kan lese data frå éi tilkopling og skrive dei til den andre utan å ta vare på dei opphavlege segmentstorleikane. Bufring, sendetidspunkt, trengsel og storleiksgrenser i vegen kan gi ei anna gruppering.
Tre grenser det er verdt å halde skilde
| Grense | Kva som avgjer ho |
|---|---|
| TCP-segment | Transport- og nettverksvegen |
| Resultat av ei socket-lesing | Dei tilgjengelege strøymebytane og bufferen til kallaren |
| HTTP-melding eller -ramme | Innrammingsreglane til HTTP-protokollen |
Éi lesing kan innehalde ein del av ein header, ein heil header pluss body-byte, eller data som kryssar meir enn éi grense på applikasjonsnivå. TCP knyter ikkje «slutten på HTTP-responsen» til slutten av ei vellukka lesing.
Derfor samlar ein HTTP/1.1-parsar headarar og brukar dei gjeldande reglane for body-innramming, mellom anna lengd, overføringskoding eller tillaten lukking av tilkoplinga. Ei HTTP/2-ramme er ein protokollstruktur som sjølv kan krysse TCP-segment; det er ikkje eit anna namn for ein nettverkspakke.
Ein vellukka CONNECT-tunnel bevarar den tunna bytestraumen, men brukar framleis to TCP-bein. Segmentgrensene kan vere ulike sjølv når proxyen ikkje har endra byta inne i tunnelen.
Når du granskar korrupsjon, samanlikn dei gjenoppbygde applikasjonsdataa. Å samanlikne pakketal eller vente like pakkelengder på begge sider krev ei grensegaranti av TCP som han ikkje gir.