Proxy có hỗ trợ HTTP/3 không? Cách kiểm tra QUIC và HTTP/2 fallback

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

Có, nhưng phụ thuộc vào loại proxy, khả năng chuyển tiếp UDP và cách trình duyệt sử dụng proxy. Việc nhà cung cấp ghi hỗ trợ HTTP hoặc HTTPS không đồng nghĩa dịch vụ đó hỗ trợ HTTP/3. Muốn kết luận chính xác, cần xác định giao thức trên từng chặng kết nối và kiểm tra phiên truy cập thực tế.

Với nhiều cấu hình HTTP proxy hoặc HTTPS proxy truyền thống, trình duyệt truy cập website HTTPS qua đường hầm CONNECT chạy trên TCP. Trong khi đó, HTTP/3 sử dụng QUIC trên UDP. Vì vậy, trình duyệt thường dùng HTTP/2 hoặc HTTP/1.1 cho kết nối đến website qua đường hầm này, thay vì HTTP/3.

Bài viết dưới đây làm rõ khái niệm proxy HTTP/3, điều kiện hỗ trợ proxy QUIC và quy trình kiểm tra HTTP/3 để xác nhận HTTP/2 fallback mà không chỉ dựa vào thông tin quảng cáo.

Hiểu đúng HTTP/3, QUIC và các chặng kết nối proxy

HTTP/3 sử dụng QUIC thay cho TCP

HTTP/2 thường được trình duyệt sử dụng trên kết nối TLS qua TCP. HTTP/3 ánh xạ các trao đổi HTTP lên QUIC, một giao thức truyền tải hoạt động trên UDP và tích hợp cơ chế bảo mật dựa trên TLS.

Khác biệt này quan trọng khi dùng proxy. Một proxy chỉ chuyển tiếp luồng TCP không tự động vận chuyển được các gói QUIC. Đồng thời, chỉ cho phép UDP ở mạng cục bộ cũng chưa đủ: ứng dụng, proxy và tuyến mạng phải cùng hỗ trợ phương thức truyền phù hợp.

Kết nối đến proxy khác kết nối đến website

Giao thức ở chặng đến proxy có thể khác với giao thức ở chặng đến máy chủ đích.

Khi đánh giá proxy HTTP/3, cần tách chặng từ trình duyệt đến proxy khỏi chặng đến website đích. Tùy kiến trúc, proxy có thể chỉ chuyển tiếp đường hầm hoặc tự thiết lập kết nối HTTP tới máy chủ đích.

Chẳng hạn, một reverse proxy có thể tiếp nhận HTTP/3 từ người dùng nhưng liên lạc với máy chủ phía sau bằng HTTP/2. Ngược lại, một dịch vụ có thể dùng HTTP/3 trên chặng nội bộ mà trình duyệt vẫn chỉ trao đổi HTTP/2 với điểm kết nối phía trước.

Hỗ trợ HTTP/3 trên một chặng không chứng minh HTTP/3 được sử dụng trên toàn bộ đường đi. Báo cáo kiểm tra cần nêu rõ đang quan sát chặng nào, thay vì chỉ kết luận rằng toàn bộ proxy có hoặc không có QUIC.

Những loại proxy nào có thể vận chuyển QUIC?

HTTP proxy và HTTPS proxy truyền thống

Với website HTTPS, trình duyệt thường yêu cầu HTTP proxy mở đường hầm CONNECT đến máy chủ đích. Kiểu CONNECT truyền thống cung cấp một luồng TCP, phù hợp với TLS và HTTP/2 nhưng không trực tiếp chuyển tiếp datagram UDP của QUIC.

HTTPS proxy bổ sung lớp TLS cho chặng kết nối đến proxy. Tên gọi này không có nghĩa proxy hỗ trợ mọi phiên bản HTTP hoặc có khả năng vận chuyển QUIC. Cần đọc tài liệu về phương thức đường hầm mà dịch vụ thực sự triển khai.

SOCKS5 và khả năng UDP

SOCKS5 có cơ chế UDP ASSOCIATE, nhưng khả năng được định nghĩa trong giao thức không đồng nghĩa trình duyệt sẽ sử dụng nó. Nhiều cấu hình SOCKS trong trình duyệt chủ yếu phục vụ lưu lượng TCP.

Do đó, thông báo hỗ trợ UDP của một SOCKS5 proxy chưa đủ để xác nhận trình duyệt chạy HTTP/3 qua proxy đó. Cần kiểm tra cả máy chủ proxy, ứng dụng khách và cách ứng dụng ánh xạ lưu lượng QUIC vào kết nối proxy.

CONNECT-UDP và kiến trúc MASQUE

CONNECT-UDP là cơ chế liên quan trực tiếp đến việc chuyển tiếp UDP qua HTTP. Các triển khai thuộc kiến trúc MASQUE có thể cung cấp nền tảng để vận chuyển lưu lượng UDP, bao gồm QUIC, qua proxy.

