د پروکسي له لارې د TCP صفر کړکۍ: ترلاسه کوونکی وپېژنئ
د ودرېدلي ډاونلوډ پړه پر کړکۍ پراخوالي یا بفر اندازه مه اچوئ، لومړی د پروکسي په کلاینټ یا سرور اړخ کې د TCP بهیر کنټرول ومومئ.
د پاکټ ټریس TCP ZeroWindow ښیي. د کرنل تنظیم بدلولو دمخه هغه پای ټکی وپېژنئ چې صفر اعلانوي.
هغه پای ټکی په دې TCP اړیکه کې خپل د ترلاسه کولو ظرفیت بیانوي. دا نه اعلانوي چې ټول پروکسي څومره بینډوېت لري. د صفر کړکۍ ازموینه لیږونکي ته اجازه ورکوي چې پوه شي اعلان شوی ظرفیت بدل شوی که نه؛ ازموینه یوازې د پاکټ ضایع یا خراب پروکسي ثبوت نه دی.
browser <-- TCP A --> proxy <-- TCP B --> websiteدا جلا TCP خبرې اترې دي. فرض کړئ چې براوزر یو لوی ځواب لوستل بندوي او په A صفر اعلانوي. پروکسي کولای شي په پای کې د B تشول بند کړي کله چې خپل بفرونه ډک شي. په B کې وروسته لیدل شوې صفر کړکۍ کېدای شي د ورو کلاینټ پایله وي، نه اصلي ستونزه.
د اپلوډ پر مهال برعکس حالت هم ممکن دی. که منزل اپلیکیشن د معلوماتو کارول بند کړي، په B کې د هغه کړکۍ کېدای شي وتړل شي. بیا فشار کولای شي د پروکسي بفرونو له لارې بېرته کلاینټ ته ولاړ شي.
مشاهدات په ترتیب کې کېږدئ
- د اړیکې دواړه پای ټکي او د اغېزمن شوي معلوماتو لېږد لوری ولیکئ.
- وپېژنئ کوم پای ټکي لومړی د کمېدونکې یا صفر ترلاسه کوونکې کړکۍ اعلان وکړ.
- وګورئ چې د هغه اپلیکیشن لوستل کول، په بل عملیات کې ودرېد، یا د سرچینو له امله محدود و.
- د اصلي لامل ټاکلو دمخه د پروکسي په بل اړیکه کې وخت پرتله کړئ.
د Wireshark د کړکۍ تحلیل نښې د نیولو ګټورې تفسیرونه دي، نه دا لارښوونه چې هر ترلاسه کوونکی بفر زیات کړئ. د کړکۍ پراخوالی هم باید د اړیکې د خبرو اترو په پام کې نیولو سره تفسیر شي.
د پروکسي لیست څخه بل پای ټکی ازمویل او د لېږد رغېدل لیدل دا ګټوره شاهد ده چې لار بدله شوې. خو یوازې دا نه ثبوتوي چې د کوم آپریټنګ سیسټم TCP پلي کول نیمګړي وو. تشریح د ترلاسه کوونکي بهیر او هغې اړیکې سره وتړئ چې انتظار پکې پیل شو.