QUIC ไม่เร็วพอสำหรับอินเทอร์เน็ตความเร็วสูง

• QUIC เป็นโปรโตคอลที่ถูกคาดหวังว่าจะนำมาซึ่งการเปลี่ยนแปลงครั้งสำคัญในการเพิ่มประสิทธิภาพของเว็บแอปพลิเคชัน แต่ประสิทธิภาพกลับไม่เป็นไปตามที่คาดหวัง
• บทความวิจัยนี้วิเคราะห์ประสิทธิภาพของ QUIC บนเครือข่ายความเร็วสูงอย่างเป็นระบบ

บทคัดย่อ

• บนอินเทอร์เน็ตความเร็วสูง สแตก UDP+QUIC+HTTP/3 แสดงอัตราการส่งข้อมูลลดลงสูงสุด 45.2% เมื่อเทียบกับ TCP+TLS+HTTP/2
• ช่องว่างด้านประสิทธิภาพระหว่าง QUIC และ HTTP/2 จะยิ่งกว้างขึ้นเมื่อแบนด์วิดท์พื้นฐานเพิ่มขึ้น
• ปัญหานี้พบได้ทั้งในไคลเอนต์รับส่งข้อมูลแบบเบาและเว็บเบราว์เซอร์หลัก (Chrome, Edge, Firefox, Opera) บนโฮสต์หลากหลายประเภท (เดสก์ท็อป, มือถือ) และเครือข่ายหลากหลายแบบ (บรอดแบนด์แบบมีสาย, เซลลูลาร์)
• ส่งผลกระทบไม่ใช่แค่การโอนไฟล์ แต่รวมถึงแอปพลิเคชันหลากหลายประเภท เช่น การสตรีมวิดีโอ (บิตเรตวิดีโอลดลงสูงสุด 9.8%) และการท่องเว็บ
• ระบุสาเหตุรากของปัญหาผ่านการวิเคราะห์ packet trace อย่างเข้มงวด รวมถึงการทำโปรไฟล์ในเคอร์เนลและ user space
• โดยเฉพาะอย่างยิ่ง พบว่าโอเวอร์เฮดการประมวลผลฝั่งตัวรับสูงจากแพ็กเก็ตข้อมูลจำนวนมากเกินไปและ ACK ของ QUIC ที่ทำใน user space
• เสนอคำแนะนำเชิงรูปธรรมเพื่อบรรเทาปัญหาด้านประสิทธิภาพที่สังเกตพบ

สาเหตุรากของประสิทธิภาพที่ลดลง

• เกิดโอเวอร์เฮดจากการประมวลผลแพ็กเก็ตมากเกินไปที่ระดับเคอร์เนลฝั่งตัวรับ
  • QUIC ไม่ได้ใช้ UDP GRO (Generic Receive Offload) จึงต้องประมวลผลแพ็กเก็ตมากกว่า TCP อย่างมาก
  • ยืนยันได้จากจำนวนครั้งที่มีการเรียกฟังก์ชัน netif_receive_skb ซึ่งสูงกว่าใน QUIC อย่างชัดเจน
• เกิดโอเวอร์เฮดจากการประมวลผลแพ็กเก็ตมากเกินไปใน user space ของ QUIC เช่นกัน
  • มีโอเวอร์เฮดสูงในการจัดการแพ็กเก็ตจำนวนมากที่เคอร์เนลส่งขึ้นมา
  • การสร้าง QUIC ACK ใน user space ก็เป็นอีกสาเหตุของโอเวอร์เฮด

ข้อเสนอเพื่อบรรเทาประสิทธิภาพที่ลดลง

• นำ UDP GRO มาใช้ฝั่งตัวรับ
  • ลดจำนวนแพ็กเก็ตที่ต้องประมวลผลในสแตก UDP เพื่อลดโอเวอร์เฮดทั้งในเคอร์เนลและ user space
  • อย่างไรก็ตาม การนำ UDP GRO ไปใช้งานจริงในสภาพแวดล้อมไคลเอนต์ที่หลากหลายอาจไม่ใช่เรื่องง่าย
• ปรับปรุงโซลูชัน offloading เช่น GSO/GRO ให้เหมาะกับ QUIC
  • รองรับการ offload แม้เป็นชุดของแพ็กเก็ต UDP ที่มีขนาดต่างกัน
  • เพิ่มการตั้งค่า pacing ที่เหมาะสมให้กับ GSO เพื่อป้องกันความแออัดของเครือข่าย
