Напреден прокси не ги зачувува границите на TCP сегментите

Да претпоставиме дека HTTP одговорот се појавува во неколку снимени TCP сегменти откако ќе помине низ Squid. Тоа може да е вообичаено TCP однесување, а не доказ дека одговорот е погрешно поделен.

Напредниот прокси обично има две врски:

client ⇄ TCP connection A ⇄ proxy ⇄ TCP connection B ⇄ origin

Секоја врска има сопствена TCP состојба, редни броеви и пакетирање. Проксито може да чита податоци од едната врска и да ги запишува во другата без да ги зачува оригиналните големини на сегментите. Баферирањето, времето на испраќање, застојот и ограничувањата на големината на патеката можат да создадат друго групирање.

Три граници што вреди да се држат одвоено

Едно читање може да содржи дел од заглавие, цело заглавие заедно со бајти од телото или податоци што преминуваат повеќе од една граница на апликациско ниво. TCP не го поврзува „крајот на HTTP одговорот“ со крајот на успешно читање.

Затоа HTTP/1.1 парсерот собира заглавија и ги применува соодветните правила за врамување на телото, вклучувајќи должина, преносно кодирање или дозволено затворање на врската. HTTP/2 рамката е протоколна структура што самата може да премине TCP сегменти; тоа не е друго име за мрежен пакет.

Успешен CONNECT тунел го зачувува тунелираниот тек на бајти, но сепак користи две TCP краци. Неговите граници на сегменти може да се разликуваат дури и кога проксито не ги променило бајтите внатре во тунелот.

Кога истражувате оштетување, споредете ги повторно составените апликациски податоци. Споредувањето на бројот на пакети или очекувањето исти должини на пакети од двете страни бара од TCP гаранција за граници што тој не ја дава.