Ipagpalagay na ang isang tugon ng HTTP ay lumilitaw sa ilang nakuhang TCP segment pagkatapos dumaan sa Squid. Karaniwang pag-uugali iyon ng TCP, hindi patunay na mali ang paghahati ng tugon.

Karaniwang may dalawang koneksyon ang forward proxy:

client ⇄ TCP connection A ⇄ proxy ⇄ TCP connection B ⇄ origin

Bawat koneksyon ay may sariling estado ng TCP, mga sequence number at packetization. Maaaring magbasa ang proxy mula sa isang koneksyon at magsulat sa isa pa nang hindi pinapanatili ang orihinal na laki ng segment. Ang buffering, oras ng pagpapadala, siksikan at mga limitasyon sa laki ng landas ay maaaring gumawa ng ibang pagpapangkat.

Tatlong hangganan na dapat ihiwalay

HanggananAno ang tumutukoy dito
TCP segmentAng landas ng transport at network
Resulta ng pagbasa ng socketAng available na stream bytes at buffer ng tumatawag
Mensahe o frame ng HTTPAng mga tuntunin sa framing ng HTTP protocol

Ang isang pagbasa ay maaaring maglaman ng bahagi ng header, buong header kasama ang body bytes, o data na tumatawid sa higit sa isang hangganan sa antas ng aplikasyon. Hindi ikinakabit ng TCP ang «katapusan ng tugon ng HTTP» sa katapusan ng matagumpay na pagbasa.

Kaya ang HTTP/1.1 parser ay nag-iipon ng header at naglalapat ng angkop na mga tuntunin sa body framing, kabilang ang haba, transfer coding o pinapayagang pagsasara ng koneksyon. Ang HTTP/2 frame ay isang istruktura ng protocol na maaaring tumawid mismo sa mga TCP segment; hindi ito ibang pangalan para sa isang network packet.

Ang matagumpay na CONNECT tunnel ay nagpapanatili ng tunneled byte stream habang gumagamit pa rin ng dalawang binti ng TCP. Maaaring magkaiba ang mga hangganan ng segment nito kahit hindi binago ng proxy ang mga byte sa loob ng tunnel.

Kapag sinisiyasat ang pinsala, ihambing ang muling binuong application data. Ang paghahambing ng bilang ng packet o pag-asam ng parehong haba ng packet sa magkabilang panig ay humihingi sa TCP ng garantiya sa hangganan na hindi nito ibinibigay.

Kaugnay na mga artikulo