HTTP/3 hosting: Đo QUIC và fallback HTTP/2

HTTP/3 hosting là cách triển khai website trên giao thức HTTP/3, sử dụng QUIC thay cho TCP. Cấu hình đúng không có nghĩa là tắt HTTP/2, mà là mở HTTP/3 qua UDP 443, duy trì HTTPS trên TCP 443 và quảng bá dịch vụ bằng Alt-Svc. Khi QUIC không dùng được do tường lửa, mạng doanh nghiệp hoặc thiết bị cũ, trình duyệt vẫn có thể truy cập bằng HTTP/2.

Trong bài này, tôi trình bày cách hiểu QUIC, cấu hình HTTP/3 với Nginx, thiết kế fallback an toàn và quy trình đo hiệu năng có thể lặp lại.

QUIC là gì và HTTP/3 khác HTTP/2 ra sao?

QUIC là gì? Đây là giao thức truyền tải chạy trên UDP, tích hợp TLS 1.3 và cơ chế đa luồng. HTTP/3 ánh xạ ngữ nghĩa HTTP lên QUIC, thay vì chạy trên TCP như HTTP/1.1 và HTTP/2 (theo ietf.org).

Tiêu chí	HTTP/2	HTTP/3
Giao thức truyền tải	TCP	QUIC trên UDP
Mã hóa	TLS thường được dùng với HTTPS	TLS 1.3 là thành phần bắt buộc của QUIC
Head-of-line blocking	Có thể xảy ra ở tầng TCP	Giảm ảnh hưởng giữa các stream
Di chuyển kết nối	Hạn chế khi đổi mạng	QUIC hỗ trợ connection migration
Cổng phổ biến	TCP 443	UDP 443
Fallback	Không cần fallback xuống HTTP/1.1 trong đa số trình duyệt hiện đại	Fallback về HTTP/2 qua TCP khi UDP thất bại

HTTP/3 thường có lợi hơn khi người dùng chuyển mạng, dùng di động hoặc gặp độ trễ và mất gói. Tuy nhiên, không nên mặc định rằng mọi website sẽ nhanh hơn rõ rệt. Nếu máy chủ đã có TTFB thấp, tài nguyên ít và người dùng chủ yếu ở mạng ổn định, chênh lệch có thể nhỏ. Hãy đo bằng cùng một vị trí mạng, cùng phiên bản nội dung và cùng trạng thái bộ nhớ đệm.

HTTP/3 cũng yêu cầu mở UDP. Vì vậy, firewall, load balancer, CDN hoặc nhà cung cấp hosting phải chuyển tiếp UDP 443; chỉ mở TCP 443 là chưa đủ.

Cấu hình HTTP/3 với Nginx và fallback HTTP/2

Nginx hỗ trợ module HTTP/3 từ nhánh mainline 1.25.0 trở đi, nhưng module ngx_http_v3_module cần được biên dịch hoặc sử dụng gói máy chủ có sẵn module phù hợp (theo nginx.org). Trước khi chỉnh cấu hình, hãy kiểm tra:

Nginx có module HTTP/3: nginx -V 2>&1 | grep http_v3.
Chứng chỉ TLS hợp lệ và tên miền trỏ đúng máy chủ.
TCP 443 và UDP 443 đều được phép trên firewall.
CDN hoặc reverse proxy phía trước có hỗ trợ HTTP/3 và chuyển tiếp đúng giao thức.

Nếu bạn đang chuẩn bị máy chủ Ubuntu, có thể xem thêm hướng dẫn cấu hình Ubuntu Server ban đầu để rà soát firewall, SSH và các thiết lập nền tảng.

Mẫu cấu hình Nginx cơ bản

server {
    listen 443 ssl;
    listen 443 quic reuseport;

    server_name example.com www.example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_protocols       TLSv1.3;

    add_header Alt-Svc 'h3=":443"; ma=86400' always;

    location / {
        root /var/www/example;
        index index.html index.php;
    }
}

Dòng listen 443 ssl giữ HTTPS trên TCP, cho phép HTTP/2 hoạt động. Dòng listen 443 quic reuseport mở QUIC trên UDP cùng số cổng. Nginx khuyến nghị dùng cùng cổng cho HTTP/3 và HTTPS để tương thích tốt hơn (theo nginx.org).

Nếu muốn bật HTTP/2 rõ ràng trên phiên bản Nginx phù hợp, có thể dùng:

listen 443 ssl http2;

Trên các bản Nginx mới, cách khai báo HTTP/2 có thể thay đổi theo phiên bản và cảnh báo cấu hình. Hãy chạy nginx -t trước khi reload. Không xóa listener TCP chỉ vì HTTP/3 đã hoạt động: đó là lỗi khiến người dùng ở mạng chặn UDP không thể truy cập.

Alt-Svc không phải là chuyển hướng

Alt-Svc thông báo rằng cùng tài nguyên có thể được truy cập bằng HTTP/3. Trình duyệt thường kết nối HTTPS qua TCP trước, đọc thông báo rồi thử QUIC ở các lần tải sau. Vì vậy, phản hồi đầu tiên chưa chắc đã dùng HTTP/3. Đặt always giúp header xuất hiện cả trong một số phản hồi lỗi, nhưng bạn vẫn cần cân nhắc chính sách cache và proxy.

Đo hiệu năng QUIC thay vì chỉ nhìn điểm Lighthouse

Muốn đánh giá HTTP/3 hosting, hãy so sánh HTTP/2 và HTTP/3 trong cùng điều kiện. Tối thiểu cần ghi nhận thời gian kết nối, TTFB, thời gian tải tài nguyên chính, tỷ lệ lỗi và khả năng hồi phục khi đổi mạng.

