ફોરવર્ડ પ્રોક્સી TCP સેગમેન્ટની સીમાઓ જાળવતું નથી

ધારો કે Squidમાંથી પસાર થયા પછી HTTP પ્રતિસાદ કેટલાક કેપ્ચર કરેલા TCP સેગમેન્ટમાં દેખાય છે. તે સામાન્ય TCP વર્તન હોઈ શકે, પ્રતિસાદ ખોટી રીતે વિભાજિત થયો હોવાનો પુરાવો નથી.

ફોરવર્ડ પ્રોક્સીમાં સામાન્ય રીતે બે કનેક્શન હોય છે:

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

દરેક કનેક્શનની પોતાની TCP સ્થિતિ, ક્રમ સંખ્યાઓ અને પેકેટાઇઝેશન હોય છે. પ્રોક્સી એક કનેક્શનમાંથી ડેટા વાંચીને બીજામાં લખી શકે છે, મૂળ સેગમેન્ટના માપ જાળવ્યા વગર. બફરિંગ, મોકલવાનો સમય, ભીડ અને માર્ગની માપ મર્યાદા બીજું જૂથ બનાવી શકે છે.

અલગ રાખવા યોગ્ય ત્રણ સીમાઓ

એક વાંચનમાં હેડરનો ભાગ, આખું હેડર સાથે બોડી બાઇટ્સ, અથવા એક કરતાં વધુ એપ્લિકેશન-સ્તરની સીમા ઓળંગતો ડેટા હોઈ શકે. TCP સફળ વાંચનના અંત સાથે “HTTP પ્રતિસાદનો અંત” જોડતું નથી.

તેથી HTTP/1.1 પાર્સર હેડર એકઠા કરે છે અને લાગુ પડતા બોડી-ફ્રેમિંગ નિયમો વાપરે છે, જેમાં લંબાઈ, ટ્રાન્સફર કોડિંગ અથવા મંજૂર કનેક્શન બંધ કરવાનો સમાવેશ થાય છે. HTTP/2 ફ્રેમ એ પ્રોટોકોલ રચના છે જે પોતે TCP સેગમેન્ટ ઓળંગી શકે છે; તે નેટવર્ક પેકેટનું બીજું નામ નથી.

સફળ CONNECT ટનલ ટનલમાંના બાઇટ પ્રવાહને જાળવે છે, છતાં બે TCP પગ વાપરે છે. પ્રોક્સીએ ટનલની અંદરના બાઇટ્સ ન બદલ્યા હોય તો પણ તેની સેગમેન્ટ સીમાઓ અલગ હોઈ શકે છે.

ભ્રષ્ટાચારની તપાસ કરતી વખતે ફરી જોડાયેલ એપ્લિકેશન ડેટાની સરખામણી કરો. પેકેટની ગણતરી સરખાવવી અથવા બંને બાજુ સમાન પેકેટ લંબાઈની અપેક્ષા રાખવી એ TCP પાસે એવી સીમા-ખાતરી માગવી છે જે તે આપતું નથી.