ชุมชนเทคโนโลยีกำลังมีการถกเถียงอย่างร้อนแรงเกี่ยวกับ QUIC โปรโตคอลขนส่งสมัยใหม่ที่ออกแบบมาเพื่อแทนที่ TCP สำหรับการรับส่งข้อมูลเว็บ ในขณะที่บทความทางเทคนิคชื่นชมสถาปัตยกรรม user-space และโซลูชันแก้ไขปัญหา head-of-line blocking ของ QUIC การอภิปรายในหมู่ผู้พัฒนากลับเผยให้เห็นความกังวลที่ลึกซึ้งยิ่งขึ้นเกี่ยวกับการแข็งตัวของโปรโตคอล การแทรกแซงจาก middlebox และคำถามว่าการย้ายตรรกะการขนส่งไปยัง user-space นั้นแสดงถึงความก้าวหน้าหรือการแบ่งแยก
ปัญหาการห่อหุ้มด้วย UDP
การอภิปรายส่วนใหญ่เกี่ยวกับ QUIC เน้นไปที่เหตุผลที่มันถูกสร้างขึ้นบน UDP แทนที่จะทำงานบน IP โดยตรงเหมือนโปรโตคอลขนส่งดั้งเดิม การออกแบบเช่นนี้มีที่มาจากสิ่งที่นักพัฒนาเรียกว่า protocol ossification - แนวโน้มที่อุปกรณ์เครือข่ายจะบล็อกโปรโตคอลที่ไม่คุ้นเคย ไฟร์วอลล์และ middlebox ส่วนใหญ่จำกัดการรับส่งข้อมูลอินเทอร์เน็ตให้เหลือเพียง TCP และ UDP เท่านั้น ซึ่งบังคับให้โปรโตคอลใหม่ต้องปลอมตัวอยู่ในโครงสร้างที่ตั้งไว้แล้วเหล่านี้
ผู้แสดงความคิดเห็นหนึ่งคนสรุปความรู้สึกของชุมชนได้อย่างสมบูรณ์แบบ: หาก TCP ถูกคิดค้นในวันนี้ มันไม่สามารถถูกนำไปใช้ได้สำเร็จบนอินเทอร์เน็ตส่วนใหญ่ เว้นแต่มันจะถูกห่อหุ้มใน UDP และเข้ารหัส ความจริงข้อนี้ได้ผลักดันนวัตกรรมให้ไปอยู่ในรูปแบบการห่อหุ้มด้วย UDP โดยมี QUIC เป็นตัวอย่างที่โดดเด่นที่สุด ค่าใช้จ่ายส่วนหัว UDP 8 ไบต์ โดยทั่วไปถือเป็นสิ่งที่ยอมรับได้เมื่อเทียบกับประโยชน์ในการหลีกเลี่ยงการกรองโปรโตคอล ถึงแม้ว่านักพัฒนาบางส่วนจะรู้สึกเสียโอกาสสำหรับการพัฒนาโปรโตคอลขนส่งที่หลากหลายมากขึ้น
การควบคุมใน User-Space: อิสระ หรือ ความวุ่นวาย?
การทำงานของ QUIC ใน user-space แทนที่จะเป็น kernel ถือเป็นหนึ่งในแง่มุมที่ถกเถียงกันมากที่สุด ผู้สนับสนุนอ้างว่าสิ่งนี้ช่วยให้เกิดนวัตกรรมอย่างรวดเร็วและการปรับปรุงเฉพาะแอปพลิเคชัน ซึ่งเป็นไปไม่ได้กับการใช้งาน TCP ที่ผูกกับ kernel นักพัฒนาสามารถทดลองอัลกอริทึมควบคุมความแออัดที่ออกแบบมาเฉพาะสำหรับกรณีการใช้งานของพวกเขาได้ โดยไม่ต้องรอการอัปเดตระบบปฏิบัติการ
อย่างไรก็ตาม ผู้ที่สงสัยได้หยิบยกข้อกังวลที่สมเหตุสมผลเกี่ยวกับการจัดการทรัพยากรและความยุติธรรม ผู้แสดงความคิดเห็นหนึ่งคนระบุว่า การสมมติว่าแอปพลิเคชันทุกตัวจะทำการควบคุมความแออัดได้อย่างถูกต้อง ในขณะที่ไม่ไปขัดขวางผู้อื่นแม้จะโดยไม่ตั้งใจ ด้วยขอบเขตการมองเห็นที่จำกัดของ user-space นั้น เป็นความคิดที่ไร้เหตุผลที่สุด หรือไม่ก็เป็นแค่ความหวังลมๆ แล้งๆ สิ่งนี้เกี่ยวข้องกับคำถามพื้นฐานเกี่ยวกับว่าตรรกะการขนส่งควรอยู่ในระบบปฏิบัติการ ซึ่งสามารถจัดการทรัพยากรได้ทั้งระบบ หรือควรอยู่ในแอปพลิเคชันแต่ละตัวที่แสวงหาจุดมุ่งหมายในการปรับให้เหมาะสมของตัวเอง
วิญญาณของ SCTP: บทเรียนจากประวัติศาสตร์โปรโตคอล
การอภิปรายจำนวนมากอ้างอิงถึง SCTP (Stream Control Transmission Protocol) ในฐานะบทเรียนที่สอนใจ SCTP นำเสนอคุณสมบัติคล้าย QUIC หลายอย่าง รวมถึงการสตรีมหลายช่องทางและการเชื่อมต่อหลายเส้นทางมาเกือบ 25 ปีแล้ว แต่ล้มเหลวในการได้รับการยอมรับอย่างกว้างขวาง ส่วนใหญ่เป็นเพราะการบล็อกโดยไฟร์วอลล์ นักพัฒนาหลายคนแบ่งปันประสบการณ์ของการพยายามใช้ SCTP ในสภาพแวดล้อมองค์กรเพียงเพื่อพบว่าถูกบล็อกทันทีโดยทีมความปลอดภัยเครือข่าย
บริบททางประวัติศาสตร์นี้อธิบายปรัชญาการออกแบบของ QUIC: มันคาดการณ์สภาพเครือข่ายที่ต่อต้านและสร้างการเข้ารหัสลงในโปรโตคอลโดยตรงเพื่อป้องกันไม่ให้ middlebox ตรวจสอบหรือปรับเปลี่ยนการรับส่งข้อมูล แม้ว่าสิ่งนี้จะปรับปรุงความน่าเชื่อถือได้ แต่ก็หมายความว่า QUIC ไม่สามารถได้รับประโยชน์จากการเพิ่มประสิทธิภาพระดับเครือข่ายที่ทำงานกับ TCP ได้ สร้างความตึงเครียดระหว่างการควบคุมแบบ end-to-end และประสิทธิภาพการทำงานที่ได้รับความช่วยเหลือจากเครือข่าย
การเปรียบเทียบโปรโตคอล: TCP vs QUIC vs SCTP
| คุณสมบัติ | TCP | QUIC | SCTP |
|---|---|---|---|
| Transport Layer | ทำงานโดยตรงบน IP | ห่อหุ้มด้วย UDP | ทำงานโดยตรงบน IP |
| Multiplexing | ต้องใช้หลาย socket | รองรับ stream multiplexing แบบเนทีฟ | รองรับ stream multiplexing แบบเนทีฟ |
| Head-of-Line Blocking | มี ต่อการเชื่อมต่อ | ไม่มี ต่อ stream | ไม่มี ต่อ stream |
| Encryption | แยกต่างหาก (TLS) | มีในตัว | แยกต่างหาก |
| Deployment | ใช้ได้ทั่วไป | กำลังเติบโต | จำกัดด้วย firewall |
| Congestion Control | ทำงานใน kernel-space | ทำงานใน user-space | ทำงานใน kernel-space |
| NAT Traversal | ท้าทาย | ออกแบบมาเพื่อรองรับ | ท้าทาย |
ความเป็นจริงในการนำไปใช้และการต่อต้านในองค์กร
แม้ QUIC จะมีข้อดีทางเทคนิค แต่การนำไปใช้ในทางปฏิบัติยังต้องเผชิญกับอุปสรรคสำคัญ ผู้แสดงความคิดเห็นหลายคนอธิบายสภาพแวดล้อมองค์กรที่แม้แต่ UDP ยังถูกจำกัด โดยทีมเครือข่ายตั้งคำถามว่าทำไมนักพัฒนาไม่ใช้ TCP แทน ความรู้สึกที่ว่า ส่วนการสนับสนุน QUIC ล่ะ? ไม่มีทางเกิดขึ้นที่นี่ สะท้อนถึงความท้าทายในการนำเสนอโปรโตคอลใหม่เข้าสู่เครือข่ายองค์กรที่保守
ประสบการณ์การพัฒนามีความหลากหลายอย่างมาก across ecosystems ในขณะที่บางภาษามีการใช้งาน QUIC ที่成熟 แล้ว ภาษาอื่นๆ ยังคงอยู่ในสภาพพัฒนาที่ล่าช้าการแบ่งแยกนี้หมายความว่าในปัจจุบัน QUIC ทำหน้าที่เป็นเลเยอร์การขนส่งสำหรับ HTTP/3 มากกว่าเป็นโปรโตคอลอเนกประสงค์ที่นักพัฒนาทุกคนสามารถใช้ได้ เส้นการเรียนรู้สำหรับการใช้งาน QUIC ที่ถูกต้องยังเป็นอุปสรรคเมื่อเทียบกับ TCP sockets ที่เข้าใจกันดี
การอภิปรายเกี่ยวกับข้อบังคับการเข้ารหัส
ข้อกำหนดของ QUIC ที่ต้องมีการเข้ารหัสบังคับได้รับปฏิกิริยาที่หลากหลาย สำหรับแอปพลิเคชันที่ใส่ใจความปลอดภัย การเข้ารหัสในตัวเป็นคุณลักษณะ但对于อื่นๆ แล้ว มันแสดงถึงค่าใช้จ่ายที่ไม่จำเป็น นักพัฒนาหนึ่งคนเรียกมันว่า ค่าใช้จ่ายที่ไร้ประโยชน์สำหรับแอปพลิเคชันที่ไม่ต้องการการเข้ารหัส ถึงแม้ว่าคนอื่นจะแย้งว่าการเข้ารหัสช่วยป้องกันการแทรกแซงจาก middlebox ที่สร้างปัญหาให้กับการใช้งาน TCP
ข้อกำหนดการเข้ารหัสยังทำให้เกิดคำถามเกี่ยวกับแอปพลิเคชันแบบ peer-to-peer และว่า QUIC จะสามารถสนับสนุนวิสัยทัศน์อินเทอร์เน็ตแบบกระจายศูนย์ได้หรือไม่ ในทางเทคนิคแล้วเป็นไปได้ที่จะใช้ใบรับรองที่ลงนามเอง แต่ความเป็นจริงในทางปฏิบัติคือการใช้งาน QUIC ส่วนใหญ่สมมติว่ามีการตรวจสอบความถูกต้องโดย certificate authority ซึ่งอาจทำให้ความไว้วางใจรวมศูนย์ในแบบที่ทำให้สมาชิกในชุมชนบางส่วนกังวล
ข้อได้เปรียบและข้อกังวลหลักของ QUIC
ข้อได้เปรียบ:
- ลดเวลาในการสร้างการเชื่อมต่อ (การกลับมาใช้งานแบบ 0-RTT)
- รองรับการเคลื่อนย้ายที่ดีขึ้น (การโยกย้ายการเชื่อมต่อ)
- กลไกการกู้คืนจากการสูญเสียข้อมูลที่ดีขึ้น
- ความเป็นอิสระของสตรีมช่วยขจัดปัญหาการติดขัดแบบ head-of-line blocking
- การเข้ารหัสตามค่าเริ่มต้นป้องกันการแทรกแซงจาก middlebox
ข้อกังวลจากชุมชน:
- ภาระของการเข้ารหัสแบบบังคับสำหรับทุกกรณีการใช้งาน
- การทำงานใน user-space อาจนำไปสู่การแข่งขันทรัพยากรที่ไม่เป็นธรรม
- ความต้านทานจาก enterprise firewall และนโยบายเครือข่าย
- การพัฒนาที่ยังไม่เป็นผู้ใหญ่ในระบบนิเวศของภาษาโปรแกรมต่างๆ
- การมองเห็นที่ลดลงสำหรับการจัดการและการแก้ไขปัญหาเครือข่าย
มองไปข้างหน้า
การอภิปรายเกี่ยวกับ QUIC สะท้อนให้เห็นถึงความตึงเครียดที่กว้างขึ้นในการวิวัฒนาการของอินเทอร์เน็ต: นวัตกรรม versus ความมั่นคง การควบคุมแบบ end-to-end versus การจัดการทั้งระบบ และโปรโตคอลเปิด versus อิทธิพลจากองค์ cooperate ในขณะที่ QUIC แก้ไขข้อจำกัดที่แท้จริงของ TCP โดยเฉพาะสำหรับแอปพลิเคชันที่อ่อนไหวต่อความล่าช้า ความสำเร็จของมันจะขึ้นอยู่กับการเอาชนะการแข็งตัวของเครือข่ายและการหาความสมดุลที่เหมาะสมระหว่างความยืดหยุ่นของแอปพลิเคชันและความมั่นคงของระบบ
ชุมชนดูเหมือนจะมองอนาคตของ QUIC ในแง่ดีอย่างระมัดระวัง โดยมองว่ามันเป็นเครื่องมือเพิ่มเติมที่มีค่า แทนที่จะเป็นการแทนที่ TCP อย่างสมบูรณ์ เมื่อการใช้งานมีความ成熟 และโครงสร้างพื้นฐานเครือข่ายปรับตัว QUIC อาจส่งมอบตามสัญญาของการขนส่งอินเทอร์เน็ตที่ดีขึ้นในที่สุด - แต่เส้นทางข้างหน้าต้องการการนำทางผ่านทั้งความท้าทายทางเทคนิคและการต่อต้านจากสถาบัน
อ้างอิง: QUIC and the End of TCP Sockets: How User-Space Transport Rewrites Flow Control