Squid හරහා ගිය පසු HTTP ප්‍රතිචාරයක් ග්‍රහණය කරගත් TCP කොටස් කිහිපයක පෙනෙනවා යැයි සිතමු. එය සාමාන්‍ය TCP හැසිරීමක් විය හැක; ප්‍රතිචාරය වැරදි ලෙස බෙදා ඇති බවට සාක්ෂියක් නොවේ.

Forward proxy එකකට සාමාන්‍යයෙන් සම්බන්ධතා දෙකක් ඇත:

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

සෑම සම්බන්ධතාවකටම තමන්ගේ TCP තත්ත්වය, අනුක්‍රම අංක සහ පැකට්කරණය ඇත. Proxy එකට එක් සම්බන්ධතාවකින් දත්ත කියවා අනෙකට ලිවිය හැක, මුල් කොටස් ප්‍රමාණ රැක නොගෙන. Buffer කිරීම, යැවීමේ වේලාව, තදබදය සහ මාර්ගයේ ප්‍රමාණ සීමා වෙනත් සමූහගත කිරීමක් ඇති කළ හැක.

වෙන් කර තැබිය යුතු මායිම් තුනක්

මායිමඑය තීරණය කරන්නේ කුමක්ද
TCP කොටසප්‍රවාහන සහ ජාල මාර්ගය
Socket කියවීමේ ප්‍රතිඵලයපවතින stream බයිට් සහ ඇමතුම්කරුගේ buffer
HTTP පණිවිඩය හෝ රාමුවHTTP ප්‍රොටෝකෝලයේ රාමුකරණ නීති

එක් කියවීමක header කොටසක්, සම්පූර්ණ header සමඟ body බයිට්, හෝ යෙදුම් මට්ටමේ මායිම් එකකට වඩා තරණය කරන දත්ත අඩංගු විය හැක. TCP “HTTP ප්‍රතිචාරයේ අවසානය” සාර්ථක කියවීමක අවසානයට සම්බන්ධ නොකරයි.

එබැවින් HTTP/1.1 විග්‍රහකය header එකතු කර අදාළ body රාමුකරණ නීති යොදයි; ඒවාට දිග, මාරු කේතකරණය හෝ අනුමත සම්බන්ධතා වැසීම ඇතුළත් වේ. HTTP/2 රාමුවක් යනු තමන්ම TCP කොටස් තරණය කළ හැකි ප්‍රොටෝකෝල ව්‍යුහයකි; එය ජාල පැකට්ටුවකට වෙනත් නමක් නොවේ.

සාර්ථක CONNECT උමඟක් උමඟ තුළ බයිට් ප්‍රවාහය රකිමින් TCP පාද දෙකක් තවමත් භාවිත කරයි. Proxy උමඟ තුළ බයිට් වෙනස් නොකළත් එහි කොටස් මායිම් වෙනස් විය හැක.

දූෂණය විමර්ශනය කරන විට නැවත එකලස් කළ යෙදුම් දත්ත සසඳන්න. පැකට් ගණන සැසඳීම හෝ දෙපසම සමාන පැකට් දිග බලාපොරොත්තු වීම TCP වෙතින් එය නොදෙන මායිම් සහතිකයක් ඉල්ලීමකි.

අදාළ ලිපි