HTTP/2 & HTTP/3

HTTP/2 & HTTP/3 là gì?

HTTP/2 và HTTP/3 là hai phiên bản mới nhất của giao thức truyền tải siêu văn bản (HTTP), được thiết kế để thay thế HTTP/1.1 — phiên bản đã hoạt động hơn 25 năm. Cả hai đều tập trung vào việc giảm độ trễ, tăng hiệu quả truyền tải và cải thiện trải nghiệm người dùng trên web.

HTTP/2 ra mắt chính thức năm 2015 (RFC 7540), hoạt động trên nền tảng TCP và giới thiệu các tính năng như multiplexing, header compression (HPACK), server push (đã bị loại bỏ trong thực tế do thiếu hỗ trợ trình duyệt), và ưu tiên yêu cầu (request prioritization).

HTTP/3 ra mắt năm 2022 (RFC 9114), là bước tiến lớn hơn: nó không còn dùng TCP mà chuyển sang giao thức vận chuyển mới tên là QUIC (Quick UDP Internet Connections), do Google phát triển và được IETF chuẩn hóa. QUIC tích hợp mã hóa (TLS 1.3 bắt buộc), giảm số lần bắt tay (handshake), khắc phục hiện tượng chặn đầu cuối (head-of-line blocking) ở cả tầng vận chuyển và tầng ứng dụng.

Tại sao quan trọng trong SEO?

Google xác nhận từ năm 2010 rằng tốc độ trang là yếu tố xếp hạng — và từ Core Web Vitals (2021), các chỉ số như Largest Contentful Paint (LCP) và Time to First Byte (TTFB) càng trở nên then chốt. HTTP/2 và HTTP/3 ảnh hưởng trực tiếp đến những chỉ số này:

• Multiplexing: Cho phép gửi nhiều yêu cầu và phản hồi đồng thời qua một kết nối duy nhất → giảm số lần mở kết nối → cải thiện TTFB và LCP.
• Header nén (HPACK): Giảm kích thước header tới 80% so với HTTP/1.1 → tiết kiệm băng thông, đặc biệt hữu ích với trang có nhiều tài nguyên nhỏ (CSS, JS, ảnh).
• QUIC trong HTTP/3: Loại bỏ hiện tượng head-of-line blocking ở tầng TCP → khi một gói tin bị mất, chỉ gói đó cần gửi lại, không làm chậm toàn bộ luồng → tăng độ ổn định trên mạng di động và mạng kém.
• TLS bắt buộc: Cả HTTP/2 (khuyến khích mạnh) và HTTP/3 (bắt buộc) yêu cầu mã hóa. Điều này giúp trang đạt điểm cao hơn trong các kiểm tra bảo mật (ví dụ: Lighthouse, PageSpeed Insights) và tránh cảnh báo “Không an toàn” trên Chrome.

Lưu ý: Không phải lúc nào nâng cấp cũng cải thiện thứ hạng trực tiếp — nhưng nếu nâng cấp giúp trang tải nhanh hơn trên thiết bị di động, giảm tỷ lệ thoát và tăng thời gian tương tác, thì đây là tín hiệu gián tiếp mạnh mẽ với thuật toán Google.

Cách hoạt động

HTTP/1.1 truyền từng yêu cầu – phản hồi tuần tự hoặc song song qua nhiều kết nối (thường tối đa 6 kết nối mỗi tên miền), gây lãng phí tài nguyên và độ trễ cao. HTTP/2 giải quyết bằng cách:

• Dùng một kết nối TCP duy nhất, chia thành nhiều luồng (streams) độc lập.
• Mỗi luồng mang một yêu cầu/phản hồi, có thể được ưu tiên (ví dụ: HTML > CSS > JS > ảnh nền).
• Header được nén bằng bảng trạng thái chung giữa client và server (HPACK), không gửi trùng lặp.

HTTP/3 đi xa hơn: thay vì dựa vào TCP (có cơ chế kiểm soát tắc nghẽn và phục hồi mất gói dựa trên ACK), nó chạy trên UDP và tích hợp QUIC — một giao thức vận chuyển đa luồng, có khả năng:

• Mở kết nối gần như tức thì (0-RTT hoặc 1-RTT handshake).
• Phục hồi mất gói theo luồng riêng — luồng A bị lỗi không làm chậm luồng B.
• Mã hóa toàn bộ dữ liệu từ tầng vận chuyển, không phụ thuộc vào TLS riêng biệt.

Hướng dẫn thực hiện

