En vidarebefordrande proxy bevarar inte TCP-segmentgränser
Skilj på TCP-segmentering, socket-läsningar och HTTP-inramning när du undersöker trafik på båda sidor av en vidarebefordrande proxy.
Anta att ett HTTP-svar dyker upp i flera fångade TCP-segment efter att ha passerat Squid. Det kan vara normalt TCP-beteende och inte bevis för att svaret delades fel.
En vidarebefordrande proxy har vanligtvis två anslutningar:
client ⇄ TCP connection A ⇄ proxy ⇄ TCP connection B ⇄ originVarje anslutning har sitt eget TCP-tillstånd, sina sekvensnummer och sin paketering. Proxyn kan läsa data från den ena anslutningen och skriva den till den andra utan att bevara de ursprungliga segmentstorlekarna. Buffring, sändningstidpunkt, trängsel och banans storleksgränser kan ge en annan gruppering.
Tre gränser som är värda att hålla isär
| Gräns | Vad som bestämmer den |
|---|---|
| TCP-segment | Transport- och nätverksbanan |
| Resultat av en socket-läsning | Tillgängliga strömbytes och anroparens buffert |
| HTTP-meddelande eller -ram | HTTP-protokollets inramningsregler |
En enda läsning kan innehålla en del av ett huvud, ett helt huvud plus body-bytes, eller data som korsar mer än en gräns på applikationsnivå. TCP knyter inte ”slutet på HTTP-svaret” till slutet av en lyckad läsning.
En HTTP/1.1-tolk samlar därför huvuden och tillämpar de regler för body-inramning som gäller, bland annat längd, överföringskodning eller tillåten stängning av anslutningen. En HTTP/2-ram är en protokollstruktur som själv kan korsa TCP-segment; det är inte ett annat namn för ett nätverkspaket.
En lyckad CONNECT-tunnel bevarar den tunnlade byteströmmen men använder fortfarande två TCP-ben. Dess segmentgränser kan skilja sig även när proxyn inte har ändrat byten inne i tunneln.
När du utreder korruption, jämför de återmonterade applikationsdata. Att jämföra paketantal eller förvänta sig identiska paketlängder på båda sidor begär en gränsgaranti av TCP som den inte ger.