• ปรับแต่งลอจิก QUIC ฝั่งตัวรับให้เหมาะสม
  • หน่วงเวลาการส่ง QUIC ACK เพื่อลดโอเวอร์เฮดจากการสร้างการตอบสนอง
  • ใช้ recvmmsg เพื่ออ่านแพ็กเก็ต UDP หลายรายการพร้อมกันและปรับปรุงประสิทธิภาพ
• ใช้การดาวน์โหลดแบบหลายเธรด
  • สำหรับไฟล์ขนาดใหญ่ การดาวน์โหลดแบบหลายเธรดที่ใช้หลายคอร์ของ CPU อาจช่วยเพิ่มประสิทธิภาพการรับข้อมูลได้
  • แต่ต้องคำนึงถึงประเด็นด้านความเป็นธรรมด้วย

[GN⁺]

ความเห็นจาก Hacker News

• อินเทอร์เฟซ syscall ซับซ้อน และ API พื้นฐานก็ช้าเกินไปเมื่อเทียบกับแพ็กเก็ตขนาดทั่วไป (ประมาณ 1500 ไบต์)
  • GSO ช่วยได้ แต่ API ซับซ้อนและแม้แต่ช่วงหลัง ๆ ก็ยังมีบั๊กเยอะ
• ค่าใช้จ่ายของ syscall สูงขึ้นจากการบรรเทา Spectre
  • จำเป็นต้องมีสิ่งมาแทนที่ BSD socket/POSIX API
  • uring ซับซ้อน แต่ก็ยังต้องการ API ระดับกลาง
• บัฟเฟอร์ UDP ของระบบมีขนาดเล็กเกินไปโดยปริยาย
  • มีแต่ผู้เชี่ยวชาญที่ใช้งาน และผู้เชี่ยวชาญก็มักปรับแต่งค่าคอนฟิก
• สแตก UDP ยังปรับแต่งเพิ่มได้
  • GSO แสดงให้เห็นจุดนี้ แต่ตัว GSO เองก็มีต้นทุนสูงและซับซ้อน
• การเพิ่มประสิทธิภาพบางอย่างที่ใช้ได้ในตอนนี้ทำงานได้แค่ในสเกลเล็ก/กลาง
  • เช่น การ bind การเชื่อมต่อเพื่อหลีกเลี่ยงการ lookup เส้นทาง
• หากทำ GSO ได้ ประสิทธิภาพอาจดีขึ้นอย่างมาก
  • น่าจะต้องเพิ่มขนาดบัฟเฟอร์ฝั่งแพลตฟอร์มด้วย
• ในช่วงแรกของ QUIC สแตก UDP ยังได้รับการปรับแต่งน้อยกว่าสแตก TCP
  • ต้องการการเพิ่มประสิทธิภาพอย่าง UDP generic receive offload
• ดูเหมือนว่า HTTP/2 ก็ถูกรีบปล่อยออกมาด้วย
  • Chrome เอาการรองรับ server push ออกแล้ว
  • ต้องคิดให้รอบคอบกว่านี้
• QUIC กับ HTTP/2 ให้ประสิทธิภาพใกล้เคียงกันเมื่อแบนด์วิดท์เครือข่ายต่ำ
  • แต่เมื่อแบนด์วิดท์เกิน 500Mbps ประสิทธิภาพของ QUIC จะลดลง
  • ปัญหานี้มักเกิดในเครือข่ายภายในเป็นหลัก
• Google มีแนวโน้มจะผลักภาระการประมวลผลไปให้ผู้ใช้
  • เช่น ปล่อยโค้ดกวิดีโอ AV1 ออกมาในตอนที่ฝั่งผู้บริโภคยังไม่มีความสามารถถอดรหัสด้วยฮาร์ดแวร์
• มีบทความวิจัยอยู่บน arXiv
  • https://arxiv.org/pdf/2310.09423
• มีการพูดถึง ping ที่ RTT 0.23ms
  • แม้ในสภาวะที่ latency สูง QUIC ก็ยังดีที่สุด
• การอ่าน RFC9000 เป็นเรื่องยากและซับซ้อน
  • แนวคิดระดับสูงของ QUIC นั้นเรียบง่าย แต่สเปกบังคับให้ต้องจัดการกรณียกเว้นจำนวนมาก
• มีไฟล์ PDF ของงานวิจัยให้ดาวน์โหลดฟรี
  • https://arxiv.org/pdf/2310.09423
• การย้ายโปรโตคอลการเชื่อมต่อไปไว้ใน user space อาจไม่ใช่แผนที่ดี