یک سوکت .NET به دست‌دادن SOCKS نیاز دارد

هدایت Socket.Connect() به یک سرور SOCKS یک اتصال TCP به آن سرور باز می‌کند. بایت‌های بعدی هنوز باید SOCKS صحبت کنند. ارسال فوری پروتکل برنامه، سرور را منتظر گفت‌وگویی دیگر می‌گذارد.

با SOCKS5، برقراری اتصال شامل مذاکرهٔ روش، هر تبادل احراز هویت انتخاب‌شده و درخواستی است که مقصد را نام می‌برد. تنها یک پاسخ موفق مسیر را برای بایت‌های برنامه باز می‌کند. این مراحل در RFC 1928 تعریف شده‌اند.

مذاکره را در لایهٔ اتصال نگه دارید

برنامه‌ای با پروتکل TCP خاص خود می‌تواند از یک اتصال‌دهندهٔ آشنا به پروکسی استفاده کند که یک جریان برقرارشده برمی‌گرداند. سپس بقیهٔ برنامه از طریق همان جریان می‌خواند و می‌نویسد. اتصال‌دهنده باید خواندن‌های جزئی، نشانی‌های با طول متغیر، شکست‌های احراز هویت و یک مهلت برای مذاکره را در نظر بگیرد.

پیاده‌سازی دست‌نویسی که یک بافر با اندازهٔ ثابت می‌خواند و موفقیت را فرض می‌کند شکننده است. TCP مرزهای پیام‌های SOCKS را حفظ نمی‌کند. پیش از شروع پروتکل برنامه، پاسخ کامل را که با نوع نشانی‌اش توصیف می‌شود بخوانید. یک خوانندهٔ پاسخ CONNECT در .NET 7+ این گام را نشان می‌دهد.

اگر کتابخانه‌ای نگهداری‌شده از قبل این لایهٔ اتصال را فراهم می‌کند، نسخه‌های پشتیبانی‌شدهٔ SOCKS، روش‌های احراز هویت و چارچوب هدف آن را بررسی کنید. پیوند انجمنی ده‌ساله نقطهٔ شروعی برای بررسی است، نه شاهدی بر سازگاری کنونی.

پیکربندی کلاینت HTTP دامنهٔ جداگانه‌ای دارد

تنظیم پروکسی یک کلاینت HTTP همان کلاینت HTTP را پیکربندی می‌کند. هر سوکت خام در فرایند را تغییر نمی‌دهد. API سوکت یک نقطهٔ پایانی شبکه می‌پذیرد و مذاکرهٔ سطح بالاتر را به فراخواننده واگذار می‌کند.

برای پروتکل رمزنگاری‌شدهٔ برنامه، دست‌دادن TLS آن را پس از برقراری تونل پروکسی انجام دهید. در همان مرحله هویت مقصد مورد نظر را اعتبارسنجی کنید. احراز هویت پروکسی و احراز هویت مقصد جدا می‌مانند، هرچند از همان جریان زیرین استفاده می‌کنند.