HTTP/3 (QUIC) trên Nginx: Loại bỏ Latency và Head-of-Line Blocking

Cuộc gọi lúc 2 giờ sáng: Khi “Nhanh” thôi là chưa đủ

Tiếng thông báo Slack phá tan sự tĩnh lặng lúc 2 giờ sáng. “Độ trễ tăng vọt ở Đông Nam Á. Người dùng di động lại gặp lỗi timeout.” Tôi uể oải ngồi vào bàn làm việc, ánh sáng màn hình làm mắt tôi cay xè. Dashboard Grafana trông vẫn hoàn hảo. Sử dụng CPU ở mức 12%, RAM ổn định ở 4GB và cơ sở dữ liệu vẫn phản hồi nhanh chóng trong vòng 30ms. Tuy nhiên, đối với những người dùng sử dụng kết nối 4G chập chờn ở Jakarta, Time to First Byte (TTFB) đang tăng vọt quá 1,8 giây.

Phần cứng không phải là vấn đề. Vấn đề nằm ở giao thức. Chúng tôi đang chạy HTTP/2 tiêu chuẩn qua TCP. Trên một kết nối cáp quang ổn định, nó hoạt động cực kỳ mạnh mẽ. Nhưng ngay khi một gói tin bị rơi trên một trạm phát sóng di động đang nghẽn, TCP quay trở lại logic từ năm 1974 của nó: nó dừng mọi thứ lại và chờ đợi. Đây chính là hiện tượng Head-of-Line (HoL) blocking. Lúc 2 giờ sáng, đó là thứ duy nhất ngăn cản tôi đi ngủ.

Nguyên nhân gốc rễ: Tại sao TCP thất bại với Web di động hiện đại

Để khắc phục tình trạng lag, tôi phải phân tích cách Nginx giao tiếp với thế giới. HTTP/2 là một bước tiến lớn vì nó giới thiệu cơ chế multiplexing, cho phép chúng ta gửi nhiều tệp qua một kết nối duy nhất. Điểm yếu là gì? Nó vẫn phụ thuộc vào TCP.

Hãy tưởng tượng bạn đang tải một tệp CSS 50KB, một gói JavaScript 200KB và một ảnh lớn (hero image). Nếu gói tin chứa một mảnh nhỏ của tệp CSS đó bị thất lạc trong quá trình truyền tải, TCP sẽ đóng băng toàn bộ đường truyền. Ngay cả khi các gói tin của JS và hình ảnh đã đến nơi hoàn hảo, trình duyệt cũng không thể chạm vào chúng. Chúng nằm chờ trong bộ đệm, đợi mảnh CSS bị thiếu được truyền lại.

Tiếp theo là “thuế bắt tay” (handshake tax). Một kết nối HTTPS tiêu chuẩn yêu cầu bắt tay ba bước (three-way handshake) của TCP, sau đó là quá trình thương lượng TLS. Đó là ba vòng khứ hồi (round-trips) trước khi máy chủ gửi đi một byte dữ liệu đầu tiên. Trên một kết nối có độ trễ cao với RTT 250ms, người dùng của bạn phải đợi gần một giây chỉ để “chào hỏi” máy chủ.

Giải pháp: HTTP/3 và giao thức QUIC

Tôi nhận ra chúng tôi phải loại bỏ TCP ở tầng vận chuyển. Đây là lúc HTTP/3 tỏa sáng. Không giống như các phiên bản cũ, HTTP/3 sử dụng QUIC (Quick UDP Internet Connections). Ban đầu được xây dựng bởi Google, nó chạy trên UDP để vượt qua các khiếm khuyết về kiến trúc của TCP.

QUIC giải quyết cuộc khủng hoảng như thế nào:

• Independent Streams: QUIC xử lý multiplexing ở tầng vận chuyển. Nếu “Stream A” mất một gói tin, “Stream B” vẫn tiếp tục di chuyển. Không còn tình trạng đình trệ toàn cục.
• 0-RTT Handshakes: QUIC hợp nhất việc kết nối và bắt tay mã hóa. Nếu khách hàng đã truy cập trước đó, họ có thể gửi dữ liệu ngay trong gói tin đầu tiên.
• Connection Migration: Khi người dùng chuyển từ Wi-Fi văn phòng sang mạng 5G, IP của họ sẽ thay đổi. TCP sẽ ngắt kết nối đó ngay lập tức. QUIC sử dụng một Connection ID duy nhất, giữ cho phiên làm việc luôn tồn tại mà không cần kết nối lại.

Triển khai: Đưa HTTP/3 lên Nginx

