Persiunčiamasis tarpinis serveris neišsaugo TCP segmentų ribų
Skirkite TCP segmentavimą, lizdo skaitymus ir HTTP įrėminimą, kai tiriate srautą abiejose persiunčiamojo tarpinio serverio pusėse.
Tarkime, HTTP atsakas po praėjimo per Squid pasirodo keliuose užfiksuotuose TCP segmentuose. Tai gali būti įprastas TCP elgesys, o ne įrodymas, kad atsakas buvo suskaidytas neteisingai.
Persiunčiamasis tarpinis serveris paprastai turi dvi jungtis:
client ⇄ TCP connection A ⇄ proxy ⇄ TCP connection B ⇄ originKiekviena jungtis turi savo TCP būseną, sekos numerius ir paketizavimą. Tarpinis serveris gali skaityti duomenis iš vienos jungties ir rašyti į kitą, neišsaugodamas pradinių segmento dydžių. Buferizavimas, siuntimo laikas, perkrova ir maršruto dydžio apribojimai gali sudaryti kitokį grupavimą.
Trys ribos, kurias verta laikyti atskirai
| Riba | Kas ją nustato |
|---|---|
| TCP segmentas | Transporto ir tinklo maršrutas |
| Lizdo skaitymo rezultatas | Turimi srauto baitai ir kviečiančiojo buferis |
| HTTP pranešimas arba kadras | HTTP protokolo įrėminimo taisyklės |
Vienas skaitymas gali turėti dalį antraštės, visą antraštę su kūno baitais arba duomenis, kertančius daugiau nei vieną programos lygio ribą. TCP nesusieja „HTTP atsakymo pabaigos“ su sėkmingo skaitymo pabaiga.
Todėl HTTP/1.1 analizatorius kaupia antraštes ir taiko atitinkamas kūno įrėminimo taisykles, įskaitant ilgį, perdavimo kodavimą arba leidžiamą jungties uždarymą. HTTP/2 kadras yra protokolo struktūra, kuri pati gali kirsti TCP segmentus; tai ne kitas tinklo paketo pavadinimas.
Sėkmingas CONNECT tunelis išsaugo tuneliuojamą baitų srautą, tačiau vis dar naudoja dvi TCP atkarpas. Jo segmentų ribos gali skirtis net tada, kai tarpinis serveris nepakeitė baitų tunelio viduje.
Tirdami pažeidimus, palyginkite iš naujo surinktus programos duomenis. Lyginti paketų skaičių arba tikėtis vienodo paketų ilgio abiejose pusėse reiškia prašyti TCP ribų garantijos, kurios jis neteikia.