’n Voorspelende proxy bewaar nie TCP-segmentgrense nie
Skei TCP-segmentering, socket-lees en HTTP-raamwerk wanneer jy verkeer aan weerskante van ’n voorspelende proxy ondersoek.
Veronderstel ’n HTTP-antwoord verskyn in verskeie opgeneemde TCP-segmente nadat dit deur Squid gegaan het. Dit kan gewone TCP-gedrag wees, en nie ’n bewys dat die antwoord verkeerd verdeel is nie.
’n Voorspelende proxy het gewoonlik twee verbindings:
client ⇄ TCP connection A ⇄ proxy ⇄ TCP connection B ⇄ originElke verbinding het sy eie TCP-toestand, volgordenommers en pakkettering. Die proxy kan data van die een verbinding lees en na die ander skryf sonder om die oorspronklike segmentgroottes te bewaar. Buffering, stuurtydsberekening, oorbelasting en die roete se groottelimiete kan ’n ander groepering lewer.
Drie grense wat apart gehou moet word
| Grens | Wat dit bepaal |
|---|---|
| TCP-segment | Die vervoer- en netwerkroete |
| ’n Socket-leesresultaat | Beskikbare stroomgrepe en die oproeper se buffer |
| HTTP-boodskap of -raam | Die HTTP-protokol se raamreëls |
Een lees kan ’n deel van ’n kop, ’n volledige kop plus liggaamsgrepe, of data oor meer as een toepassingsvlakgrens bevat. TCP koppel nie “einde van HTTP-antwoord” aan die einde van ’n geslaagde lees nie.
’n HTTP/1.1-ontleder versamel dus koppe en gebruik die toepaslike liggaamsraamreëls, insluitend lengte, oordragkode of toegelate verbindingsluiting. ’n HTTP/2-raam is ’n protokolstruktuur wat self TCP-segmente kan kruis; dit is nie ’n ander naam vir ’n netwerkpakket nie.
’n Geslaagde CONNECT-tonnel bewaar die getonnelde greepstroom terwyl dit steeds twee TCP-pote gebruik. Sy segmentgrense kan verskil selfs wanneer die proxy nie die grepe binne die tonnel verander het nie.
Vergelyk weer saamgestelde toepassingsdata wanneer jy korrupsie ondersoek. Om pakkettellings te vergelyk of om dieselfde pakketlengtes aan beide kante te verwag, vra van TCP ’n grensgarantie wat dit nie bied nie.