Алдыңғы прокси TCP сегменттерінің шекараларын сақтамайды
Алдыңғы проксидің екі жағындағы трафикті тексергенде TCP сегменттеуін, сокет оқуларын және HTTP қаптамасын бөлек қарастырыңыз.
Squid арқылы өткеннен кейін HTTP жауабы бірнеше түсірілген TCP сегментінде көрінеді делік. Бұл TCP-нің қалыпты әрекеті болуы мүмкін, жауап дұрыс бөлінбеді деген дәлел емес.
Алдыңғы прокси әдетте екі қосылымға ие:
client ⇄ TCP connection A ⇄ proxy ⇄ TCP connection B ⇄ originӘр қосылымның өз TCP күйі, реттік нөмірлері және пакеттелуі бар. Прокси бір қосылымнан деректерді оқып, екіншісіне жаза алады, бастапқы сегмент өлшемдерін сақтамай. Буферлеу, жіберу уақыты, кептелу және жолдың өлшем шектері басқа топтастыруды тудыруы мүмкін.
Бөлек ұстаған жөн үш шекара
| Шекара | Оны не анықтайды |
|---|---|
| TCP сегменті | Тасымалдау және желі жолы |
| Сокет оқуының нәтижесі | Қолжетімді ағын байттары және шақырушының буфері |
| HTTP хабарламасы немесе фреймі | HTTP протоколының қаптау ережелері |
Бір оқу тақырыпшаның бір бөлігін, толық тақырыпшаны дене байттарымен бірге немесе бірнеше қолданба деңгейінің шекарасын кесіп өтетін деректерді қамтуы мүмкін. TCP «HTTP жауабының соңын» сәтті оқудың соңына байламайды.
Сондықтан HTTP/1.1 талдағышы тақырыпшаларды жинақтап, қолданылатын дене қаптамасы ережелерін қолданады, оның ішінде ұзындық, тасымалдау кодтауы немесе рұқсат етілген қосылым жабылуы бар. HTTP/2 фреймі өзі TCP сегменттерін кесіп өте алатын протокол құрылымы; ол желілік пакеттің басқа атауы емес.
Сәтті CONNECT туннелі туннельденген байт ағынын сақтайды, бірақ бәрібір екі TCP аяғын пайдаланады. Прокси туннель ішіндегі байттарды өзгертпесе де, оның сегмент шекаралары өзгеше болуы мүмкін.
Бүлінуді тергеу кезінде қайта жиналған қолданба деректерін салыстырыңыз. Пакет санын салыстыру немесе екі жақта бірдей пакет ұзындығын күту TCP-ден ол бермейтін шекара кепілдігін сұрау болып табылады.