د مخکې پروکسي د 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 څخه داسې پوله‌ژمنه غوښتل دي چې هغه نه ورکوي.