- มีการส่งแพตช์แรกสำหรับการผสานโปรโตคอล QUIC เข้าสู่ เคอร์เนลลินุกซ์ อย่างเป็นทางการ
- มีเป้าหมายเพื่อแก้ข้อจำกัดของ TCP เดิม เช่น ความหน่วง, head-of-line blocking, และการแข็งตัวของโปรโตคอลจากอุปกรณ์ตัวกลาง
- QUIC ทำงานบน UDP รองรับมัลติสตรีมและการเข้ารหัสแบบ End-to-End ซึ่งเมื่อเข้าไปอยู่ในเคอร์เนลแล้วจะเพิ่มโอกาสในการใช้งานบนแพลตฟอร์มและฮาร์ดแวร์ที่กว้างขึ้น
- ประสิทธิภาพของการติดตั้งใช้งานในเคอร์เนลช่วงแรกยังวัดได้ต่ำกว่า TCP เดิมและ kernel TLS แต่คาดว่าจะปรับปรุงได้ในอนาคตผ่าน hardware offloading และการเพิ่มประสิทธิภาพ
- ขณะนี้มีการหารือเรื่องการรองรับใน Samba, SMB/NFS บนเคอร์เนล, curl และอื่น ๆ อย่างคึกคัก แต่คาดว่ายังต้องใช้เวลาอีกพอสมควรกว่าจะถูกรวมเข้า mainline
ที่มาของโปรโตคอล QUIC และข้อจำกัดของ TCP
- QUIC ถูกสร้างขึ้นมาเพื่อแก้ปัญหาหลายอย่างของ TCP บนอินเทอร์เน็ตแบบเดิม
- ความหน่วงจาก 3-way handshake ในขั้นตอนเชื่อมต่อของ TCP, การรองรับมัลติสตรีมที่ยังไม่ดีพอ, และปัญหา head-of-line blocking เมื่อเกิด packet loss ล้วนทำให้ประสบการณ์ใช้งานเว็บแย่ลง
- metadata ของ TCP ถูกส่งโดยไม่เข้ารหัส ทำให้มีความเสี่ยงด้านการรั่วไหลของข้อมูล และ middlebox (อุปกรณ์ตัวกลาง) บนอินเทอร์เน็ตก็กรองทราฟฟิกตามข้อมูลการเชื่อมต่อ จนนำไปสู่ การแข็งตัวของโปรโตคอล (ossification)
- แม้จะมีความพยายามปรับปรุง TCP (เช่น Multipath TCP) ก็ยังอยู่ในสภาพที่หากไม่ปลอมตัวเป็น TCP แบบเดิมก็ทำงานได้ไม่สมบูรณ์
คุณลักษณะและข้อได้เปรียบทางเทคนิคของ QUIC
- QUIC ทำงานบน UDP และสามารถตั้งค่าการเชื่อมต่อได้รวดเร็วโดยไม่ต้องมี 3-way handshake แยกต่างหาก
- มีการออกแบบการส่งแบบ มัลติสตรีม เพื่อไม่ให้ packet loss กระทบทั้งสตรีมทั้งหมด
- ข้อมูลการส่งที่เกี่ยวข้องกับ QUIC จะถูก เข้ารหัสแบบ end-to-end (อิง TLS) ตลอดเวลา ทำให้อุปกรณ์ตัวกลางไม่สามารถเข้าถึงข้อความภายในได้
- หากเป็นสภาพแวดล้อมเครือข่ายที่แพ็กเก็ต UDP ผ่านได้ QUIC ก็สามารถทำงานได้ตามปกติเช่นกัน
ภาพรวมของแพตช์ผสาน QUIC เข้าสู่เคอร์เนลลินุกซ์
- ในแพตช์ที่ส่งเข้ามามีการเพิ่มชนิดโปรโตคอลใหม่ชื่อ IPPROTO_QUIC ทำให้สามารถใช้ system call socket() แบบเดิมได้
- สามารถใช้คำสั่งเรียกอย่าง bind(), connect(), listen(), accept() ได้คล้ายกับ TCP แต่แนวทางการทำงานหลังจากนั้นมีความแตกต่าง
- การจัดการ TLS session และกระบวนการยืนยันตัวตน/เข้ารหัส จะประมวลผลใน userspace และหลังเชื่อมต่อแล้วแต่ละฝั่งต้องทำ TLS handshake ให้เสร็จก่อนจึงจะรับส่งข้อมูลได้
- หลังการเชื่อมต่อครั้งแรกสามารถ แคชผลการเจรจา TLS เอาไว้ เพื่อเร่งความเร็วอย่างมากเมื่อสองระบบเชื่อมต่อกันใหม่
ความท้าทายด้านประสิทธิภาพและแนวโน้ม
- การติดตั้งใช้งาน QUIC ภายในเคอร์เนล ที่ส่งเข้ามายังด้อยกว่า kernel TLS และ TCP เดิมในด้านประสิทธิภาพ
- throughput ต่ำกว่า in-kernel TLS มากกว่า 3 เท่า และแม้ปิดการเข้ารหัสก็ยังมี throughput ต่ำกว่า TCP ได้สูงสุดถึง 4 เท่า
- สาเหตุที่ถูกชี้ถึงได้แก่ ยังไม่รองรับ segmentation offloading, มีการคัดลอกข้อมูลเพิ่มในเส้นทางส่งข้อมูล และมีขั้นตอนเข้ารหัสส่วนหัว
- ในอนาคตหากเพิ่มการรองรับ hardware offloading และปรับแต่ง implementation ในเคอร์เนลให้ดีขึ้น ก็คาดว่าประสิทธิภาพจะดีขึ้น
สถานะการนำไปใช้และแนวโน้มต่อจากนี้
- มีการหารือเรื่อง การรองรับ QUIC ในเคอร์เนล อย่างคึกคักในหลาย โปรเจกต์ เช่น เซิร์ฟเวอร์/ไคลเอนต์ Samba, ระบบไฟล์ SMB และ NFS บนเคอร์เนล, รวมถึง curl
- แพตช์มีขนาดราว 9,000 บรรทัด และตอนนี้ยังมีเพียงโค้ดรองรับระดับล่างเท่านั้น โดย implementation ทั้งหมดยังจะตามมาในแพตช์เพิ่มเติม
- การรีวิวโค้ดและการหารือเพื่อรวมเข้าระบบเพิ่งเริ่มต้น จึงคาดว่าจะยังต้องใช้เวลาอีกมากกว่าจะใช้งานจริงได้
- เมื่อดูจากกรณีของโปรโตคอล Homa ที่ต้องส่งถึง 11 ครั้งในช่วง 9 เดือนกว่าจะถูกรวมเข้าเคอร์เนล ก็มีแนวโน้มว่า QUIC เองอาจได้เข้าสู่ mainline หลังปี 2026
ยังไม่มีความคิดเห็น