Kiểm tra giao thức bằng curl

# Chỉ thử HTTP/3, thất bại nếu QUIC không kết nối được
curl --http3-only -I https://example.com/

# Thử HTTP/3 và cho phép fallback về HTTP/2 hoặc HTTP/1.1
curl --http3 -I https://example.com/

# Ép HTTP/2 để tạo đường cơ sở
curl --http2 -I https://example.com/

--http3-only giúp xác nhận QUIC thật sự hoạt động; --http3 cho phép cơ chế fallback tương tự HTTPS eyeballing (theo curl.se). Lưu ý rằng bản curl phải được biên dịch với hỗ trợ HTTP/3.

Để đo nhiều lần, dùng tùy chọn thời gian:

curl --http3-only -sS -o /dev/null 
  -w 'HTTP=%{http_version} DNS=%{time_namelookup} connect=%{time_connect} start=%{time_starttransfer} total=%{time_total}n' 
  https://example.com/

Chạy khoảng 10–20 lần cho mỗi giao thức, bỏ qua các lần lỗi và ghi chú thời điểm, địa điểm, IPv4/IPv6, trạng thái CDN cache. Đừng so sánh một lần HTTP/3 lạnh với một lần HTTP/2 đã được cache.

Đọc log Nginx để xác nhận QUIC

log_format protocols '$remote_addr $request $status http=$server_protocol h3=$http3 quic=$quic';
access_log /var/log/nginx/protocols.log protocols;

Biến liên quan HTTP/3 có thể giúp phân biệt request dùng QUIC với request đi qua TCP. Nếu log không ghi nhận request HTTP/3 dù curl --http3-only thành công, hãy kiểm tra format log và quá trình reload.

Với kiểm tra trên trình duyệt, mở DevTools, vào Network, bật cột Protocol rồi tải lại trang. Giá trị thường thể hiện h3 hoặc h2. Đây là cách thực tế để kiểm tra HTTP/3 website, nhưng nên kết hợp curl và log máy chủ vì trình duyệt có cache Alt-Svc.

Fallback HTTP/2 đúng cách: kiểm tra, lỗi thường gặp và quyết định triển khai

Fallback tốt phải xảy ra tự nhiên ở tầng kết nối, không cần JavaScript hay redirect. Quy trình nên là: trình duyệt thử HTTP/3 qua UDP 443; nếu không nhận được phản hồi phù hợp, nó dùng HTTPS trên TCP 443 và thương lượng HTTP/2 qua ALPN. Người quản trị cần bảo đảm cả hai đường đều phục vụ cùng chứng chỉ, hostname, nội dung và chính sách bảo mật.

Danh sách kiểm tra trước khi bật production

Kiểm tra chứng chỉ bao phủ mọi hostname đang dùng.
Mở TCP 443 và UDP 443 trên máy chủ, cloud firewall và security group.
Xác nhận Nginx thực sự có module HTTP/3 bằng nginx -V.
Chạy nginx -t && systemctl reload nginx.
Dùng curl --http3-only từ ít nhất hai mạng khác nhau.
Dùng curl --http2 để xác nhận đường TCP vẫn hoạt động.
Kiểm tra DevTools và log để đối chiếu giao thức.
Theo dõi tỷ lệ lỗi 4xx, 5xx, timeout UDP và phản hồi từ người dùng di động.

Các lỗi phổ biến

Chỉ mở TCP 443: HTTP/2 chạy nhưng HTTP/3 luôn thất bại. Cách sửa là mở UDP 443 ở mọi lớp mạng.
Tắt listener TCP: người dùng sau mạng doanh nghiệp hoặc firewall nghiêm ngặt bị mất fallback. Hãy giữ HTTPS TCP.
Alt-Svc sai cổng hoặc hostname: trình duyệt thử QUIC ở nơi không tồn tại. Dùng h3=":443" nếu HTTP/3 cùng cổng.
Chứng chỉ không hợp lệ: QUIC yêu cầu TLS 1.3 và xác thực chứng chỉ như HTTPS thông thường. Gia hạn chứng chỉ trước khi thử nghiệm.
CDN không hỗ trợ HTTP/3 đến origin: người dùng có thể thấy h3 ở CDN nhưng kết nối CDN–origin vẫn là HTTP/2 hoặc HTTP/1.1. Đây không phải lỗi, nhưng cần hiểu đúng phạm vi đo.
Đánh giá bằng một lần tải: kết quả bị ảnh hưởng bởi cache, DNS và tuyến mạng. Hãy dùng nhiều mẫu và báo cáo trung vị hoặc p95.

Nếu website có lượng truy cập lớn hoặc phụ thuộc CDN, hãy kiểm tra thêm IPv6 vì lựa chọn đường mạng có thể làm thay đổi kết quả đo HTTP/3. Bài kiểm tra IPv6 hosting thực tế có thể dùng như danh sách rà soát bổ sung.

Kết luận: nên bật HTTP/3 khi nhà cung cấp hỗ trợ UDP ổn định, bạn kiểm soát được firewall/CDN và có quy trình đo. Cấu hình an toàn nhất là chạy song song HTTP/3 trên UDP 443 và HTTP/2 trên TCP 443. Đừng triển khai dựa trên khẩu hiệu “HTTP/3 luôn nhanh hơn”; hãy quyết định bằng dữ liệu TTFB, thời gian tải, tỷ lệ lỗi và trải nghiệm trên các mạng thực tế.

HTTP/3 hosting: Đo hiệu năng QUIC và cấu hình fallback HTTP/2 đúng cách