Tuy nhiên, không nên suy luận rằng chỉ cần proxy hỗ trợ CONNECT-UDP là mọi trình duyệt sẽ tự sử dụng được. Ứng dụng khách phải hỗ trợ cơ chế tương ứng, được cấu hình đúng và tương thích với dịch vụ. Proxy dùng HTTP/3 để nhận kết nối cũng chưa chắc đã cung cấp chức năng chuyển tiếp UDP đến website.

Chuẩn bị môi trường kiểm tra HTTP/3

Một phép thử đáng tin cậy cần có đường cơ sở không dùng proxy. Nếu website chưa từng hoạt động bằng HTTP/3 trên kết nối trực tiếp, việc thấy HTTP/2 khi bật proxy chưa thể chứng minh proxy là nguyên nhân.

• Chọn website có hỗ trợ HTTP/3: ưu tiên điểm kiểm tra được công bố rõ ràng và có thể quan sát giao thức trong trình duyệt.
• Giữ nguyên điều kiện: dùng cùng thiết bị, trình duyệt, mạng và địa chỉ website cho các lần đối chiếu.
• Ghi nhận cấu hình: lưu loại proxy, phương thức xác thực và phạm vi áp dụng cho trình duyệt hoặc hệ điều hành.
• Kiểm soát yếu tố trung gian: ghi nhận VPN, phần mềm kiểm tra HTTPS, tiện ích mở rộng và chính sách quản trị.
• Dùng phiên thử nghiệm tách biệt: đóng các phiên liên quan hoặc dùng hồ sơ trình duyệt riêng để hạn chế ảnh hưởng của kết nối đã mở.

Website có thể giới thiệu HTTP/3 thông qua Alt-Svc hoặc bản ghi DNS HTTPS. Trình duyệt đôi khi cần một lần truy cập ban đầu trước khi thiết lập HTTP/3. Vì vậy, lần tải đầu tiên dùng HTTP/2 không nhất thiết có nghĩa website không hỗ trợ HTTP/3.

Cách kiểm tra HTTP/3 trong trình duyệt

Quan sát cột Protocol trong DevTools

Quan sát giao thức của tài liệu chính và các yêu cầu cùng tên miền trong bảng Network.

Với trình duyệt dựa trên Chromium, mở công cụ dành cho nhà phát triển, chuyển đến Network và bật cột Protocol từ menu tiêu đề bảng. Tên mục có thể khác theo ngôn ngữ và phiên bản trình duyệt.

1. Tắt proxy, truy cập website kiểm tra và mở bảng Network.
2. Tải lại trang; có thể bật Disable cache khi DevTools đang mở để giảm ảnh hưởng của bộ nhớ đệm HTTP.
3. Quan sát yêu cầu tài liệu chính và các yêu cầu tới cùng hostname.
4. Nếu cần, truy cập lại để trình duyệt có cơ hội sử dụng thông tin quảng bá HTTP/3.
5. Ghi nhận giá trị giao thức, tên miền và trạng thái phản hồi của các yêu cầu đại diện.

Giá trị h3 cho biết yêu cầu được công cụ ghi nhận sử dụng HTTP/3; h2 tương ứng HTTP/2. Nếu hiển thị HTTP/1.1, yêu cầu đang dùng phiên bản đó, không phải HTTP/2 fallback.

Một trang có thể tải tài nguyên từ nhiều tên miền với giao thức khác nhau. Không nên dùng kết quả của một tài nguyên quảng cáo hoặc ảnh bên ngoài để kết luận về kết nối tới tên miền chính.

Phân biệt phản hồi mạng với dữ liệu có sẵn

Yêu cầu được phục vụ từ bộ nhớ đệm hoặc service worker có thể không tạo kết nối mạng mới. Khi kiểm tra HTTP/3, hãy ưu tiên yêu cầu thực sự đi qua mạng và xem thông tin nguồn phản hồi.

Disable cache không nhất thiết xóa trạng thái Alt-Svc hoặc đóng kết nối hiện có. Nếu kết quả khó giải thích, đóng hoàn toàn trình duyệt rồi thử lại bằng hồ sơ kiểm tra riêng, thay vì chỉ tải lại trang.

Cách xác nhận trình duyệt chuyển về HTTP/2 khi dùng proxy

Đối chiếu kết nối trực tiếp và kết nối qua proxy

Sau khi quan sát được h3 khi truy cập trực tiếp, bật proxy và thiết lập phiên kết nối mới. Không nên chỉ đổi cấu hình rồi tiếp tục dùng tab đang giữ kết nối cũ.

1. Cấu hình proxy và kiểm tra xem cấu hình đã được áp dụng cho trình duyệt chưa.
2. Xác nhận tuyến truy cập qua nhật ký proxy hoặc một điểm kiểm tra địa chỉ IP phù hợp.
3. Mở lại đúng website đã dùng làm đường cơ sở.
4. Quan sát cột Protocol của tài liệu chính và các yêu cầu cùng hostname.
5. Ghi nhận liệu yêu cầu thành công bằng h2, HTTP/1.1 hay gặp lỗi kết nối.
6. Tắt proxy, tạo phiên mới và kiểm tra lại để củng cố kết quả đối chiếu.

