Edastav puhverserver ei säilita TCP-segmentide piire
Eraldage TCP segmenteerimine, soketi lugemised ja HTTP raamimine, kui uurite liiklust edastava puhverserveri mõlemal poolel.
Oletame, et HTTP-vastus ilmub pärast Squidi läbimist mitmes jäädvustatud TCP-segmendis. See võib olla tavaline TCP käitumine, mitte tõestus, et vastus jagati valesti.
Edastaval puhverserveril on tavaliselt kaks ühendust:
client ⇄ TCP connection A ⇄ proxy ⇄ TCP connection B ⇄ originIgal ühendusel on oma TCP olek, järjekorranumbrid ja paketiseerimine. Puhverserver saab lugeda andmeid ühest ühendusest ja kirjutada need teise, säilitamata algseid segmendi suurusi. Puhverdamine, saatmise ajastus, ummikud ja tee suuruspiirangud võivad tekitada teistsuguse rühmituse.
Kolm piiri, mida tasub lahus hoida
| Piir | Mis seda määrab |
|---|---|
| TCP-segment | Transpordi- ja võrgutee |
| Soketi lugemise tulemus | Saadaolevad voo baidid ja kutsuja puhver |
| HTTP-sõnum või -raam | HTTP-protokolli raamimisreeglid |
Üks lugemine võib sisaldada osa päisest, tervet päist koos keha baitidega või andmeid, mis ületavad rohkem kui ühe rakenduskihi piiri. TCP ei seo „HTTP-vastuse lõppu“ eduka lugemise lõpuga.
Seetõttu kogub HTTP/1.1 parser päiseid ja rakendab asjakohaseid keha raamimise reegleid, sealhulgas pikkust, ülekandekodeeringut või lubatud ühenduse sulgemist. HTTP/2 raam on protokolli struktuur, mis võib ise TCP-segmente ületada; see ei ole võrgupaketi teine nimi.
Edukas CONNECT tunnel säilitab tunnelitatud baidivoo, kasutades siiski kahte TCP jalga. Selle segmendipiirid võivad erineda ka siis, kui puhverserver ei ole tunnelis olevaid baite muutnud.
Rikke uurimisel võrrelge uuesti kokku pandud rakenduse andmeid. Pakettide arvu võrdlemine või mõlemal poolel samade paketipikkuste ootamine nõuab TCP-lt piirigarantiid, mida see ei anna.