Bạn đang xem YouTube trên điện thoại, bước ra khỏi nhà là máy tự chuyển từ Wi-Fi sang 4G. Video vẫn chạy, không khựng, không xoay vòng. Vài năm trước, đoạn chuyển mạng đó gần như chắc chắn làm video đứng hình một nhịp. Thứ đứng sau sự khác biệt này là HTTP/3, phiên bản mới nhất của giao thức web, và nó có một lựa chọn nghe rất ngược đời: bỏ TCP, thứ đã gánh Internet hơn bốn mươi năm, để chạy trên UDP, giao thức vốn bị coi là "không đáng tin".
Bài này giải thích TCP vướng ở đâu, vì sao không ai sửa được nó, QUIC đã xây lại mọi thứ trên nền UDP ra sao, và cái giá của lựa chọn đó.
TCP và UDP khác nhau thế nào?
Mọi dữ liệu trên Internet đều bị cắt thành những gói tin (packet) nhỏ rồi gửi đi riêng lẻ. Trên đường đi, gói có thể bị mất, tới trễ, hoặc tới sai thứ tự. Tầng giao vận (transport layer) quyết định xử lý mấy chuyện đó thế nào, và hai lựa chọn phổ biến nhất là TCP và UDP.
TCP (Transmission Control Protocol) giống như gửi thư bảo đảm:
- Đánh số thứ tự từng byte dữ liệu, bên nhận ráp lại đúng thứ tự.
- Xác nhận đã nhận (ACK): bên nhận liên tục báo "tôi đã nhận tới đây".
- Gửi lại gói bị mất, và tự giảm tốc khi mạng nghẽn.
UDP (User Datagram Protocol) thì như ném tờ rơi qua cửa sổ: gửi đi là xong. Không đánh số, không xác nhận, không gửi lại. Phần đầu gói UDP chỉ có 8 byte gồm cổng nguồn, cổng đích, độ dài và mã kiểm tra lỗi. Nhanh và nhẹ, nhưng mất gói nào thì ứng dụng tự lo.
| TCP | UDP | |
|---|---|---|
| Thiết lập kết nối | Có, bắt tay trước khi gửi | Không, gửi ngay |
| Đảm bảo thứ tự | Có | Không |
| Gửi lại gói mất | Có | Không |
| Phần đầu gói | Tối thiểu 20 byte | 8 byte |
| Dùng nhiều cho | Web, email, tải file | DNS, game, gọi video |
Nghe qua thì TCP rõ ràng "xịn" hơn cho web. Vậy vấn đề nằm ở đâu?
Cái giá của những lần "chào hỏi"
Trước khi gửi byte dữ liệu đầu tiên, TCP phải bắt tay ba bước (three-way handshake): máy bạn gửi SYN, máy chủ trả SYN-ACK, máy bạn đáp ACK. Mất trọn một vòng đi về (RTT, round-trip time).
Nhưng web ngày nay đều chạy HTTPS, nên sau đó còn phải bắt tay TLS để thống nhất khoá mã hoá. Với TLS 1.2 là thêm hai vòng, TLS 1.3 rút còn một vòng.
Một vòng đi về từ Việt Nam sang máy chủ ở Mỹ mất khoảng 200 mili giây, vì tín hiệu phải băng qua cáp quang dưới biển Thái Bình Dương rồi quay về. Đem nhân lên:
| Cách kết nối | Số vòng trước khi tải | Thời gian (RTT 200 ms) |
|---|---|---|
| TCP + TLS 1.2 | 3 | khoảng 600 ms |
| TCP + TLS 1.3 | 2 | khoảng 400 ms |
| QUIC (lần đầu) | 1 | khoảng 200 ms |
| QUIC (trang đã ghé, 0-RTT) | 0 | gửi dữ liệu ngay |
Gần sáu trăm mili giây chỉ để chào hỏi, chưa tải được chút nội dung nào. Mạng nhanh tới đâu cũng không cứu được, vì giới hạn ở đây là tốc độ ánh sáng và số lần đi về, không phải băng thông.
Gói cáp 1 Gbps giúp tải file lớn nhanh hơn, nhưng không làm một vòng đi về ngắn lại. Với trang web gồm nhiều file nhỏ, độ trễ mới là thứ quyết định cảm giác "nhanh hay chậm".
HTTP/2 và hiện tượng nghẽn đầu hàng
HTTP/1.1 tải mỗi file trên một kết nối, nên trình duyệt phải mở nhiều kết nối TCP cùng lúc, mỗi cái lại tốn công bắt tay. HTTP/2 (chuẩn hoá năm 2015) gom tất cả ảnh, CSS, JavaScript chạy song song trên một kết nối TCP duy nhất, gọi là ghép kênh (multiplexing). Rất hợp lý, cho đến khi mạng bắt đầu rớt gói.
Vấn đề là TCP không hề biết bên trong có nhiều file. Với TCP, đó chỉ là một dòng byte liền mạch, và nó bắt buộc giao đúng thứ tự. Chỉ cần một gói của tấm ảnh bị mất, mọi byte phía sau, kể cả của file CSS hay JavaScript đã tới nơi, đều phải nằm chờ trong bộ đệm cho đến khi gói kia được gửi lại.
Hiện tượng này gọi là head-of-line blocking (nghẽn đầu hàng). Hãy hình dung một làn đường duy nhất: một chiếc xe chết máy ở đầu hàng thì cả dòng phía sau đứng im, dù xe nào cũng có đường riêng để đi.
Trên mạng cáp ổn định, chuyện này ít xảy ra. Nhưng trên 4G khi di chuyển hay Wi-Fi công cộng đông người, tỉ lệ mất gói cao hơn hẳn, và HTTP/2 có thể chạy chậm hơn cả HTTP/1.1 nhiều kết nối.
Sao không sửa luôn TCP cho xong?
Câu hỏi hợp lý: nếu TCP có vấn đề, sao không nâng cấp nó? Câu trả lời nằm ở chỗ TCP được cài ở đâu.
- Trong nhân hệ điều hành: TCP là một phần của kernel Windows, Linux, Android, iOS. Muốn đổi cách TCP hoạt động, phải chờ hệ điều hành cập nhật, rồi chờ người dùng cài bản cập nhật đó. Hàng tỉ thiết bị cũ không bao giờ được cập nhật nữa.
- Trong thiết bị trung gian: router, tường lửa, thiết bị NAT, bộ cân bằng tải trên đường đi đều "đọc" phần đầu gói TCP và có giả định riêng về nó trông ra sao. Gặp gói TCP có tuỳ chọn lạ, nhiều thiết bị sẽ xoá tuỳ chọn đó hoặc chặn luôn.
Giới kỹ sư mạng gọi tình trạng này là ossification (hoá xương): giao thức cứng lại vì cả hệ sinh thái đã quen với hình dạng cũ. Ví dụ điển hình là TCP Fast Open, một cải tiến cho phép gửi dữ liệu ngay trong gói bắt tay. Nó được chuẩn hoá thành RFC 7413 từ năm 2014, nhưng việc triển khai thực tế gặp nhiều trở ngại vì thiết bị trung gian xử lý sai những gói lạ này.
Muốn đổi TCP, phải cập nhật cả thế giới. Và thế giới thì không chịu cập nhật.
QUIC: xây lại TCP ở tầng trên, dùng UDP làm lớp vỏ
UDP thì khác. Nó đơn giản tới mức gần như không có gì để thiết bị trung gian can thiệp, và vì DNS hay gọi video đều dùng UDP, phần lớn mạng đều cho nó đi qua.
Google tận dụng đúng điểm đó. Từ khoảng năm 2012, họ phát triển QUIC: lấy UDP làm lớp vỏ ngoài, rồi tự xây toàn bộ tính năng tin cậy (đánh số, xác nhận, gửi lại, kiểm soát nghẽn) ở tầng ứng dụng, ngay trong trình duyệt và máy chủ. Sau nhiều năm thử nghiệm trên Chrome và các dịch vụ của Google, IETF chuẩn hoá QUIC thành RFC 9000 vào tháng 5/2021, và HTTP chạy trên QUIC trở thành HTTP/3 với RFC 9114 vào tháng 6/2022.
Nói cách khác, QUIC không phải "UDP không tin cậy". Nó là một giao thức tin cậy hoàn chỉnh, chỉ mượn UDP làm phong bì để lọt qua mạng. Ba thay đổi lớn nhất:
Mỗi file một luồng riêng
QUIC biết bên trong kết nối có nhiều luồng (stream) độc lập. Gói của tấm ảnh bị mất thì chỉ luồng ảnh chờ gửi lại, còn CSS và JavaScript vẫn đi tiếp. Quay lại ví dụ con đường: thay vì một làn duy nhất, giờ mỗi xe có làn riêng, xe chết máy chỉ chặn làn của nó.
Gộp bắt tay và mã hoá làm một
QUIC tích hợp sẵn TLS 1.3 (RFC 9001). Thông tin kết nối và khoá mã hoá được trao đổi cùng lúc, nên chỉ mất một vòng đi về là bắt đầu tải. Với trang đã từng ghé, trình duyệt giữ lại thông tin phiên cũ và có thể gửi dữ liệu ngay trong gói đầu tiên, gọi là 0-RTT.
Dữ liệu gửi ở chế độ 0-RTT có thể bị kẻ xấu chặn lại rồi phát lại (replay attack). Vì thế máy chủ thường chỉ chấp nhận 0-RTT cho các yêu cầu an toàn khi lặp lại, như tải trang (GET), không dùng cho thanh toán hay gửi form.
Mã hoá cả phần đầu gói
TCP để lộ số thứ tự, thông tin xác nhận cho mọi thiết bị trên đường đọc. QUIC mã hoá gần như toàn bộ, chỉ để lộ vài trường tối thiểu để định tuyến. Thiết bị trung gian không đọc được thì cũng không "tối ưu" sai được, và đây chính là cách QUIC tự bảo vệ mình khỏi bị hoá xương như TCP.
Đổi mạng mà không đứt kết nối
Một kết nối TCP được nhận diện bằng bốn thông số: IP nguồn, cổng nguồn, IP đích, cổng đích. Bạn đi từ Wi-Fi sang 4G, IP của điện thoại đổi, kết nối cũ coi như chết. Ứng dụng phải bắt tay lại từ đầu, video khựng, tải file đứt giữa chừng.
QUIC gắn kết nối với một mã kết nối (Connection ID) do hai bên tự đặt, không phụ thuộc địa chỉ IP. Khi IP đổi, máy chủ vẫn nhận ra gói tin đến từ kết nối cũ và chạy tiếp. Tính năng này gọi là connection migration (di chuyển kết nối). Để tránh bị theo dõi khi đổi mạng, QUIC còn cho phép đổi sang Connection ID mới, nên người ngoài khó ghép hai đoạn kết nối lại với nhau.
Thêm một lợi ích ít ai để ý: vì QUIC chạy trong ứng dụng chứ không trong nhân hệ điều hành, Chrome hay Firefox có thể cập nhật thuật toán của nó theo nhịp phát hành trình duyệt, nhanh hơn rất nhiều so với chờ cả hệ điều hành cập nhật TCP.
HTTP/3 ngày nay: ai dùng, và cái giá phải trả
Theo số liệu của W3Techs, tỉ lệ website hỗ trợ HTTP/3 đã lên khoảng 37–40% trong năm 2026, tức hơn một phần ba web. Google, YouTube, Facebook và các mạng CDN lớn như Cloudflare đều đã bật. Mọi trình duyệt phổ biến (Chrome, Edge, Firefox, Safari) đều hỗ trợ.
Nhưng HTTP/3 không phải miễn phí:
- Tốn CPU hơn: TCP được tối ưu suốt mấy chục năm, nhiều card mạng còn xử lý một phần TCP bằng phần cứng. QUIC chạy ở tầng ứng dụng, phải tự mã hoá từng gói và đi qua đường xử lý UDP vốn ít được tối ưu, nên máy chủ tốn tài nguyên hơn cho cùng lưu lượng.
- Một số mạng chặn UDP: nhiều mạng công ty và trường học chặn UDP cổng 443 vì khó giám sát. Khi đó trình duyệt tự động quay về HTTP/2 qua TCP, người dùng không thấy lỗi, chỉ không được hưởng lợi.
- Khó gỡ lỗi hơn: vì phần đầu gói bị mã hoá, quản trị mạng không còn "nhìn" vào lưu lượng dễ như với TCP.
Trình duyệt biết một trang có HTTP/3 nhờ máy chủ trả về header Alt-Svc (hoặc bản ghi DNS loại HTTPS). Lần đầu ghé trang, trình duyệt vẫn dùng TCP, thấy lời mời này thì từ các yêu cầu sau mới chuyển sang QUIC.
Trong Chrome, mở DevTools (F12) > tab Network, bấm chuột phải vào hàng tiêu đề cột và bật cột Protocol. Tải lại trang, các yêu cầu ghi h3 là đang chạy HTTP/3, h2 là HTTP/2.
Nếu bạn dùng curl được biên dịch có hỗ trợ HTTP/3, có thể thử từ terminal:
# Xem máy chủ có quảng bá HTTP/3 qua header Alt-Svc không
curl -sI https://www.google.com | grep -i alt-svc
# Ép dùng HTTP/3 (cần bản curl hỗ trợ)
curl -sI --http3 https://www.google.com
Dòng alt-svc: h3=":443" nghĩa là máy chủ mời trình duyệt chuyển sang HTTP/3 trên cổng 443 UDP.
Tóm tắt nhanh
- TCP tin cậy nhưng mất 2–3 vòng đi về để bắt tay và mã hoá, cộng thêm nghẽn đầu hàng khi một gói bị mất.
- Không sửa được TCP vì nó nằm trong nhân hệ điều hành và bị hàng tỉ thiết bị trung gian "đóng khuôn".
- QUIC dùng UDP làm lớp vỏ, tự xây lại tính năng tin cậy ở tầng trên: luồng độc lập, bắt tay 1 vòng (hoặc 0), mã hoá cả phần đầu gói, giữ kết nối khi đổi mạng.
- HTTP/3 là HTTP chạy trên QUIC, đã có mặt trên hơn một phần ba website, đổi lại tốn CPU hơn và có thể bị chặn ở một số mạng.
HTTP/3 chọn UDP không phải vì UDP tốt hơn TCP, mà vì UDP trống trơn, đủ chỗ để xây lại mọi thứ đúng cách.
Câu hỏi thường gặp
HTTP/3 có làm mạng nhà tôi nhanh hơn không?
Không làm tăng băng thông. Lợi ích rõ nhất là trang mở nhanh hơn khi độ trễ cao (máy chủ ở xa) hoặc mạng hay rớt gói (4G, Wi-Fi công cộng). Trên cáp quang ổn định gần máy chủ, khác biệt thường khó nhận ra.
UDP không tin cậy thì dữ liệu HTTP/3 có bị mất không?
Không. QUIC tự đánh số, xác nhận và gửi lại gói mất y như TCP, chỉ là làm ở tầng ứng dụng thay vì trong hệ điều hành. UDP chỉ đóng vai phong bì chở gói tin đi.
Có cần bật gì để dùng HTTP/3 không?
Phía người dùng thì không: Chrome, Edge, Firefox, Safari đều bật sẵn. Phía người làm web, nếu dùng CDN như Cloudflare thường chỉ cần bật một tuỳ chọn; tự chạy máy chủ thì cần Nginx, Caddy hoặc LiteSpeed bản có hỗ trợ QUIC và mở cổng UDP 443 trên tường lửa.
HTTP/3 có thay thế hoàn toàn TCP không?
Chưa và có lẽ không sớm. Trình duyệt luôn giữ đường lui về HTTP/2 qua TCP khi UDP bị chặn, và rất nhiều dịch vụ khác (email, SSH, cơ sở dữ liệu) vẫn chạy trên TCP.
