
QUIC là gì? Giao thức truyền tải thế hệ mới bỏ hẳn TCP
QUIC là gì? QUIC là giao thức truyền tải (transport protocol) chạy trên lớp UDP, do Google khởi xướng và hiện đã được chuẩn hoá thành RFC 9000. Điểm khác biệt cốt lõi so với TCP là QUIC gộp luôn bảo mật vào bên trong giao thức, dùng ngay TLS 1.3, nên chỉ cần một vòng bắt tay (round-trip) là dữ liệu đã được mã hoá và truyền đi. Bài viết này bóc tách cấu trúc gói tin, cơ chế khôi phục kết nối và lý do HTTP/3 chọn QUIC làm nền tảng.

Vì sao cần một giao thức mới?
Rust pipe của TCP được thiết kế từ những năm 1980, khi mạng LAN với tổn thất rất thấp là chuẩn. Giả định cũ là: gói tin đến đúng thứ tự, đến đủ, và băng thông ổn định. Ba giả định đó đều không còn đúng trên Internet di động ngày nay, và hậu quả là giao thức TCP vấp phải những vấn đề cấu trúc mà không sửa được nếu giữ nguyên thiết kế cũ.
Head-of-line blocking ở tầng truyền tải
TCP bảo đảm các byte đến đúng thứ tự bằng cách đánh số tuần tự. Nếu một đoạn dữ liệu bị mất ở giữa đường, mọi đoạn phía sau nó phải nằm chờ, kể cả khi đã đến nơi. Trong HTTP/2 trên TCP, các request chạy song song ở tầng ứng dụng nhưng lại chia sẻ một byte stream duy nhất, nên chỉ cần một gói tin mất là toàn bộ request đang bay bị chặn cùng lúc.
QUIC chữa bằng cách chia dữ liệu thành nhiều stream độc lập. Mỗi stream có không gian số thứ tự riêng, nên mất gói tin ở stream A không ảnh hưởng stream B. Đây là cải tiến lớn nhất của QUIC so với TCP và là lý do nó phù hợp với mô hình request/response không đồng bộ.
Vòng bắt tay nhiều chặng và không khôi phục được
Kết nối TCP cổ điển cần SYN, SYN-ACK, ACK rồi mới tới bắt tay TLS 1.2 nhiều chặng. Tổng cộng có thể tới 3 chuyến đi-về trước khi byte dữ liệu đầu tiên chạm tới server. Tệ hơn, nếu đường truyền đổi (chuyển từ Wi-Fi sang 4G), địa chỉ IP thay đổi thì kết nối TCP chết hẳn và phải làm lại từ đầu.

QUIC hoạt động như thế nào?
Theo RFC 9000, QUIC cung cấp cho ứng dụng ba năng lực chính: stream có điều khiển luồng, thiết lập kết nối độ trễ thấp và di trú đường mạng (network path migration).
Khôi phục kết nối tức thì bằng session ticket
QUIC lưu trạng thái phiên ở hai bên. Khi quay lại, client gửi kèm session ticket và transport parameters đã lưu, cho phép bỏ qua gần như toàn bộ quy trình xác thực. Kết nối mới lên chỉ cần 1-RTT, và nếu client đã có ticket từ lần trước thì có thể gửi dữ liệu ngay trong gói đầu tiên qua chế độ 0-RTT.
| Cơ chế | TCP + TLS 1.2 | QUIC + TLS 1.3 |
|---|---|---|
| Bắt tay lần đầu | 3-4 RTT | 1 RTT |
| Bắt tay khi quay lại | 3-4 RTT | 0-RTT hoặc 1-RTT |
| Bảo mật | Tách lớp, giao thức có thể rơi xuống HTTP rõng | Bắt buộc tích hợp trong giao thức |
| Di trú đường mạng | Không hỗ trợ | Hỗ trợ qua Connection ID |
| Tách head-of-line | Không | Có, theo từng stream |
Connection ID thay cho địa chỉ IP
Thay vì định danh kết nối bằng cặp IP và cổng, QUIC dùng một Connection ID ngẫu nhiên do server cấp. Nhờ vậy khi bạn đổi mạng và IP thay đổi, client chỉ cần thông báo Connection ID mới cho server, cuộc hội thoại tiếp tục mà không cần bắt tay lại. Server cũng có thể đổi địa chỉ thật (migrate) sang một cụm máy chủ khác mà không làm gián đoạn phiên.
Bảo vệ tiêu đề gói tin
RFC 9001 mô tả cách bảo vệ toàn bộ gói tin, kể cả phần tiêu đề, bằng header protection với khóa tách biệt. Mỗi gói tin dùng nonce thay đổi theo số thứ tự, chống việc tái sử dụng khóa. Bên cạnh đó RFC quy định cơ chế Key Update để hai bên đồng bộ khóa mới định kỳ mà không cần bắt tay lại.
0-RTT và cái giá của việc tấn công replay
0-RTT là cơ chế nhanh nhất nhưng cũng là điểm yếu được thảo luận nhiều nhất. Vì client gửi dữ liệu trước khi handshake hoàn tất, kẻ tấn công có thể chặn và phát lại gói tin đó. Do đó RFC 9001 yêu cầu dữ liệu 0-RTT phải idempotent, hoặc server phải có cơ chế chống replay riêng.
Trong thực tế, phần lớn triển khai chỉ dùng 0-RTT cho việc tải tài nguyên tĩnh có thể cache lại, còn thao tác ghi vẫn chờ bắt tay hoàn tất. Nếu bạn tự xây dựng hệ thống, hãy coi 0-RTT là tối ưu hoá cho nội dung tĩnh và tuyệt đối không gắn nó vào giao dịch tài chính.
HTTP/3 và vị trí thực tế của QUIC
QUIC chỉ là tầng truyền tải. Bản thân nó không định nghĩa request hay response. HTTP/3 là bản ánh xạ ngữ nghĩa HTTP cũ lên QUIC, thường dùng QPACK để nén bảng tra cứu header để tránh round-trip thừa. HTTP/3 được định nghĩa tại quicwg.org và phần lớn trình duyệt lớn đã bật mặc định.
Điểm cần lưu ý về mặt vận hành: vì QUIC chạy trên UDP, một số mạng doanh nghiệp và tường lửa cũ vẫn chặn UDP thành phố. Khi đó client sẽ phải dùng đường vòng qua TCP hoặc chậm lại với HTTP/2, và chẩn đoán hiện tượng “web nhanh lúc nào cũng chậm” trên một số mạng là do nguyên nhân này. Bảng điều khiển trạng thái giao thức của trình duyệt cho biết phiên hiện tại đang chạy HTTP/3 hay không.
Tóm lại
QUIC thay thế TCP bằng cách mang bảo mật vào trong giao thức, dùng stream độc lập để loại bỏ head-of-line blocking ở tầng truyền tải, và thêm Connection ID để hỗ trợ di trú mạng cùng khôi phục nhanh. Đổi lại, độ phức tạp dồn vào phía triển khai, và người dùng cuối phải đối mặt với các đường tắt UDP mới đây. Với phần lớn người dùng phổ thông, lợi ích đến từ HTTP/3 chứ không cần tự viết client QUIC.
Tài liệu chính thức và đặc tả toàn diện của nhóm làm việc QUIC nằm tại quicwg.org, nơi công bố các bản RFC cùng bản Internet-Draft tiến hóa.
