اته بایټونه ولولئ، بیا SOCKS4 تونل وسپارئ
د SOCKS4 ځواب ثابته پوله تحلیل کړئ تر څو د منزل سلام نه تېر کړئ او نه د نهشته بایټونو انتظار وکړئ.
د SOCKS4 د نښلون غوښتنه بریالۍ کیږي، خو اپلیکیشن د سرور پیلنی سلام هېڅکله نه ویني. د کتلو یو ځای د نښلوونکي لومړنی لوستل دي. د شپاړسو بایټونو لوستل د اتو بایټونو SOCKS4 ځواب لپاره ډېر لوی دي.
| د ځواب ساحه | بایټ |
|---|---|
| د ځواب نسخې ساحه | 1 |
| د پایلې کوډ | 1 |
| د پورټ ساحه | 2 |
| د پتې ساحه | 4 |
د پایلې کوډ 0x5a ښیي چې غوښتنه ومنل شوه. SOCKS4a بدلوي چې غوښتنه د کوربه نوم څنګه وړي؛ دا ځواب شپاړس بایټه نه کوي.
له ځواب وروسته هماغه TCP بهیر د منزل پروتوکول وړي. د برېښنالیک سرور کولی شي خپل سلام سمدلاسه واستوي. نو هغه لوستل چې شپاړس موجود بایټونه کاروي کولی شي بشپړ پروکسي ځواب او د هغه سلام لومړني اته بایټونه واخلي. که تر اوسه هېڅ نه وي راغلی، ډېر لوی بندېدونکی لوستل کولی شي پرځای یې بېځایه انتظار ورزیات کړي.
سمه اوږدوالی د شننونکي مسؤلیت دی
یو ځل اته بایټونه غوښتل د دې کافي ثبوت نه دی چې اته بایټونه راغلي. د بهیر لوستل کېدای شي لږ بیرته راوګرځوي. د ځواب اوږدوالی په ټاکلې موده کې سم راټول کړئ، په بند یا ناکام بهیر کې ودريدل شئ، ځواب وګورئ، او راتلونکي بایټونه اپلیکیشن ته پرېږدئ.
که نښلوونکی لوی بفر شوی لوستل کاروي، د پولې وروسته هر څه وساتئ او بل مصرف کوونکي ته یې وسپارئ. اضافي دور کول هماغه د معلوماتو زیان دی چې یوازې د لوستلو اندازه بدله ده.
SOCKS5 خپل شننونکی غواړي. د هغه د ځواب پتې اوږدوالی د پتې ډول له مخې توپیر کولی شي. هره پروکسي لوستل په ثابت اتو بایټونو لوستلو بدلول به یو پروتوکول سم کړي او بل به مات کړي.