Uz priekšu vērsts starpniekserveris nesaglabā TCP segmentu robežas
Atdaliet TCP segmentāciju, ligzdas lasījumus un HTTP iekadrēšanu, pārbaudot satiksmi abpus uz priekšu vērstam starpniekserverim.
Pieņemsim, ka HTTP atbilde pēc iziešanas caur Squid parādās vairākos ierakstītos TCP segmentos. Tā var būt parasta TCP uzvedība, nevis pierādījums, ka atbilde sadalīta nepareizi.
Uz priekšu vērstam starpniekserverim parasti ir divi savienojumi:
client ⇄ TCP connection A ⇄ proxy ⇄ TCP connection B ⇄ originKatram savienojumam ir savs TCP stāvoklis, secības numuri un pakešu veidošana. Starpniekserveris var lasīt datus no viena savienojuma un rakstīt tos otrā, nesaglabājot sākotnējos segmenta izmērus. Buferēšana, sūtīšanas laiks, sastrēgumi un ceļa izmēra ierobežojumi var radīt citu grupējumu.
Trīs robežas, ko vērts turēt atsevišķi
| Robeža | Kas to nosaka |
|---|---|
| TCP segments | Transporta un tīkla ceļš |
| Ligzdas lasījuma rezultāts | Pieejamie straumes baiti un izsaucēja buferis |
| HTTP ziņojums vai kadrs | HTTP protokola iekadrēšanas noteikumi |
Viens lasījums var saturēt daļu galvenes, visu galveni kopā ar ķermeņa baitiem vai datus, kas šķērso vairāk nekā vienu lietojumprogrammas līmeņa robežu. TCP nesaista “HTTP atbildes beigas” ar veiksmīga lasījuma beigām.
Tāpēc HTTP/1.1 parsētājs uzkrāj galvenes un piemēro attiecīgos ķermeņa iekadrēšanas noteikumus, tostarp garumu, pārsūtīšanas kodējumu vai atļauto savienojuma aizvēršanu. HTTP/2 kadrs ir protokola struktūra, kas pati var šķērsot TCP segmentus; tas nav cits tīkla paketes nosaukums.
Veiksmīgs CONNECT tunelis saglabā tunelēto baitu plūsmu, taču joprojām izmanto divus TCP posmus. Tā segmentu robežas var atšķirties arī tad, ja starpniekserveris nav mainījis baitus tuneļa iekšpusē.
Izmeklējot bojājumus, salīdziniet no jauna samontētos lietojumprogrammas datus. Pakešu skaita salīdzināšana vai vienādu pakešu garumu gaidīšana abās pusēs pieprasa no TCP robežu garantiju, ko tas nesniedz.