โซลูชันใหม่ที่ใช้ eBPF ซึ่งห่อหุ้มแพ็กเก็ต TCP ด้วยส่วนหัว UDP เพื่อหลีกเลี่ยง network middleboxes ได้จุดประกายการถกเถียงเกี่ยวกับการพัฒนาโปรโตคอลและการประยุกต์ใช้เพื่อหลีกเลี่ยงการเซ็นเซอร์ เทคนิคนี้แก้ไขปัญหาที่อุปกรณ์เครือข่ายบล็อกหรือปรับเปลี่ยนการเชื่อมต่อ MPTCP โดยเฉพาะในเครือข่ายมือถือที่ใช้ Performance Enhancing Proxies
QUIC เทียบกับ TCP-in-UDP: การถกเถียงโปรโตคอลครั้งใหญ่
ชุมชนกำลังเปรียบเทียบแนวทางนี้กับ multipath QUIC อย่างแข็งขัน โดยตั้งคำถามว่าโซลูชันไหนให้ประโยชน์ที่ดีกว่า แม้ว่าทั้งสองโปรโตคอลจะใช้ tunnel ผ่าน UDP เพื่อหลีกเลี่ยงการรบกวนจาก middlebox แต่ก็มีจุดประสงค์ที่แตกต่างกัน TCP-in-UDP รักษาการใช้งาน TCP ที่มีอยู่และกลไกการควบคุมความแออัดที่ผ่านการทดสอบมาแล้ว ทำให้เหมาะสำหรับระบบเก่าที่ต้องการความเข้ากันได้
TCP-in-UDP รักษาตรรกะที่ผ่านการทดสอบของ TCP แต่ห่อหุ้มเพื่อหลีกเลี่ยง middleboxes ซึ่งเหมาะสำหรับระบบเก่า QUIC เป็นการเขียนใหม่หมด เหมาะสำหรับแอปพลิเคชันใหม่กว่า
อย่างไรก็ตาม นักวิจารณ์ชี้ให้เห็นว่าการห่อหุ้ม TCP ใน UDP นั้นขจัดประโยชน์ด้านความเข้ากันได้โดยพื้นฐาน เนื่องจาก middleboxes และระบบปฏิบัติการไม่สามารถจดจำโปรโตคอลพื้นฐานได้อีกต่อไป สิ่งนี้ทำให้เกิดคำถามเกี่ยวกับว่าแนวทางไหนเหมาะสมเมื่อไหร่
MPTCP: Multipath TCP อนุญาตให้การเชื่อมต่อใช้เส้นทางเครือข่ายหลายเส้นทางพร้อมกัน eBPF: Extended Berkeley Packet Filter อนุญาตให้โปรแกรมที่กำหนดเองทำงานในพื้นที่ kernel
การเปรียบเทียบ Header ของ Protocol
| Protocol | ขนาด Header | คุณสมบัติหลัก |
|---|---|---|
| UDP | 8 bytes | เรียบง่าย, connectionless |
| TCP | 20+ bytes | Connection-oriented, เชื่อถือได้ |
| TCP-in-UDP | 20+ bytes | ฟังก์ชันการทำงานของ TCP ผ่าน UDP transport |
ศักยภาพการหลีกเลี่ยงการเซ็นเซอร์ที่ไม่ได้ตั้งใจ
แม้ว่าจะไม่ใช่เป้าหมายการออกแบบหลัก แต่การแปลง TCP-in-UDP ได้ดึงดูดความสนใจในฐานะเครื่องมือหลีกเลี่ยงการเซ็นเซอร์ที่มีศักยภาพ การแปลโปรโตคอลอาจเพียงพอที่จะหลบเลี่ยงการจับคู่รูปแบบที่ไฟร์วอลล์พื้นฐานใช้ แม้ว่าผู้เชี่ยวชาญจะยังคงสงสัยเกี่ยวกับประสิทธิภาพของมันต่อระบบตรวจสอบแพ็กเก็ตเชิงลึกที่ซับซ้อน
ความสำเร็จของเทคนิคนี้จะขึ้นอยู่กับความสามารถของระบบเซ็นเซอร์เป็นหลัก สภาพแวดล้อมองค์กรที่มีการกรองพื้นฐานอาจถูกหลีกเลี่ยงได้ แต่ระบบขั้นสูงที่อนุญาตเฉพาะการรับส่งข้อมูล UDP ที่เฉพาะเจาะจงหรือทำการวิเคราะห์ในระดับแอปพลิเคชันน่าจะบล็อกความพยายามดังกล่าว
ความท้าทายในการใช้งานทางเทคนิค
โซลูชันนี้เผชิญกับอุปสรรคทางเทคนิคหลายประการที่เน้นย้ำถึงความซับซ้อนของ network stacks สมัยใหม่ การปรับปรุงฮาร์ดแวร์อย่าง Generic Receive Offload (GRO) และ TCP Segmentation Offload (TSO) ต้องถูกปิดใช้งานเพราะแต่ละแพ็กเก็ต UDP มีข้อมูลส่วนหัวเฉพาะของ TCP ที่ไม่สามารถรวมกันได้ง่าย
การจัดการ checksum พิสูจน์ให้เห็นว่าเป็นเรื่องที่ท้าทายเป็นพิเศษ ต้องใช้การรวมกันของ eBPF hooks และ Linux Traffic Control actions เพื่ออัปเดต checksums อย่างถูกต้องเมื่อสลับระหว่างโปรโตคอล การใช้งานนี้ยังสูญเสียฟังก์ชัน Urgent Pointer ของ TCP แม้ว่าสิ่งนี้จะไม่ค่อยส่งผลต่อแอปพลิเคชันส่วนใหญ่
ข้อกำหนดทางเทคนิค
- การสนับสนุน eBPF สำหรับการจัดการแพ็กเก็ต
- ปิดการใช้งาน hardware offloading ( GRO , TSO , GSO )
- การจัดการ checksum แบบกำหนดเองผ่าน TC ACT_CSUM
- การปรับแต่ง MTU/MSS ที่อาจจำเป็นสำหรับเครือข่ายมือถือ
- Linux kernel ที่มีการสนับสนุน TC ( Traffic Control )
IPv6 และเครือข่ายในอนาคต
การถกเถียงได้ขยายไปสู่การพัฒนาเครือข่ายในวงกว้าง โดยสมาชิกชุมชนบางคนเน้นย้ำถึงศักยภาพของ IPv6 ในการทำให้ความท้าทายด้านเครือข่ายปัจจุบันหลายอย่างง่ายขึ้น IPv6 สามารถลดความซับซ้อนของเราเตอร์และขจัดความจำเป็นของ Network Address Translation (NAT) แม้ว่าการลดต้นทุนฮาร์ดแวร์อาจไม่ได้มีนัยสำคัญเท่าที่บางคนหวัง
การถกเถียงสะท้อนถึงความตึงเครียดที่ดำเนินต่อไประหว่างการรักษาความเข้ากันได้กับโครงสร้างพื้นฐานที่มีอยู่และการนำโปรโตคอลที่สะอาดและทันสมัยกว่ามาใช้ซึ่งสามารถแก้ปัญหาเครือข่ายพื้นฐานได้
แนวทาง TCP-in-UDP นี้แสดงถึงอีกก้าวหนึ่งในการพัฒนาโปรโตคอลอินเทอร์เน็ตที่ดำเนินต่อไป โดยสร้างสมดุลระหว่างความต้องการความเข้ากันได้ในทางปฏิบัติกับความปรารถนาที่จะเอาชนะการแข็งตัวของเครือข่ายที่ป้องกันไม่ให้เทคโนโลยีใหม่ทำงานได้อย่างถูกต้อง
อ้างอิง: Introducing TCP-in-UDP solution