Framsendisproxy heldur ekki mörkum TCP-búta
Aðgreindu TCP-bútun, socketlestur og HTTP-rammagervið þegar þú skoðar umferð hvoru megin við framsendisproxy.
Gerum ráð fyrir að HTTP-svar birtist í nokkrum TCP-bútum sem voru handsamaðir eftir að hafa farið í gegnum Squid. Það getur verið venjuleg TCP-hegðun, en ekki sönnun þess að svarinu hafi verið skipt rangt.
Framsendisproxy hefur venjulega tvær tengingar:
client ⇄ TCP connection A ⇄ proxy ⇄ TCP connection B ⇄ originHver tenging hefur sitt eigið TCP-ástand, raðnúmer sín og pakkagerð. Proxyið getur lesið gögn úr einni tengingu og skrifað í hina án þess að varðveita upprunalegu bútastærðirnar. Biðminni, sendingartími, þrengsli og stærðarmörk leiðarinnar geta myndað aðra flokkun.
Þrjú mörk sem vert er að halda aðskildum
| Mark | Hvað ákvarðar það |
|---|---|
| TCP-bútur | Flutnings- og netleiðin |
| Niðurstaða socketlesturs | Tiltæk straumbyti og biðminni kallarans |
| HTTP-skilaboð eða rammi | Rammareglur HTTP-samskiptareglunnar |
Einn lestur getur innihaldið hluta hauss, heilan haus ásamt líkamsbytum eða gögn sem fara yfir fleiri en eitt mark á forritslaginu. TCP tengir ekki „endir HTTP-svars“ við enda á árangursríkum lestri.
Því safnar HTTP/1.1-þáttari hausum og beytir viðeigandi reglum um líkamsramma, þar á meðal lengd, flutningskóðun eða leyfðri lokun tengingar. HTTP/2-rammi er samskiptareglubygging sem getur sjálf farið yfir TCP-búta; hann er ekki annað heiti á netpakka.
Árangursrík CONNECT-göng halda varðveita tunnuðu býtastreymunni en nota enn tvo TCP-fætur. Bútamörk þess geta verið frábrugðin jafnvel þótt proxyið hafi ekki breytt bytunum inni í göngunum.
Þegar þú rannsakar skemmdir skaltu bera saman endursamsettu forritsgögnin. Að bera saman pakkafjölda eða búast við sömu pakkalengd beggja vegna krefst þess að TCP veiti mörk sem það veitir ekki.