Një proxy përpara nuk i ruan kufijtë e segmenteve TCP

Supozoni se një përgjigje HTTP shfaqet në disa segmente TCP të kapura pasi ka kaluar nëpër Squid. Ky mund të jetë sjellje normale e TCP, dhe jo provë se përgjigja u nda gabimisht.

Një proxy përpara zakonisht ka dy lidhje:

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

Secila lidhje ka gjendjen e vet TCP, numrat e sekuencës dhe paketimin e vet. Proxy-i mund të lexojë të dhëna nga një lidhje dhe t’i shkruajë në tjetrën pa ruajtur madhësitë origjinale të segmenteve. Buferimi, koha e dërgimit, mbingarkesa dhe kufijtë e madhësisë së rrugës mund të prodhojnë një grupim tjetër.

Tre kufij që ia vlen t’i mbani të ndarë

Një lexim i vetëm mund të përmbajë një pjesë të një koke, një kokë të plotë bashkë me bajtët e trupit, ose të dhëna që kalojnë më shumë se një kufi të nivelit të aplikacionit. TCP nuk e lidh «fundin e përgjigjes HTTP» me fundin e një leximi të suksesshëm.

Prandaj një analizues HTTP/1.1 grumbullon kokët dhe zbaton rregullat përkatëse të kornizimit të trupit, duke përfshirë gjatësinë, kodimin e transferimit ose mbylljen e lejuar të lidhjes. Një kornizë HTTP/2 është një strukturë protokolli që mund të kalojë vetë segmentet TCP; nuk është një emër tjetër për një paketë rrjeti.

Një tunel CONNECT i suksesshëm ruan rrjedhën e bajtëve të tunelizuar, ndërsa përdor ende dy këmbë TCP. Kufijtë e segmenteve të tij mund të ndryshojnë edhe kur proxy-i nuk i ka ndryshuar bajtët brenda tunelit.

Kur hetoni korrupsion, krahasoni të dhënat e aplikacionit të rimontuara. Krahasimi i numrit të paketave ose pritja e gjatësive identike në të dyja anët i kërkon TCP-së një garanci kufijsh që ai nuk e jep.