Предњи прокси не чува границе 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-а гаранцију граница коју он не пружа.