ซ็อกเก็ต .NET ต้องมีแฮนด์เชก SOCKS

การชี้ Socket.Connect() ไปยังเซิร์ฟเวอร์ SOCKS จะเปิดการเชื่อมต่อ TCP ไปยังเซิร์ฟเวอร์นั้น ไบต์ถัดไปยังต้องพูดภาษา SOCKS การส่งโปรโตคอลของแอปพลิเคชันทันทีจะทำให้เซิร์ฟเวอร์รอการสนทนาอีกแบบหนึ่ง

กับ SOCKS5 การสร้างการเชื่อมต่อรวมถึงการเจรจาวิธีการ การแลกเปลี่ยนการยืนยันตัวตนที่เลือก (ถ้ามี) และคำขอที่ระบุปลายทาง มีเพียงการตอบกลับที่สำเร็จเท่านั้นที่เปิดเส้นทางให้ไบต์ของแอปพลิเคชัน ขั้นตอนเหล่านี้กำหนดไว้ใน RFC 1928.

เก็บการเจรจาไว้ในชั้นการเชื่อมต่อ

แอปพลิเคชันที่มีโปรโตคอล TCP ของตัวเองสามารถใช้ตัวเชื่อมต่อที่รู้จักพร็อกซีและคืนสตรีมที่สร้างแล้ว ส่วนที่เหลือของแอปพลิเคชันจะอ่านและเขียนผ่านสตรีมนั้น ตัวเชื่อมต่อต้องคำนึงถึงการอ่านบางส่วน ที่อยู่ที่มีความยาวผันแปร ความล้มเหลวของการยืนยันตัวตน และกำหนดเวลาสำหรับการเจรจา

การทำให้ใช้งานได้ด้วยการเขียนมือที่อ่านบัฟเฟอร์ขนาดคงที่หนึ่งก้อนและถือว่าสำเร็จนั้นเปราะบาง TCP ไม่ได้รักษาขอบเขตของข้อความ SOCKS. อ่านการตอบกลับทั้งหมดตามที่อธิบายโดยชนิดที่อยู่ก่อนเริ่มโปรโตคอลของแอปพลิเคชัน ตัวอ่านการตอบกลับ CONNECT สำหรับ .NET 7+ แสดงขั้นตอนนั้น

หากไลบรารีที่ได้รับการดูแลอยู่แล้วมีชั้นการเชื่อมต่อนี้ ให้ตรวจสอบเวอร์ชัน SOCKS ที่รองรับ วิธีการยืนยันตัวตน และเฟรมเวิร์กเป้าหมาย ลิงก์ฟอรัมที่เก่าทศวรรษเป็นจุดเริ่มต้นของการสอบสวน ไม่ใช่หลักฐานของความเข้ากันได้ในปัจจุบัน

การกำหนดค่าของไคลเอนต์ HTTP มีขอบเขตแยกต่างหาก

การตั้งค่าพร็อกซีของไคลเอนต์ HTTP กำหนดค่าไคลเอนต์ HTTP นั้น ไม่ได้แก้ไขทุกซ็อกเก็ตดิบในโปรเซส API ของ Socket ยอมรับปลายทางเครือข่ายและปล่อยการเจรจาระดับสูงให้ผู้เรียก

สำหรับโปรโตคอลแอปพลิเคชันที่เข้ารหัส ให้ทำแฮนด์เชก TLS หลังจากสร้างอุโมงค์พร็อกซีแล้ว ตรวจสอบตัวตนปลายทางที่ตั้งใจไว้ในขั้นตอนนั้น การยืนยันตัวตนพร็อกซีและการยืนยันตัวตนปลายทางยังแยกจากกันแม้จะใช้สตรีมพื้นฐานเดียวกัน