ส่งต่อการปิดครึ่งเดียวของ TCP หลังจากระบายไบต์ที่ค้างอยู่

ไคลเอนต์ส่งเสร็จ พร็อกซีเห็น EOF และการตอบกลับหายไป การปิดซ็อกเก็ตทั้งสองของพร็อกซีทันทีอาจทำให้เกิดลำดับนั้นพอดี ในรีเลย์ TCP การสิ้นสุดอย่างเป็นระเบียบในทิศทางหนึ่งไม่ได้หมายความว่าอีกทิศทางสิ้นสุดแล้ว

ลองพิจารณาไคลเอนต์ที่ส่งคำขอ ปิดฝั่งส่งของตน แล้วรอการตอบกลับ:

client -- request, then FIN --> proxy --> service
client <-------- reply ------- proxy <-- service

พร็อกซีมีการเชื่อมต่อ TCP สองรายการและ สตรีมไบต์สองสายที่เคลื่อนที่อย่างเป็นอิสระจากกัน ต้องส่งสัญญาณสิ้นสุดข้อมูลขาเข้าต่อไป หลังจากส่งไบต์ที่มาก่อนหน้ามันแล้ว

ระบายคิวก่อนส่งต่อ EOF

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

เมื่อคิวจากไคลเอนต์ไปยังบริการระบายหมดแล้ว ให้เรียก shutdown(service_socket, SHUT_WR) บนซ็อกเก็ต POSIX การทำเช่นนี้ยุติการส่งต่อไปยังบริการ แต่ทิศทางจากบริการไปยังไคลเอนต์ยังใช้ได้ เมื่อบริการตอบกลับเสร็จแล้ว ให้ใช้การดำเนินการแบบกระจกหลังระบายคิวการตอบกลับ

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

ความพร้อมคือคำเชิญให้อ่าน

ซ็อกเก็ตที่อ่านได้อาจมีข้อมูลหรือสภาวะ EOF ให้เรียก recv แล้วตีความผลลัพธ์ จำนวนบวกคือไบต์ที่ต้องส่งต่อ ศูนย์คือจุดสิ้นสุดของทิศทาง บนซ็อกเก็ตที่ไม่บล็อก EAGAIN หรือ EWOULDBLOCK หมายความว่าขณะนี้ไม่มีข้อมูลเพิ่มเติม ขณะที่ EINTR อาจต้องลองใหม่ ทั้งสองไม่ใช่เหตุการณ์เดียวกับ EOF

อย่าค้นหาธง FIN ในบัฟเฟอร์ไบต์ที่ส่งคืน TCP ส่งสตรีมไบต์ตามลำดับให้ API นี้ ขอบเขตแพ็กเก็ตและส่วน FIN ไม่ใช่เพย์โหลดแอปพลิเคชันปกติ

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