Ứng dụng có thể vẫn mở website dù giao thức hoặc đường đi khác với dự kiến. Khi mục tiêu là kiểm thử HTTP/3 qua proxy, kết quả “trang chạy” mới chỉ là bước đầu.
HTTP/3 cần gì?
HTTP/3 sử dụng QUIC dựa trên UDP. Khi QUIC không thiết lập được, client có thể chuyển sang HTTP dựa trên TCP; xem RFC 9114. Không mặc định proxy HTTP/TCP truyền được mọi UDP.
Đặt câu hỏi đúng cho nhà cung cấp
- Gói hỗ trợ giao thức và loại lưu lượng nào?
- Client đang dùng có hỗ trợ cơ chế đó qua proxy không?
- Việc phân giải tên và định tuyến diễn ra ở đâu?
- Hành vi fallback được cấu hình và quan sát như thế nào?
- Đích kiểm thử có thực sự phục vụ HTTP/3 không?
Khả năng UDP của một sản phẩm không đồng nghĩa mọi ứng dụng HTTP/3 sẽ hoạt động qua nó. Cần kiểm tra sự kết hợp cụ thể giữa client, cấu hình, dịch vụ và đích.
Ghi giao thức và tuyến
- Dùng một endpoint thử hợp lệ và tác vụ nhỏ.
- Quan sát giao thức tại client bằng công cụ được hỗ trợ.
- Đối chiếu log hoặc dấu vết tuyến do bạn có quyền quản lý.
- Ghi rõ phần nào đã đo và phần nào chưa xác minh.
- Kiểm tra fallback riêng nếu đó là yêu cầu của ứng dụng.
Ví dụ minh họa
Đội thử thấy website tải thành công và kết luận UDP đã đi qua proxy. Khi xem công cụ mạng, client thực tế dùng HTTP/2. Kết quả xác nhận tác vụ web hoạt động với giao thức đó, không xác nhận HTTP/3 hoặc UDP của toàn tuyến.
Không suy luận “không lộ IP” từ giao diện
Ứng dụng có thể có tuyến hoặc thành phần không theo cấu hình proxy mong muốn. Nếu yêu cầu công việc là mọi lưu lượng liên quan phải qua tuyến đã phê duyệt, cần kiểm thử và chính sách quản trị phù hợp. Không lấy một request kiểm tra IP làm bằng chứng cho mọi giao thức.
Kết luận bằng điều kiện cụ thể
Ghi phiên bản client, endpoint, giao thức quan sát, cấu hình tuyến đã che bí mật và tiêu chí thành công. Đọc thêm HTTP, HTTPS và SOCKS5. Bài viết không công bố khả năng UDP hoặc HTTP/3 chưa được nhà cung cấp xác nhận cho từng gói.