QUIC không đủ nhanh trên Internet tốc độ cao
-
Bối cảnh nghiên cứu
- QUIC được kỳ vọng sẽ đóng vai trò quan trọng trong việc cải thiện hiệu năng của các ứng dụng web.
- Bài báo này khảo sát một cách có hệ thống hiệu năng của QUIC trên các mạng tốc độ cao.
-
Phát hiện chính
- Trên Internet tốc độ cao, ngăn xếp UDP+QUIC+HTTP/3 có tốc độ truyền dữ liệu giảm tới 45,2% so với TCP+TLS+HTTP/2.
- Khi băng thông cơ bản tăng lên, chênh lệch hiệu năng giữa QUIC và HTTP/2 càng lớn.
- Vấn đề này 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 nhau như phát video trực tuyến (bitrate video giảm tối đa 9,8%) và duyệt web.
-
Phương pháp phân tích
- Phân tích truy vết gói tin cùng với profiling ở kernel và user space đã được sử dụng để xác định nguyên nhân gốc rễ của vấn đề.
- Overhead xử lý phía nhận cao, đặc biệt là các gói dữ liệu dư thừa và ACK trong user space của QUIC, là nguyên nhân gây ra vấn đề.
-
Khuyến nghị cải thiện
- Đưa ra các khuyến nghị cụ thể nhằm giảm thiểu các vấn đề hiệu năng đã quan sát được.
Tóm tắt của GN⁺
- Bài báo này phân tích các vấn đề hiệu năng của QUIC trong môi trường mạng tốc độ cao, cung cấp những insight quan trọng có thể góp phần cải thiện hiệu năng ứng dụng web.
- Bằng cách xác định nguyên nhân suy giảm hiệu năng của QUIC là overhead xử lý phía nhận và đề xuất các biện pháp cụ thể để khắc phục, bài viết mang lại thông tin hữu ích cho các kỹ sư mạng và nhà phát triển.
- Một giao thức khác có chức năng tương tự là HTTP/2, và việc so sánh hiệu năng với giao thức này cho thấy hướng cải thiện cho QUIC.
1 bình luận
Ý kiến trên Hacker News
Ngành công nghiệp đang thử mọi thứ ngoại trừ việc làm website gọn nhẹ. Vào cuối thập niên 90, nếu có kết nối Internet nhanh thì trang web nhỏ và hầu như không có JavaScript. Ngày nay vẫn có thể tìm thấy những trang nhẹ như vậy tải rất nhanh, và trải nghiệm gần như siêu thực. Nếu trải nghiệm người dùng tốt hơn thì có lẽ mọi người đã chịu đựng được hơn.
Tôi từng làm Speedtest thuần JS ở Google. Khi đó Ookla dựa trên Flash nên không chạy trên Chromebooks. Tôi đã học được rất nhiều về cách TCP phản ứng với nhiều yếu tố khác nhau. Nhìn bài viết này, tôi thấy kết quả đúng như dự đoán, vì nó đẩy điều khiển luồng từ kernel sang user space. TCP có điều khiển luồng và đánh số thứ tự. QUIC thì tự phải quản lý việc đó. Điều khiển tắc nghẽn của TCP không phù hợp với tốc độ kết nối hiện đại nên cần các thuật toán mới như BRR, nhưng điều đó có chi phí. Bài học lớn nhất là đừng xem nhẹ tầm quan trọng của độ trễ trong kiểm thử mạng. Những người sống ở châu Á hoặc Úc sẽ biết RTT 100ms có thể tai hại đến mức nào. Overhead của QUIC có thể không thực sự quan trọng, vì băng thông thực tế qua một kết nối TCP đơn lẻ hoặc một luồng QUIC có thể thấp hơn rất nhiều so với băng thông thô.
Daniel Stenberg, người tạo ra và duy trì Curl, đã viết một bài blog về HTTP/3. Ông nhấn mạnh mức sử dụng CPU cao của HTTP/3 và đề cập rằng CPU có thể trở thành yếu tố giới hạn thông lượng. Tôi tự hỏi điều này là do triển khai còn non nớt hay do chính cách QUIC được thiết kế.
Người ta nói rằng trên Internet nhanh, stack UDP+QUIC+HTTP/3 làm giảm tốc độ truyền dữ liệu tới 45,2% so với TCP+TLS+HTTP/2. Tôi vẫn chưa đọc hết bài báo, nhưng dưới 600 Mbit/s lại bị coi là "Internet chậm".
Họ nói QUIC không đủ nhanh trên Internet nhanh. Tôi đã đạt tốc độ 900mbps với quic+http3, nên tôi tự hỏi là do triển khai TLS kém hay do các triển khai ban đầu chưa hiệu quả. Mức sử dụng CPU trung bình khoảng 5% trên lõi gen 2 epyc.
Ở đây, "Internet nhanh" là 500Mbps, và họ nói là do quic phụ thuộc vào CPU. Tôi chưa kiểm tra xem hệ thống thử nghiệm có phải là hệ thống tiêu dùng cơ bản hay đây cũng là vấn đề trên desktop hiệu năng cao.
Tôi từng nghĩ QUIC được tối ưu cho độ trễ. Nó được tối ưu để tải nhiều gói nhỏ trên trang web và trong trò chơi điện tử. Khi chỉ đo thông lượng tổng thể thì nó có thể tỏ ra kém hơn. Tôi tự hỏi liệu ở cấp độ giao thức có thể phát hiện việc truyền tệp lớn hoặc streaming video băng thông cao để chuyển sang thứ gì đó ít ngốn CPU hơn không. Tôi cũng tự hỏi liệu QUIC có được tối ưu ở cấp phần cứng/HĐH kém hơn TCP hay không.
Tôi ước QUIC có chế độ không dùng TLS. Khi phát triển cục bộ, đôi lúc tôi chỉ muốn nhìn thấy dữ liệu đang được truyền, và điều này làm phát sinh ma sát không cần thiết.