Առաջադիր պրոքսին չի պահպանում TCP սեգմենտների սահմանները

Ենթադրենք՝ HTTP պատասխանը Squid-ով անցնելուց հետո երևում է մի քանի գրանցված TCP սեգմենտներում։ Դա կարող է TCP-ի սովորական վարք լինել, ոչ թե ապացույց, որ պատասխանը սխալ է բաժանվել։

Առաջադիր պրոքսին սովորաբար ունենում է երկու միացում՝

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

Յուրաքանչյուր միացում ունի իր TCP վիճակը, հաջորդականության համարները և փաթեթավորումը։ Պրոքսին կարող է տվյալ կարդալ մի միացումից և գրել մյուսի մեջ՝ չպահպանելով սկզբնական սեգմենտների չափերը։ Բուֆերացումը, ուղարկման պահը, գերբեռնվածությունը և ուղու չափային սահմանները կարող են այլ խմբավորում ստեղծել։

Երեք սահման, որոնք արժե առանձին պահել

Մեկ ընթերցումը կարող է պարունակել վերնագրի մի մաս, ամբողջ վերնագիր՝ մարմնի բայթերի հետ, կամ տվյալ, որը հատում է մեկից ավելի կիրառական մակարդակի սահման։ TCP-ն «HTTP պատասխանի վերջը» չի կապում հաջող ընթերցման վերջին։

Այդ պատճառով HTTP/1.1 վերլուծիչը կուտակում է վերնագրերը և կիրառում է մարմնի շրջանակավորման համապատասխան կանոնները՝ ներառյալ երկարությունը, փոխանցման կոդավորումը կամ թույլատրված միացման փակումը։ HTTP/2 շրջանակը արձանագրային կառուցվածք է, որն ինքը կարող է հատել TCP սեգմենտները. դա ցանցային փաթեթի այլ անուն չէ։

Հաջող CONNECT թունելը պահպանում է թունելավորված բայթային հոսքը՝ միաժամանակ օգտագործելով TCP-ի երկու ոտք։ Նրա սեգմենտների սահմանները կարող են տարբեր լինել նույնիսկ այն դեպքում, երբ պրոքսին չի փոխել թունելի ներսի բայթերը։

Վնասվածքը հետաքննելիս համեմատեք վերահավաքված կիրառական տվյալները։ Փաթեթների քանակի համեմատումը կամ երկու կողմերում նույն փաթեթի երկարությունները սպասելը TCP-ից պահանջում է սահմանի երաշխիք, որը նա չի տալիս։