Nếu kết nối trực tiếp sử dụng h3 còn kết nối qua proxy sử dụng h2, có thể kết luận phiên truy cập qua proxy đang dùng HTTP/2 thay cho HTTP/3. Đây là bằng chứng thực tế hữu ích về hành vi HTTP/2 fallback trong cấu hình đã kiểm tra.

Phân biệt chọn HTTP/2 với thử QUIC rồi thất bại

Chỉ nhìn thấy h2 chưa chứng minh trình duyệt đã gửi QUIC, thất bại rồi mới chuyển giao thức. Trình duyệt có thể biết cấu hình proxy không phù hợp và chọn HTTP/2 ngay từ đầu.

Nếu cần xác định trình tự chính xác, hãy thu nhật ký mạng của trình duyệt, chẳng hạn bằng chức năng NetLog trên Chromium. Tìm thông tin về lựa chọn proxy, thiết lập QUIC, kết nối TCP và giao thức được thương lượng.

Kết luận nên phản ánh đúng bằng chứng: “truy cập qua proxy dùng HTTP/2” khác với “đã ghi nhận lần thử QUIC không thành công trước khi thiết lập HTTP/2”.

Kiểm tra QUIC ở cấp mạng và bằng công cụ dòng lệnh

Quan sát UDP bằng công cụ bắt gói

Dữ liệu bắt gói cần được đối chiếu với giao thức trong trình duyệt và nhật ký proxy để xác nhận đường đi của QUIC.

Công cụ bắt gói có thể hỗ trợ xác định lưu lượng UDP và các kết nối được nhận diện là QUIC. Hãy giới hạn phạm vi theo thời điểm thử nghiệm, địa chỉ đích và tiến trình nếu công cụ hỗ trợ.

Tuy nhiên, có UDP không đồng nghĩa yêu cầu website đang dùng HTTP/3. Lưu lượng có thể thuộc ứng dụng khác hoặc một chức năng khác của trình duyệt. Ngược lại, khi dùng đường hầm mã hóa, quan sát tại thiết bị có thể chỉ cho thấy kết nối bên ngoài đến proxy.

Để xác nhận QUIC thực sự được vận chuyển qua proxy, nên kết hợp thông tin giao thức trong trình duyệt, nhật ký proxy và dữ liệu bắt gói. Địa chỉ IP đầu ra thay đổi chỉ chứng minh yêu cầu kiểm tra IP đi theo tuyến đó, không chứng minh mọi kết nối đều như vậy.

Dùng curl để kiểm tra bổ trợ

curl có thể hỗ trợ kiểm tra HTTP/3 nếu bản cài đặt được biên dịch với tính năng phù hợp. Trước tiên, kiểm tra thông tin phiên bản và tính năng; sau đó xem tài liệu của bản đang dùng về các tùy chọn --http3, --http3-only và cấu hình proxy.

Cần phân biệt chế độ cho phép chuyển sang giao thức khác với chế độ chỉ chấp nhận HTTP/3. Đồng thời, hỗ trợ HTTP/3 tới máy chủ đích không tự động đồng nghĩa curl hỗ trợ vận chuyển QUIC qua loại proxy đang thử.

Kết quả curl chỉ mang tính bổ trợ cho trình duyệt, vì hai ứng dụng có thể khác nhau về thư viện QUIC, cách xử lý proxy và chính sách kết nối.

Những kết luận dễ sai khi đánh giá proxy HTTP/3

• Thấy Alt-Svc rồi khẳng định đã dùng HTTP/3: tiêu đề này quảng bá khả năng, không xác nhận giao thức của phản hồi hiện tại.
• Thấy h2 rồi quy lỗi ngay cho proxy: cần loại trừ khả năng website, mạng hoặc chính sách trình duyệt đã không cho phép HTTP/3 từ trước.
• Thấy h3 khi bật proxy rồi kết luận QUIC đi qua proxy: cần kiểm tra phạm vi cấu hình, quy tắc loại trừ và tuyến kết nối thực tế.
• Đồng nhất hỗ trợ UDP với hỗ trợ trình duyệt: máy chủ có UDP nhưng ứng dụng khách có thể không sử dụng được cơ chế đó.
• Xem HTTP/2 fallback là lỗi: HTTP/2 vẫn có thể là giao thức hoạt động bình thường và phù hợp với kiến trúc proxy.

Kết luận

Proxy có thể hỗ trợ HTTP/3, nhưng cần đánh giá cụ thể cơ chế vận chuyển UDP, khả năng của ứng dụng khách và từng chặng kết nối. Với HTTP proxy hoặc HTTPS proxy dùng CONNECT truyền thống, HTTP/2 thường là lựa chọn thực tế cho truy cập HTTPS thay vì QUIC.

Quy trình kiểm tra đáng tin cậy là xác nhận h3 khi kết nối trực tiếp, tạo phiên mới qua proxy, quan sát h2 và đối chiếu nhật ký khi cần. Cách làm này giúp phân biệt proxy thực sự vận chuyển QUIC với trường hợp trình duyệt sử dụng HTTP/2, đồng thời không nhầm lựa chọn giao thức ban đầu với một lần thử QUIC thất bại.