QUIC ยังไม่เร็วพอในอินเทอร์เน็ตความเร็วสูง
-
ภูมิหลังของงานวิจัย
- คาดว่า QUIC จะมีบทบาทสำคัญในการปรับปรุงประสิทธิภาพของเว็บแอปพลิเคชัน
- งานวิจัยนี้ศึกษาประสิทธิภาพของ QUIC บนเครือข่ายความเร็วสูงอย่างเป็นระบบ
-
ข้อค้นพบหลัก
- บนอินเทอร์เน็ตความเร็วสูง สแตก UDP+QUIC+HTTP/3 มีความเร็วในการส่งข้อมูลลดลงได้สูงสุด 45.2% เมื่อเทียบกับ TCP+TLS+HTTP/2
- ยิ่งแบนด์วิดท์พื้นฐานเพิ่มขึ้น ความแตกต่างด้านประสิทธิภาพระหว่าง QUIC กับ HTTP/2 ก็ยิ่งมากขึ้น
- ปัญหานี้ส่งผลไม่เฉพาะกับการถ่ายโอนไฟล์เท่านั้น แต่ยังรวมถึงการสตรีมวิดีโอ (บิตเรตวิดีโอลดลงสูงสุด 9.8%) และการท่องเว็บ เป็นต้น
-
วิธีการวิเคราะห์
- ระบุสาเหตุรากของปัญหาผ่านการวิเคราะห์ packet trace รวมถึงการทำ profiling ทั้งใน kernel space และ user space
- สาเหตุหลักคือโอเวอร์เฮดในการประมวลผลฝั่งรับที่สูง โดยเฉพาะแพ็กเก็ตข้อมูลที่มากเกินไปและ ACK ของ QUIC ที่ทำงานใน user space
-
คำแนะนำเพื่อการปรับปรุง
- นำเสนอข้อแนะนำที่เป็นรูปธรรมเพื่อบรรเทาปัญหาด้านประสิทธิภาพที่พบ
สรุปโดย GN⁺
- งานวิจัยนี้วิเคราะห์ปัญหาด้านประสิทธิภาพของ QUIC ในสภาพแวดล้อมเครือข่ายความเร็วสูง และมอบอินไซต์สำคัญที่อาจช่วยยกระดับประสิทธิภาพของเว็บแอปพลิเคชัน
- งานวิจัยชี้ว่า สาเหตุของประสิทธิภาพที่ลดลงของ QUIC คือโอเวอร์เฮดในการประมวลผลฝั่งรับ พร้อมเสนอแนวทางที่เป็นรูปธรรมในการแก้ไข จึงเป็นข้อมูลที่มีประโยชน์สำหรับวิศวกรเครือข่ายและนักพัฒนา
- โปรโตคอลอื่นที่มีฟังก์ชันใกล้เคียงกันคือ HTTP/2 และการเปรียบเทียบประสิทธิภาพกับโปรโตคอลนี้ช่วยชี้ทิศทางการปรับปรุงของ QUIC
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
วงการนี้พยายามทำทุกอย่าง ยกเว้นสร้างเว็บไซต์ที่มีน้ำหนักเบา ช่วงปลายยุค 90 หากคุณมีการเชื่อมต่ออินเทอร์เน็ตที่เร็ว หน้าเว็บจะมีขนาดเล็กและแทบไม่มี JavaScript เลย ทุกวันนี้ก็ยังหาเพจเบา ๆ ที่โหลดเร็วแบบนี้ได้อยู่ และประสบการณ์นั้นแทบจะเหมือนเหนือจริง ถ้าประสบการณ์ผู้ใช้ดีกว่านี้ก็คงพอทนได้มากกว่า
เคยทำงานกับ Speedtest แบบ JS ล้วนที่ Google ตอนนั้น Ookla ยังใช้ Flash อยู่ เลยใช้บน Chromebooks ไม่ได้ ได้เรียนรู้มากเกี่ยวกับการตอบสนองของ TCP ต่อปัจจัยต่าง ๆ พอเห็นบทความนี้ก็รู้สึกว่าผลลัพธ์ออกมาตามคาด เพราะมันผลัก flow control จากเคอร์เนลไปไว้ใน user space แทน TCP มีทั้ง flow control และ sequencing ส่วน QUIC ทำให้มันต้องจัดการเอง TCP congestion control ไม่ค่อยเข้ากับความเร็วการเชื่อมต่อสมัยใหม่ จึงต้องมีอัลกอริทึมใหม่อย่าง BRR ซึ่งมีต้นทุน บทเรียนที่ใหญ่ที่สุดคืออย่ามองข้ามความสำคัญของ latency ในการทดสอบเครือข่าย คนที่อยู่ในเอเชียหรือออสเตรเลียน่าจะรู้ดีว่า RTT latency ระดับ 100ms ร้ายแรงแค่ไหน โอเวอร์เฮดของ QUIC อาจไม่ได้สำคัญมากในทางปฏิบัติ เพราะแบนด์วิดท์จริงผ่าน TCP connection เดียวหรือ QUIC stream เดียวอาจต่ำกว่าแบนด์วิดท์ดิบมาก
Daniel Stenberg ผู้สร้างและผู้ดูแล Curl เคยเขียนบล็อกเกี่ยวกับ HTTP/3 โดยเน้นว่ามันใช้ CPU สูง และบอกว่า CPU อาจกลายเป็นตัวจำกัด throughput ได้ เลยสงสัยว่านี่เป็นเพราะ implementation ยังไม่สุกงอม หรือเป็นเพราะแนวทางการออกแบบของ QUIC เอง
บนอินเทอร์เน็ตความเร็วสูง สแตก UDP+QUIC+HTTP/3 ทำให้ความเร็วในการรับส่งข้อมูลลดลงได้สูงสุด 45.2% เมื่อเทียบกับ TCP+TLS+HTTP/2 ยังไม่ได้อ่านทั้งงานวิจัย แต่ดูเหมือนว่าความเร็วต่ำกว่า 600 Mbit/s จะถูกจัดว่าเป็น "อินเทอร์เน็ตช้า"
มีคนบอกว่า QUIC เร็วไม่พอสำหรับอินเทอร์เน็ตความเร็วสูง เคยทำความเร็ว 900mbps ได้บน quic+http3 และก็สงสัยว่าเป็นเพราะ implementation ของ TLS แย่ หรือเพราะ implementation ระยะแรกยังไม่มีประสิทธิภาพ โดยการใช้ CPU เฉลี่ยอยู่ที่ราว 5% บนคอร์ gen 2 epyc
คำว่า "อินเทอร์เน็ตความเร็วสูง" ที่นี่คือ 500Mbps และบอกว่าเป็นเพราะ quic พึ่งพา CPU ไม่ได้ตรวจดูว่าระบบทดสอบเป็นเครื่องผู้บริโภคทั่วไป หรือแม้แต่บนเดสก์ท็อประดับสูงก็ยังมีปัญหา
เคยนึกว่า QUIC ถูกปรับแต่งมาเพื่อ latency โดยเหมาะกับการโหลดแพ็กเก็ตเล็ก ๆ จำนวนมากในเว็บเพจและวิดีโอเกม ถ้าวัดเฉพาะ throughput รวมอาจดูด้อยกว่า เลยสงสัยว่าในระดับโปรโตคอลจะสามารถตรวจจับการส่งไฟล์ขนาดใหญ่หรือการสตรีมวิดีโอแบนด์วิดท์สูง แล้วสลับไปใช้วิธีที่กิน CPU น้อยกว่านี้ได้หรือไม่ และก็สงสัยว่า QUIC ยังได้รับการปรับแต่งในระดับฮาร์ดแวร์/OS น้อยกว่า TCP หรือไม่
อยากให้ QUIC มีโหมดที่ไม่มี TLS บ้าง เวลา develop บนเครื่อง local บางครั้งก็อยากเห็นข้อมูลที่ถูกส่งจริง ๆ และตอนนี้มันเพิ่มแรงเสียดทานที่ไม่จำเป็น