Việc thiết lập HTTP/3 từng là một cơn ác mộng với các bản vá thử nghiệm. May mắn thay, Nginx hiện đã hỗ trợ QUIC chính thức trong nhánh mainline (bắt đầu từ phiên bản 1.25.0). Tôi đã triển khai nó cho các node biên của mình và độ ổn định rất tuyệt vời.

Bước 1: Cài đặt Nginx Mainline

Các kho lưu trữ apt mặc định trên hầu hết các bản phân phối thường chứa các phiên bản cũ. Bạn cần các bản build mainline. Đối với người dùng Ubuntu, hãy lấy trực tiếp từ nguồn chính thức của Nginx:

sudo apt update && sudo apt install -y curl gnupg2 ca-certificates lsb-release ubuntu-keyring

# Nhập mã khóa ký của Nginx
curl https://nginx.org/keys/nginx_signing.key | gpg --dearmor | sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg >/dev/null

# Cấu hình repository mainline
echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] http://nginx.org/packages/mainline/ubuntu `lsb_release -cs` nginx" | sudo tee /etc/apt/sources.list.d/nginx.list

sudo apt update
sudo apt install nginx

Chạy nginx -v để đảm bảo bạn đang ở phiên bản 1.25.0 hoặc cao hơn.

Bước 2: Cấu hình Server Block

Kích hoạt HTTP/3 yêu cầu hai thay đổi cụ thể. Bạn phải lắng nghe trên cổng UDP và phát một header Alt-Svc để trình duyệt biết rằng QUIC có sẵn. Chỉnh sửa cấu hình trang web của bạn (thường là /etc/nginx/conf.d/default.conf):

server {
    # Lắng nghe trên cổng 443 cho TCP (HTTP/2) và UDP (HTTP/3)
    listen 443 quic reuseport;
    listen 443 ssl;
    http2 on;

    server_name example.com;

    # QUIC yêu cầu bắt buộc TLS 1.3
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;

    # Thông báo hỗ trợ HTTP/3 cho trình duyệt
    add_header Alt-Svc 'h3=":443"; ma=86400';

    # Tùy chọn: Theo dõi việc sử dụng QUIC trong header
    add_header X-Protocol $server_protocol;

    location / {
        root /usr/share/nginx/html;
        index index.html;
    }
}

Mẹo nhỏ: Tham số reuseport rất quan trọng. Nó cho phép kernel phân phối các gói tin UDP đến nhiều worker process của Nginx, ngăn chặn tình trạng thắt cổ chai trên một nhân CPU duy nhất.

Bước 3: Cấu hình Firewall

Tôi đã mất hai mươi phút để debug một thiết lập “thất bại” trước khi nhận ra firewall chính là thủ phạm. HTTPS tiêu chuẩn sử dụng TCP. HTTP/3 sử dụng UDP. Nếu bạn không mở cổng UDP 443, trình duyệt sẽ âm thầm quay lại sử dụng HTTP/2 và bạn sẽ bỏ lỡ các lợi ích về hiệu năng.

# Cho người dùng UFW
sudo ufw allow 443/tcp
sudo ufw allow 443/udp

# Cho người dùng AWS/GCP: Đảm bảo Security Group cho phép UDP 443 từ 0.0.0.0/0

Kiểm tra kết nối

Các trình duyệt thường không hiển thị rõ ràng về HTTP/3. Để xác minh nó đang hoạt động, hãy mở Chrome DevTools và vào tab Network. Nhấp chuột phải vào hàng tiêu đề và bật cột Protocol. Tải lại trang hai lần. Lần truy cập đầu tiên để phát hiện header Alt-Svc; lần thứ hai sẽ hiển thị h3 trong cột giao thức.

Bạn cũng có thể sử dụng terminal. Chạy curl --http3 -I https://example.com để xem quá trình bắt tay giao thức diễn ra.

Kết luận: Có xứng đáng không?

Sau khi di chuyển, các chỉ số của chúng tôi đã kể một câu chuyện rõ ràng. Đối với người dùng ở các vùng có độ trễ cao, thời gian kết nối ban đầu đã giảm trung bình 320ms. Quan trọng hơn, cảm giác “giật lag” của ứng dụng web trên mạng di động đã biến mất. Ngay cả với tỷ lệ mất gói tin 3%, trang web vẫn phản hồi nhanh chóng.

Dưới đây là so sánh các giao thức trong thế giới thực:

Nâng cấp lên HTTP/3 không chỉ là chạy theo công nghệ mới nhất. Đó là về khả năng phục hồi. Trong một thế giới mà lưu lượng truy cập di động chiếm đa số, khả năng tồn tại trên một kết nối không ổn định là một lợi thế khổng lồ. Nếu người dùng của bạn không phải tất cả đều đang sử dụng cáp quang gigabit, bạn cần phải thực hiện thay đổi này ngay.