1. Kiểm tra trạng thái hiện tại: Dùng công cụ như http2.pro, KeyCDN HTTP/2 Test hoặc lệnh curl -I --http2 https://domain.com. Với HTTP/3, kiểm tra bằng curl -I --http3 https://domain.com (cần curl phiên bản ≥ 7.66 + được biên dịch với nghttp3/quiche).
2. Đảm bảo máy chủ hỗ trợ: Apache (≥ 2.4.37 + mod_http2), Nginx (≥ 1.15.0 + bật http_v2), hoặc Cloudflare, Fastly, AWS CloudFront (đều hỗ trợ cả HTTP/2 và HTTP/3).
3. Bật HTTPS bắt buộc: HTTP/2 chỉ hoạt động trên kết nối an toàn (HTTPS). Nếu chưa có SSL/TLS, cài chứng chỉ miễn phí từ Let’s Encrypt.
4. Cấu hình máy chủ:
   • Nginx: thêm listen 443 ssl http2; trong khối server.
   • Apache: bật module mod_http2 và thêm Protocols h2 h2c http/1.1.
5. Kích hoạt HTTP/3: Cần hỗ trợ từ CDN hoặc máy chủ (ví dụ: Cloudflare bật sẵn HTTP/3 cho mọi trang dùng SSL; Nginx cần module ngx_http_v3_module từ phiên bản 1.25.0+).
6. Giám sát hiệu quả: Đo TTFB, LCP và số lượng kết nối qua DevTools (tab Network → cột Protocol), hoặc dùng WebPageTest để so sánh trước/sau.

Lỗi thường gặp

• HTTP/2 hiển thị nhưng không hoạt động thực tế: Do proxy trung gian (firewall, WAF cũ) chặn hoặc không hiểu frame HTTP/2. Cách khắc phục: tắt proxy thử nghiệm, hoặc cập nhật firmware.
• Server push gây phản tác dụng: Đẩy tài nguyên không cần thiết làm lãng phí băng thông và trì hoãn tải nội dung chính. Hiện hầu hết trình duyệt (Chrome từ v85+, Firefox) đã vô hiệu hóa hoàn toàn tính năng này. Khuyến nghị: không cấu hình server push — thay vào đó dùng <link rel="preload"> có kiểm soát.
• HTTP/3 không được nhận diện: Trình duyệt cũ (Chrome <100, Safari <16.4) hoặc hệ điều hành không hỗ trợ QUIC (Windows 10 cũ, Android <12). Đây là vấn đề tương thích — không phải lỗi cấu hình. Giải pháp: giữ HTTP/2 làm dự phòng (tất cả máy chủ hỗ trợ HTTP/3 đều fallback về HTTP/2 tự động).
• Chứng chỉ SSL không hợp lệ hoặc hết hạn: Dẫn đến HTTP/2 và HTTP/3 không khởi động. Kiểm tra bằng openssl s_client -connect domain.com:443 -servername domain.com.

Ví dụ thực tế

Một website thương mại điện tử Việt Nam (domain: shopgiay.vn) đang dùng HTTP/1.1 trên Nginx, TTFB trung bình 420ms, LCP 3.8s trên 3G. Sau khi nâng cấp lên HTTP/2 + TLS 1.3 và tối ưu header, các chỉ số cải thiện:

Chỉ số	Trước nâng cấp	Sau nâng cấp (HTTP/2)	Sau nâng cấp (HTTP/3 + QUIC)
TTFB (3G)	420 ms	290 ms	210 ms
LCP (3G)	3.8 s	2.6 s	2.1 s
Số kết nối TCP	12	1	1 (UDP)

Ghi chú: Kết quả thực tế tùy trường hợp — phụ thuộc vào vị trí người dùng, chất lượng mạng, cấu hình CDN và mức độ tối ưu khác (như lazy load, image compression).

Câu hỏi thường gặp

HTTP/2 và HTTP/3 có cần thay đổi code frontend không?

Không. Cả hai phiên bản đều trong suốt với frontend — không yêu cầu sửa HTML, CSS hay JavaScript. Các thẻ như <img>, <script> vẫn hoạt động như cũ. Chỉ cần cấu hình đúng ở tầng máy chủ và CDN.

Googlebot có hỗ trợ HTTP/3 không?

Tính đến tháng 6/2024, Googlebot chưa hỗ trợ HTTP/3. Nó vẫn thu thập dữ liệu qua HTTP/1.1 và HTTP/2. Tuy nhiên, việc hỗ trợ HTTP/3 trên website không gây hại — và sẽ có lợi khi Googlebot nâng cấp trong tương lai. Hiện tại, ưu tiên HTTP/2 là đủ.

Có nên tắt HTTP/1.1 sau khi bật HTTP/2/3?

Không nên. Việc tắt HTTP/1.1 có thể làm gián đoạn truy cập từ thiết bị cũ (trình duyệt IE, một số smart TV, thiết bị IoT). Máy chủ và CDN luôn tự động negotiate phiên bản phù hợp (ALPN). Hãy giữ HTTP/1.1 làm lớp dự phòng — đây là thực tiễn được khuyến nghị bởi IETF và các nhà cung cấp CDN hàng đầu.