อ่านแปดไบต์ แล้วส่งต่ออุโมงค์ SOCKS4
หลีกเลี่ยงการกลืนคำทักทายของปลายทางหรือการรอไบต์ที่ไม่มีอยู่ โดยวิเคราะห์ขอบเขตคงที่ของการตอบกลับ SOCKS4
คำขอเชื่อมต่อ SOCKS4 สำเร็จ แต่แอปพลิเคชันไม่เคยเห็นคำทักทายเปิดของเซิร์ฟเวอร์ จุดหนึ่งที่ควรตรวจคือการอ่านครั้งแรกของตัวเชื่อมต่อ การอ่านสิบหกไบต์นั้นใหญ่เกินไปสำหรับการตอบกลับ SOCKS4 แปดไบต์
| ฟิลด์การตอบกลับ | ไบต์ |
|---|---|
| ฟิลด์เวอร์ชันการตอบกลับ | 1 |
| รหัสผลลัพธ์ | 1 |
| ฟิลด์พอร์ต | 2 |
| ฟิลด์ที่อยู่ | 4 |
รหัสผลลัพธ์ 0x5a บ่งชี้ว่าคำขอได้รับอนุญาต SOCKS4a เปลี่ยนวิธีที่คำขอพาชื่อโฮสต์ แต่ไม่ได้ทำให้การตอบกลับกลายเป็นสิบหกไบต์
หลังการตอบกลับ สตรีม TCP เดียวกันพาโปรโตคอลของปลายทาง เซิร์ฟเวอร์เมลอาจส่งคำทักทายทันที ดังนั้นการอ่านที่ใช้สิบหกไบต์ที่มีอยู่อาจเอาคำตอบพร็อกซีทั้งหมดพร้อมแปดไบต์แรกของคำทักทายนั้นไปด้วย หากยังไม่มีอะไรตามมา การอ่านแบบบล็อกที่ใหญ่เกินไปอาจเพิ่มการรอโดยไม่จำเป็นแทน
ความยาวที่แน่นอนเป็นความรับผิดชอบของตัวแยกวิเคราะห์
การขอแปดไบต์เพียงครั้งเดียวไม่ใช่หลักฐานที่เพียงพอว่าแปดไบต์มาถึงแล้ว การอ่านสตรีมอาจคืนน้อยกว่า เก็บความยาวของการตอบกลับให้ครบถ้วนภายในกำหนดเวลา หยุดเมื่อสตรีมปิดหรือล้มเหลว ตรวจสอบการตอบกลับ และปล่อยไบต์ถัดไปให้แอปพลิเคชัน
หากตัวเชื่อมต่อใช้การอ่านแบบบัฟเฟอร์ที่ใหญ่กว่า ให้เก็บทุกอย่างหลังขอบเขตและส่งต่อให้ผู้บริโภคถัดไป การทิ้งส่วนเกินคือการสูญเสียข้อมูลแบบเดียวกันด้วยขนาดการอ่านที่ต่างกัน
SOCKS5 ต้องมีตัวแยกวิเคราะห์ของตัวเอง ความยาวของที่อยู่ในการตอบกลับอาจต่างกันตามชนิดของที่อยู่ การแทนที่การอ่านพร็อกซีทุกครั้งด้วยการอ่านแปดไบต์แบบคงที่จะแก้โปรโตคอลหนึ่งแต่ทำให้อีกโปรโตคอลเสีย