En videresendende proxy bevarer ikke TCP-segmentgrænser
Skeln mellem TCP-segmentering, socket-læsninger og HTTP-indramning, når du undersøger trafik på hver side af en videresendende proxy.
Antag at et HTTP-svar optræder i flere opfangede TCP-segmenter, efter at det har passeret Squid. Det kan være normal TCP-adfærd og ikke bevis for, at svaret blev opdelt forkert.
En videresendende proxy har normalt to forbindelser:
client ⇄ TCP connection A ⇄ proxy ⇄ TCP connection B ⇄ originHver forbindelse har sin egen TCP-tilstand, sekvensnumre og pakkedannelse. Proxyen kan læse data fra den ene forbindelse og skrive dem til den anden uden at bevare de oprindelige segmentstørrelser. Buffering, sendetidspunkt, trængsel og stiens størrelsesgrænser kan give en anden gruppering.
Tre grænser, der er værd at holde adskilt
| Grænse | Hvad bestemmer den |
|---|---|
| TCP-segment | Transport- og netværksstien |
| Resultatet af en socket-læsning | De tilgængelige stream-bytes og kalderens buffer |
| HTTP-besked eller -ramme | HTTP-protokollens indramningsregler |
En enkelt læsning kan indeholde en del af en header, en hel header plus body-bytes eller data, der krydser mere end én grænse på applikationsniveau. TCP knytter ikke “slut på HTTP-svar” til slutningen af en vellykket læsning.
En HTTP/1.1-parser akkumulerer derfor headere og anvender de relevante regler for body-indramning, herunder længde, overførselskodning eller tilladt lukning af forbindelsen. En HTTP/2-ramme er en protokolstruktur, som selv kan krydse TCP-segmenter; det er ikke et andet navn for en netværkspakke.
En vellykket CONNECT-tunnel bevarer den tunnellerede bytestrøm, men bruger stadig to TCP-ben. Dens segmentgrænser kan være forskellige, selv når proxyen ikke har ændret bytes inde i tunnelen.
Sammenlign genopbyggede applikationsdata, når du undersøger korruption. At sammenligne pakketal eller forvente identiske pakkelængder på begge sider kræver en grænsegaranti af TCP, som den ikke giver.