Преден прокси не запазва границите на TCP сегментите
Разделяйте TCP сегментацията, четенията от сокета и HTTP рамкирането, когато изследвате трафика от двете страни на преден прокси.
Да предположим, че HTTP отговор се появи в няколко прихванати TCP сегмента, след като е преминал през Squid. Това може да е обичайно поведение на 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 гаранция за граници, която той не дава.