Прамы проксі не захоўвае межы сегментаў TCP
Аддзяляйце сегментацыю TCP, чытанні сокета і фарміраванне кадраў HTTP пры аналізе трафіку па абодва бакі прамога проксі.
Выкажам здагадку, што адказ HTTP пасля праходжання праз Squid з’яўляецца ў некалькіх захаваных сегментах 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 гарантыі межаў, якой ён не дае.