QUIC không đủ nhanh trên Internet tốc độ cao

• QUIC là giao thức được kỳ vọng sẽ mang lại bước thay đổi đột phá trong việc cải thiện hiệu năng ứng dụng web, nhưng hiệu năng thực tế không đạt như kỳ vọng
• Bài báo này phân tích một cách có hệ thống hiệu năng của QUIC trên các mạng tốc độ cao

Tóm tắt

• Trên Internet tốc độ cao, ngăn xếp UDP+QUIC+HTTP/3 cho thấy thông lượng dữ liệu giảm tới 45,2% so với TCP+TLS+HTTP/2
• Khoảng cách hiệu năng giữa QUIC và HTTP/2 càng lớn khi băng thông cơ sở tăng lên
• Vấn đề này được quan sát trên các ứng dụng khách truyền dữ liệu nhẹ và các trình duyệt web phổ biến (Chrome, Edge, Firefox, Opera), trên nhiều loại thiết bị (máy tính để bàn, di động) và nhiều loại mạng khác nhau (băng rộng có dây, mạng di động)
• Không chỉ ảnh hưởng đến truyền tệp mà còn tác động đến nhiều ứng dụng khác như truyền phát video (giảm bitrate video tới 9,8%), duyệt web, v.v.
• Thông qua phân tích truy vết gói tin nghiêm ngặt cùng với profiling ở không gian kernel và không gian người dùng, nghiên cứu đã xác định được nguyên nhân gốc rễ
• Cụ thể, chi phí xử lý phía máy nhận tăng cao do số lượng gói dữ liệu quá mức và ACK của QUIC được xử lý ở không gian người dùng
• Nghiên cứu cũng đưa ra các khuyến nghị cụ thể để giảm thiểu các vấn đề hiệu năng đã quan sát được

Nguyên nhân gốc rễ của suy giảm hiệu năng

• Phát sinh chi phí xử lý gói tin quá mức ở cấp kernel phía máy nhận
  • QUIC không sử dụng UDP GRO (Generic Receive Offload), nên phải xử lý nhiều gói tin hơn rất nhiều so với TCP
  • Điều này được xác nhận qua số lần gọi hàm netif_receive_skb cao hơn nhiều ở QUIC
• QUIC cũng phát sinh chi phí xử lý gói tin quá mức trong không gian người dùng
  • Có chi phí lớn khi xử lý số lượng lớn gói tin được chuyển lên từ kernel
  • Việc tạo QUIC ACK trong không gian người dùng cũng là một nguyên nhân gây overhead

Đề xuất để giảm thiểu suy giảm hiệu năng

• Áp dụng UDP GRO ở phía máy nhận
  • Giảm số lượng gói tin mà ngăn xếp UDP phải xử lý, từ đó giảm overhead ở cả kernel và không gian người dùng
  • Tuy nhiên, việc triển khai UDP GRO trên nhiều môi trường client khác nhau có thể không dễ dàng
• Cải tiến các giải pháp offloading như GSO/GRO để phù hợp hơn với QUIC
  • Hỗ trợ offloading cả các chuỗi gói UDP có kích thước khác nhau
  • Bổ sung thiết lập pacing phù hợp cho GSO để tránh tắc nghẽn mạng
• Tối ưu hóa logic QUIC ở phía máy nhận
  • Trì hoãn việc gửi QUIC ACK để giảm overhead khi tạo phản hồi
  • Sử dụng recvmmsg để đọc nhiều gói UDP trong một lần, qua đó cải thiện hiệu năng
• Sử dụng tải xuống đa luồng
  • Với các tệp lớn, tải xuống đa luồng tận dụng nhiều lõi CPU có thể cải thiện hiệu năng nhận
  • Tuy nhiên, cần cân nhắc vấn đề công bằng

[GN⁺]

Ý kiến trên Hacker News

• Giao diện syscall phức tạp, và API cơ bản quá chậm so với các gói tin kích thước thông thường (khoảng 1500 byte)
  • GSO có ích nhưng API phức tạp và gần đây vẫn còn nhiều lỗi
• Chi phí syscall đã tăng cao hơn do các biện pháp giảm thiểu Spectre
  • Cần thay thế BSD sockets/POSIX API
  • uring phức tạp, nhưng cần một API ở mức trung gian
• Bộ đệm UDP của hệ thống mặc định quá nhỏ
  • Chỉ các chuyên gia mới dùng, và họ sẽ tự điều chỉnh cấu hình
• Có thể tối ưu hóa stack UDP
  • GSO cho thấy điều đó, nhưng bản thân GSO cũng tốn kém và phức tạp
• Một số tối ưu hóa hiện có chỉ hoạt động ở quy mô nhỏ/trung bình
  • Ví dụ, bind kết nối để tránh tra cứu đường đi
• Việc triển khai GSO có thể cải thiện hiệu năng đáng kể
  • Có lẽ sẽ cần tăng kích thước bộ đệm ở phía nền tảng
• Ở giai đoạn đầu của QUIC, stack UDP được tối ưu hóa kém hơn stack TCP
  • Cần các tối ưu hóa như UDP generic receive offload
• Có vẻ HTTP/2 cũng đã được phát hành quá vội vàng
  • Chrome đã loại bỏ hỗ trợ server push
  • Cần suy nghĩ kỹ hơn
• QUIC và HTTP/2 cho hiệu năng tương tự khi băng thông mạng thấp
  • Khi băng thông vượt quá 500Mbps, hiệu năng QUIC giảm xuống
  • Đây chủ yếu là vấn đề trong mạng cục bộ
• Google có xu hướng đẩy gánh nặng xử lý sang phía người dùng
  • Ví dụ, codec video AV1 được triển khai tới người dùng khi thiết bị tiêu dùng chưa có khả năng giải mã phần cứng
• Bài nghiên cứu có trên arXiv
  • https://arxiv.org/pdf/2310.09423
• Có nhắc tới ping với RTT là 0.23ms
  • Ngay cả ở độ trễ cao, QUIC vẫn là tốt nhất
• Việc đọc RFC9000 khó và phức tạp
  • Ý tưởng cấp cao của QUIC thì đơn giản, nhưng đặc tả yêu cầu xử lý rất nhiều ngoại lệ
• Có cung cấp bản PDF miễn phí của nghiên cứu
  • https://arxiv.org/pdf/2310.09423
• Việc chuyển giao thức kết nối sang user space có thể không phải là một kế hoạch tốt