QUIC cho nhân Linux

(lwn.net)

12 điểm bởi GN⁺ 2025-08-02 | Chưa có bình luận nào. | Chia sẻ qua WhatsApp

Bản vá đầu tiên để tích hợp chính thức giao thức QUIC vào nhân Linux đã được gửi lên
Mục tiêu là khắc phục các hạn chế của TCP hiện tại như độ trễ, head-of-line blocking, và sự xơ cứng giao thức do các thiết bị trung gian gây ra
QUIC dựa trên UDP, hỗ trợ đa luồng và mã hóa end-to-end; nếu được đưa vào nhân, khả năng tận dụng trên nhiều nền tảng và phần cứng sẽ cao hơn
Hiệu năng của bản triển khai ban đầu trong nhân được đo là thấp hơn TCP hiện có và kernel TLS, nhưng có thể kỳ vọng cải thiện nhờ hardware offloading và tối ưu hóa trong tương lai
Hiện đang có nhiều thảo luận sôi nổi về hỗ trợ trong Samba, SMB/NFS dựa trên nhân, curl, v.v., nhưng có vẻ sẽ còn mất thời gian trước khi được hợp nhất vào mainline

Bối cảnh ra đời của giao thức QUIC và các giới hạn của TCP

QUIC được tạo ra nhằm giải quyết nhiều vấn đề vốn có của TCP trên Internet hiện nay
Độ trễ do bắt tay 3 bước trong quá trình thiết lập kết nối của TCP, việc hỗ trợ đa luồng còn hạn chế, cùng hiện tượng head-of-line blocking khi mất gói đều làm suy giảm trải nghiệm web
Metadata của TCP được truyền đi mà không mã hóa, tạo ra rủi ro rò rỉ thông tin; đồng thời các middlebox (thiết bị trung gian) trên Internet lọc lưu lượng dựa trên thông tin kết nối, từ đó dẫn đến sự xơ cứng giao thức (ossification)
Ngay cả các nỗ lực cải tiến TCP (ví dụ: Multipath TCP) cũng rơi vào tình trạng không thể hoạt động bình thường nếu không ngụy trang thành TCP hiện có

QUIC hoạt động trên UDP và có thể thiết lập kết nối nhanh mà không cần quy trình bắt tay 3 bước riêng như TCP
Thiết kế truyền tải đa luồng được đưa vào để việc mất gói không ảnh hưởng đến toàn bộ luồng dữ liệu
Dữ liệu truyền tải liên quan đến QUIC luôn được mã hóa đầu-cuối (dựa trên TLS), nên thiết bị trung gian không thể truy cập thông điệp bên trong
Nếu môi trường mạng cho phép các gói UDP đi qua, QUIC cũng có thể hoạt động bình thường

Bản vá được gửi lên giới thiệu một kiểu giao thức mới là IPPROTO_QUIC, cho phép tận dụng lời gọi hệ thống socket() hiện có
Tương tự TCP, có thể dùng các lời gọi như bind(), connect(), listen(), accept(), nhưng cách xử lý về sau có những điểm khác biệt
Quản lý phiên TLS và quá trình xác thực/mã hóa được xử lý ở không gian người dùng; sau khi kết nối, bắt tay TLS phải hoàn tất ở mỗi bên thì mới có thể gửi nhận dữ liệu
Sau kết nối ban đầu, có thể cache kết quả thương lượng TLS để tăng tốc đáng kể khi hai hệ thống kết nối lại

Bản triển khai QUIC trong nhân được gửi lên hiện vẫn yếu hơn kernel TLS và TCP hiện có về mặt hiệu năng
- Thông lượng thấp hơn tới dưới 3 lần so với TLS trong nhân; ngay cả khi tắt mã hóa, thông lượng vẫn có thể thấp hơn TCP tới 4 lần
Các nguyên nhân được chỉ ra gồm chưa hỗ trợ segmentation offloading, phát sinh thêm sao chép dữ liệu trên đường truyền gửi, và quá trình mã hóa header
Trong tương lai, nếu được bổ sung hỗ trợ hardware offloading và tối ưu hóa bản triển khai trong nhân, hiệu năng được kỳ vọng sẽ cải thiện

Nhiều dự án như máy chủ/khách Samba, hệ thống tệp SMB và NFS trong nhân, curl, v.v. đang thảo luận tích cực về hỗ trợ QUIC trong nhân
Bản vá có quy mô khoảng 9.000 dòng và hiện mới chỉ bao gồm mã hỗ trợ mức thấp. Toàn bộ triển khai sẽ được bổ sung trong các bản vá tiếp theo
Việc review mã và thảo luận hợp nhất mới chỉ ở giai đoạn khởi đầu, nên có vẻ sẽ còn cần thêm thời gian trước khi đi vào sử dụng thực tế
- Xét tiền lệ gần đây khi giao thức Homa cần 11 lần gửi trong suốt 9 tháng mới được hợp nhất vào nhân, QUIC cũng được dự đoán chỉ có thể vào mainline sau năm 2026