WebTransport và proxy: stream, datagram và giới hạn của UDP

WebTransport và proxy là chủ đề về việc API WebTransport của trình duyệt chạy trên HTTP/3 và QUIC, tức trên UDP, trong khi phần lớn proxy HTTP chỉ chuyển tiếp TCP qua lệnh CONNECT. Hai thứ này không khớp nhau theo mặc định, nên câu hỏi "WebTransport có đi qua proxy được không" cần trả lời theo từng loại proxy. ProxyVN dựng máy chủ WebTransport bằng aioquic trên máy lab, kết nối từ Chrome 152 trong app Claude, đo bắt tay, stream hai chiều và 20 datagram để anh em thấy giao thức này khác WebSocket ở đâu.

WebTransport và proxy: lớp nào quyết định hành vi

WebTransport là API trình duyệt cho phép trang web mở kết nối hai chiều tới máy chủ, gửi nhiều luồng dữ liệu song song và gửi datagram không cần bảo đảm tới nơi. Nó thường được nhắc như người kế nhiệm WebSocket cho game, gọi video và ứng dụng thời gian thực.

Giao thức bên dưới

Tài liệu MDN về WebTransport mô tả API này chạy trên HTTP/3, tức HTTP trên QUIC. QUIC là giao thức truyền tải chạy trên UDP, có mã hóa TLS 1.3 tích hợp. Một phiên WebTransport bắt đầu bằng một request CONNECT mở rộng trên HTTP/3, có trường :protocol bằng webtransport.

Sau khi máy chủ chấp nhận, trình duyệt mở được luồng một chiều, luồng hai chiều và gửi datagram trong cùng một kết nối QUIC. Mọi thứ đi trong gói UDP tới cổng của máy chủ, thường là 443.

Proxy HTTP chuyển tiếp gì

Proxy HTTP thông thường nhận lệnh CONNECT trên kết nối TCP và mở một đường hầm TCP tới đích. Bài proxy tunnel là gì giải thích cơ chế này. Đường hầm TCP mang được HTTPS, WebSocket, gRPC trên HTTP/2, vì tất cả đều chạy trên TCP.

QUIC chạy trên UDP. Đường hầm TCP không mang được gói UDP. Muốn chuyển QUIC qua proxy, proxy phải hỗ trợ chuyển tiếp UDP: CONNECT-UDP theo RFC 9298, một phần của nhóm giao thức MASQUE, hoặc lệnh UDP ASSOCIATE của SOCKS5.

WebTransport không đi qua đường hầm CONNECT thường được, vì nó cần UDP còn đường hầm chỉ có TCP.

Ai dùng WebTransport

WebTransport hiện xuất hiện chủ yếu ở game trên trình duyệt, phát video độ trễ thấp, công cụ cộng tác thời gian thực và một số dịch vụ truyền dữ liệu đo lường. Trang tin tức, trang thương mại điện tử và trang mạng xã hội phần lớn vẫn dùng HTTP thường và WebSocket.

Với người dùng proxy, câu hỏi thực tế thường là: một trang cần cho công việc báo lỗi kết nối khi bật proxy, trong khi tắt proxy thì chạy. Nếu trang đó dùng WebTransport mà không có dự phòng, proxy HTTP chính là nguyên nhân. Biết điều này giúp tránh mất thời gian đổi proxy này sang proxy khác cùng loại.

Trình duyệt quyết định đi đường nào

Khi trình duyệt cấu hình proxy HTTP, nó phải chọn giữa đi thẳng bằng UDP, bỏ qua proxy, hay báo lỗi. Hành vi này do trình duyệt quyết định, không phải trang web. Trang web không biết trình duyệt có proxy hay không, nó chỉ thấy kết nối thành công hay thất bại.

Bài này không kiểm hành vi của Chrome khi có proxy, vì trình duyệt trong app không cho đổi cấu hình proxy. Phần đó ghi ở mục giới hạn và trong checklist để anh em tự kiểm trên môi trường của mình.

Ranh giới với các bài đã có

Bài WebSocket qua HTTP proxy nói về WebSocket, chạy trên TCP và đi qua CONNECT bình thường. Bài proxy HTTP/3 và QUIC và proxy HTTP/3 MASQUE nói về HTTP/3 và chuyển tiếp UDP nói chung. Bài này đi vào WebTransport: stream, datagram, lỗi bắt tay và hệ quả với proxy.

Giải thích stream, datagram WebTransport và giới hạn hạ tầng proxy theo giao thức khi xét WebTransport và proxy

Stream và datagram

Phần này đi qua hai kiểu dữ liệu của WebTransport và xem mỗi loại proxy làm được gì với chúng.

Stream: tin cậy, có thứ tự

Stream giống một kết nối TCP thu nhỏ bên trong QUIC: dữ liệu tới đủ, đúng thứ tự. Khác TCP ở chỗ nhiều stream chạy song song trong một kết nối, mất gói ở stream này không làm stream khác phải chờ. WebSocket không có tính năng này, mọi tin nhắn đi trên một kết nối TCP duy nhất.

API có createBidirectionalStream cho luồng hai chiều và createUnidirectionalStream cho luồng một chiều. Mỗi luồng có readable và writable theo kiểu Streams API của trình duyệt.

Datagram: không bảo đảm, không thứ tự

Datagram là gói tin rời, gửi một lần, có thể mất, có thể tới lệch thứ tự. Kích thước tối đa giới hạn theo gói QUIC, trình duyệt cho biết qua thuộc tính maxDatagramSize. Datagram hợp với dữ liệu mà gói mới quan trọng hơn gói cũ, như vị trí trong game hay số đo thời gian thực.

WebSocket không có datagram. Muốn gửi dữ liệu không bảo đảm trên WebSocket là không được, mọi thứ đều tin cậy và có thứ tự. Đây là khác biệt lớn nhất về khả năng giữa hai API.

Phiên và kết nối

Một kết nối QUIC có thể mang nhiều phiên WebTransport, mỗi phiên có nhiều stream và datagram. Khi kết nối QUIC đứt, mọi phiên trên đó đứt theo. QUIC có cơ chế di chuyển kết nối khi đổi mạng, ví dụ từ Wi-Fi sang 4G, mà không cần bắt tay lại, điều TCP không làm được.

Với proxy, cơ chế di chuyển này phụ thuộc proxy có giữ được ánh xạ UDP khi địa chỉ nguồn đổi hay không. Proxy UDP đơn giản thường không giữ, nên kết nối đứt khi đổi mạng dù QUIC hỗ trợ.

Mỗi loại proxy làm được gì

Proxy nào mang được UDP

Bảng: Mỗi loại proxy làm được gì

Loại proxy	WebSocket	WebTransport trên HTTP/3	Ghi chú
HTTP proxy, CONNECT trên TCP	Được	Không mang được UDP	Loại phổ biến nhất
SOCKS5 chỉ hỗ trợ CONNECT	Được	Không	Nhiều dịch vụ SOCKS5 tắt UDP
SOCKS5 có UDP ASSOCIATE	Được	Về lý thuyết có, tùy trình duyệt	Ít trình duyệt dùng UDP qua SOCKS
Proxy hỗ trợ CONNECT-UDP, MASQUE	Được	Có thể	Còn mới, ít dịch vụ
VPN hoặc proxy tầng mạng	Được	Được	Chuyển mọi gói IP
Reverse proxy phía máy chủ	Tùy cấu hình	Cần hỗ trợ HTTP/3 và WebTransport	Do chủ trang quyết định

Bảng này theo đặc tả giao thức. Dòng thứ ba ghi về lý thuyết vì lab không có proxy SOCKS5 UDP và trình duyệt để thử. Dòng cuối là chuyện của chủ trang web, không phải người dùng proxy.

QUIC mã hóa gần hết tiêu đề

Với TCP, thiết bị mạng giữa đường đọc được cờ, số thứ tự và trạng thái kết nối. Với QUIC, gần như mọi thứ sau tiêu đề ngắn đều được mã hóa. Proxy hay tường lửa muốn hiểu luồng QUIC chỉ thấy địa chỉ, cổng và vài trường công khai.

Điều này làm việc kiểm soát lưu lượng QUIC khó hơn TCP. Nhiều mạng doanh nghiệp chọn cách đơn giản là chặn UDP 443 để buộc trình duyệt quay về TCP. Kết quả là HTTP/3 và WebTransport không chạy trong các mạng đó.

Cổng UDP 443 và tường lửa

Nhiều mạng công ty chặn UDP ra ngoài, chỉ cho TCP qua proxy. Trong mạng như vậy, HTTP/3 và WebTransport không chạy. Trình duyệt thường tự rơi về HTTP/2 với trang web thường, nhưng WebTransport không có bản dự phòng nào được triển khai rộng.

Đặc tả có bản nháp WebTransport trên HTTP/2, chạy trên TCP, để dùng khi UDP bị chặn. Bản này chưa được trình duyệt chính hỗ trợ ở thời điểm viết, bài chưa thử.

Thiết kế lab WebTransport và proxy: phiên bản và phép đo

Lab chạy ngày 29/10/2026 trên Windows 10. Máy chủ viết bằng Python 3.12.10 với aioquic 1.7.0 và cryptography. Trình duyệt là khung trình duyệt trong ứng dụng Claude, user agent ghi Chrome/152.0.7977.167.

Máy chủ aioquic

Máy chủ nghe UDP ở 127.0.0.1 cổng 9590, bật HTTP/3 với enable_webtransport và cho phép datagram. Khi nhận request CONNECT có :protocol bằng webtransport, máy chủ trả 200 kèm header sec-webtransport-http3-draft. Dữ liệu nhận trên stream được gửi lại kèm tiền tố echo, datagram cũng vậy.

Máy chủ ghi log mỗi sự kiện: header nhận được, số byte trên stream, mỗi datagram. Một máy chủ HTTP thường ở cổng 9591 phục vụ trang thử và tệp chứa mã băm chứng chỉ.

Chứng chỉ tự ký và serverCertificateHashes

WebTransport bắt buộc TLS. Với máy chủ thử không có chứng chỉ từ cơ quan cấp phát, API cho phép truyền mã băm SHA-256 của chứng chỉ qua tùy chọn serverCertificateHashes. Đặc tả WebTransport của W3C đặt điều kiện cho chứng chỉ dùng cách này, gồm thời hạn ngắn và khóa ECDSA.

Lab sinh chứng chỉ ECDSA P-256 hạn 10 ngày cho localhost và 127.0.0.1, tính mã băm từ bản DER và đưa vào trang thử.

Vì sao chạy trên trình duyệt thật

WebTransport là API của trình duyệt, nên cách kiểm đáng tin nhất là chạy trong trình duyệt thật. Thư viện Python có thể làm client QUIC, nhưng hành vi chứng chỉ, origin và thông báo lỗi chỉ đúng khi đo trong trình duyệt. Khung trình duyệt trong ứng dụng Claude dùng Chromium bản 152, đủ để đo.

Trang thử được phục vụ qua http://127.0.0.1, một origin được coi là an toàn như HTTPS cho mục đích thử nghiệm cục bộ. Nhờ vậy không cần chứng chỉ cho trang, chỉ cần chứng chỉ cho máy chủ WebTransport.

Bốn lần kết nối

Lần một không truyền mã băm. Lần hai truyền mã băm sai, 32 byte toàn số 7. Lần ba truyền mã băm đúng nhưng tới cổng 9599, nơi không có máy chủ. Lần bốn truyền mã băm đúng tới cổng 9590.

Với lần bốn, trang mở một stream hai chiều, gửi chuỗi xin chao, đọc phản hồi. Sau đó gửi 20 datagram liên tiếp và đếm số datagram phản hồi nhận được trong khoảng 1,5 giây.

Vì sao không có proxy trong lab

Trình duyệt trong ứng dụng không cho đổi cấu hình proxy, và máy lab không có proxy hỗ trợ UDP để thử. Thay vì dựng một kịch bản không đo được, lab tập trung vào phần đo được: bắt tay, chứng chỉ, stream, datagram và thông báo lỗi. Phần proxy được suy ra từ đặc tả và ghi rõ là suy ra.

Kết quả có ích cho cả hai phía. Người làm ứng dụng biết lỗi nào trông ra sao. Người dùng proxy biết khi gặp thông báo Opening handshake failed thì đó là lỗi tầng nào có thể gây ra.

Kết quả kỳ vọng

Ba lần đầu thất bại. Lần bốn thành công, stream trả về echo:xin chao, datagram có thể mất vài gói vì không bảo đảm.

Tái lập WebTransport và proxy: luồng thành công và các ca lỗi có kiểm soát

Phần này đưa mã cốt lõi của trang thử và kết quả thật đọc từ trang và từ log máy chủ.

Mã kết nối

const hash = Uint8Array.from(atob(h.hash_b64), c => c.charCodeAt(0));
const wt = new WebTransport("https://127.0.0.1:9590/wt", {
  serverCertificateHashes: [{ algorithm: "sha-256", value: hash }]
});
await wt.ready;
const s = await wt.createBidirectionalStream();
const w = s.writable.getWriter();
await w.write(new TextEncoder().encode("xin chao"));
await w.close();

Kết quả bốn lần kết nối

Bảng: Kết quả bốn lần kết nối

Lần	Điều kiện	Kết quả trên trang	Thời gian
1	Không mã băm	WebTransportError: Opening handshake failed	17 ms
2	Mã băm sai	WebTransportError: Opening handshake failed	24 ms
3	Cổng không có máy chủ	WebTransportError: Opening handshake failed	21 ms
4	Mã băm đúng	ready	54 ms

Ba lần thất bại vì ba lý do khác nhau cho cùng một thông báo lỗi. Trang web không phân biệt được chứng chỉ sai với máy chủ không tồn tại. Đây là thiết kế có chủ ý để trang không dò được mạng nội bộ của người dùng, nhưng làm chẩn đoán khó hơn nhiều.

Log máy chủ chỉ có một dòng header, của lần bốn. Lần một và hai thất bại ở bắt tay TLS trong QUIC, trước khi có request HTTP. Lần ba không tới máy chủ nào.

Header mà máy chủ nhận

Dòng header duy nhất ghi phương thức CONNECT, giao thức webtransport, đường dẫn /wt và origin http://127.0.0.1:9591. Origin là trang đã mở kết nối. Máy chủ WebTransport nên kiểm origin này, giống máy chủ WebSocket kiểm origin, để chặn trang lạ mở kết nối.

Stream và datagram

Bảng: Stream và datagram

Phép đo	Kết quả
Stream hai chiều	Nhận echo:xin chao sau 21 ms
Số stream máy chủ ghi	2 sự kiện, một có dữ liệu, một đánh dấu kết thúc
Datagram trình duyệt gửi	20
Datagram máy chủ nhận	20
Datagram trình duyệt nhận lại	17 trong khoảng 1,5 giây
maxDatagramSize	1024 byte

Máy chủ nhận đủ 20 datagram và gửi lại 20. Trình duyệt chỉ đọc được 17. Ba datagram phản hồi bị mất ở chiều về, ngay cả trên loopback không có mạng thật. Đây là bản chất của datagram: không bảo đảm tới nơi, ứng dụng phải chịu được mất gói.

Với stream, dữ liệu tới đủ. Chuỗi xin chao và phần echo tới nguyên vẹn, đúng thứ tự.

Vì sao datagram mất cả trên loopback

Loopback không có mạng vật lý, nhưng có bộ đệm. Datagram được gửi liên tiếp nhanh, phía nhận có hàng đợi giới hạn. Khi hàng đợi đầy, datagram mới bị bỏ thay vì chờ. Với stream, cơ chế điều khiển luồng làm bên gửi chậm lại, với datagram thì không.

Ứng dụng gửi datagram nên giới hạn tốc độ gửi theo khả năng xử lý của bên nhận, và không coi việc gửi thành công là việc nhận thành công. Đo tỷ lệ mất trên môi trường thật trước khi chọn dùng datagram cho dữ liệu quan trọng.

Ý nghĩa với proxy

Toàn bộ lab chạy trên UDP loopback, không có proxy. Nếu đặt một HTTP proxy giữa trình duyệt và máy chủ này, đường đi UDP không thể vào đường hầm CONNECT TCP. Kết nối hoặc đi thẳng không qua proxy, hoặc thất bại, tùy trình duyệt. Trong cả hai trường hợp, thông báo lỗi trên trang vẫn là Opening handshake failed như ba ca lỗi trên.

Khi WebTransport lỗi trong môi trường có proxy, thông báo lỗi không cho biết lỗi do proxy hay do chứng chỉ. Phải kiểm từng lớp riêng.

Đọc log, gói tin và response để tách nguyên nhân khi xét WebTransport và proxy

Vì trang web chỉ thấy một thông báo lỗi chung, chẩn đoán phải dựa vào nguồn khác: công cụ của trình duyệt, log máy chủ và gói tin.

Bảng nguyên nhân

Một thông báo cho ba lỗi

Bảng: Bảng nguyên nhân

Nguyên nhân	Log máy chủ	Gói tin UDP tới máy chủ	Cách kiểm
Chứng chỉ không được tin	Không có header	Có gói QUIC Initial	Kiểm mã băm, thời hạn, loại khóa
Máy chủ không chạy hoặc sai cổng	Không có gì	Có gói đi, không có gói về	Kiểm máy chủ nghe UDP
UDP bị tường lửa hoặc mạng chặn	Không có gì	Không tới máy chủ	Thử từ mạng khác
Trình duyệt có proxy không chuyển UDP	Không có gì	Không đi hoặc đi thẳng	Tắt proxy và thử lại
Máy chủ từ chối origin	Có header	Có	Kiểm log máy chủ
Máy chủ không hỗ trợ WebTransport	Có header, trả lỗi	Có	Kiểm cấu hình HTTP/3

Ba dòng giữa đều cho log máy chủ trống. Cách tách chúng là thử từ mạng không có proxy và không chặn UDP. Nếu chạy được, nguyên nhân nằm ở proxy hoặc tường lửa của mạng ban đầu.

Công cụ của trình duyệt

Chrome có trang net-internals và công cụ ghi log mạng, ghi chi tiết bắt tay QUIC và lý do thất bại mà trang web không thấy. Mở công cụ này trong lúc tái lập lỗi sẽ thấy lỗi chứng chỉ, lỗi kết nối hay lỗi do proxy.

Gói tin

Wireshark nhận ra gói QUIC trên UDP 443 hoặc cổng tùy chọn. Bắt gói trên máy client cho biết trình duyệt có gửi gói QUIC hay không. Nếu không có gói nào khi kết nối WebTransport, trình duyệt không thử đi bằng UDP, có thể do cấu hình proxy hoặc chính sách. Bài Wireshark proxy có cách lọc gói theo cổng.

Log phía máy chủ nên ghi gì

Máy chủ WebTransport nên ghi mỗi request CONNECT với origin, đường dẫn và kết quả chấp nhận hay từ chối, như lab làm. Thêm số stream mở, số datagram nhận và gửi theo phiên. Khi người dùng báo lỗi, log này cho biết request có tới máy chủ không.

Nếu log không có dòng nào cho thời điểm người dùng báo lỗi, lỗi xảy ra trước tầng HTTP: chứng chỉ, mạng hoặc proxy. Nếu có dòng mà bị từ chối, lỗi nằm ở cấu hình máy chủ. Hai trường hợp cần hai hướng xử lý khác nhau.

So với WebSocket trong cùng môi trường

Một cách tách nhanh là mở WebSocket tới cùng máy chủ trong cùng môi trường. Nếu WebSocket chạy qua proxy mà WebTransport không chạy, nguyên nhân gần như chắc là UDP không đi được. Nếu cả hai đều lỗi, vấn đề nằm ở tầng chung như DNS, tường lửa hay máy chủ.

Xử lý WebTransport và proxy theo bằng chứng và checklist

Checklist WebTransport

Phần này gom cách xử lý cho hai phía: người làm ứng dụng web và người dùng hoặc vận hành proxy.

Phía ứng dụng web: luôn có đường dự phòng

Vì WebTransport có thể không chạy trong mạng có proxy HTTP hoặc chặn UDP, ứng dụng nên có đường dự phòng bằng WebSocket. Thử WebTransport trước, nếu thất bại trong thời gian ngắn thì chuyển sang WebSocket. Ứng dụng mất datagram và luồng song song nhưng vẫn chạy được.

Giữ logic ứng dụng tách khỏi lớp truyền tải để chuyển qua lại dễ. Ghi lại lý do chuyển vào log phía máy chủ khi kết nối WebSocket dự phòng tới, để biết bao nhiêu người dùng không dùng được WebTransport.

Phía ứng dụng web: kiểm origin

Máy chủ nên kiểm header origin và từ chối origin lạ. Lab cho thấy origin đi kèm request CONNECT. Không kiểm origin thì trang bất kỳ cũng mở được kết nối tới máy chủ WebTransport của anh em.

Phía ứng dụng web: đặt thời gian chờ ngắn

Khi UDP bị chặn im lặng, wt.ready có thể chờ lâu trước khi thất bại. Đặt một mốc thời gian ngắn, ví dụ ba giây, rồi chuyển sang WebSocket nếu chưa sẵn sàng. Người dùng trong mạng chặn UDP sẽ chỉ chờ ba giây thay vì đợi hết thời gian chờ mặc định.

Có thể ghi nhớ kết quả trong phiên trình duyệt: lần sau người dùng đó vào, đi thẳng WebSocket nếu lần trước WebTransport thất bại. Cách này tránh bắt người dùng chờ mỗi lần tải trang.

Phía người dùng proxy

Nếu công việc cần WebTransport và phải qua proxy, cần proxy hỗ trợ chuyển tiếp UDP. Với SOCKS5, hỏi nhà cung cấp có bật UDP ASSOCIATE không. Với proxy tầng mạng hoặc VPN, UDP thường được chuyển. Proxy HTTP thường không giúp được.

Với phần lớn công việc qua proxy như cào dữ liệu, kiểm tra quảng cáo hay quản lý tài khoản, WebTransport hiếm khi là yêu cầu. Trang web dùng WebTransport thường có dự phòng WebSocket chạy qua proxy HTTP bình thường.

Phía người dùng proxy: kiểm nhanh trang có dùng WebTransport không

Mở công cụ nhà phát triển của trình duyệt, tab mạng, rồi tải trang. Kết nối WebTransport hiện với loại riêng, khác request HTTP thường và WebSocket. Nếu trang chỉ dùng WebSocket, proxy HTTP thông thường đủ cho trang đó.

Một cách khác là tạm tắt proxy để xem trang có chạy không. Nếu chạy khi tắt và lỗi khi bật, rồi trong tab mạng có kết nối WebTransport thất bại, đã tìm ra nguyên nhân.

Phía vận hành mạng

Nếu chặn UDP 443 ra ngoài để buộc mọi lưu lượng qua proxy, cần biết WebTransport và HTTP/3 sẽ không chạy. Trình duyệt tự rơi về HTTP/2 cho trang thường. Ứng dụng WebTransport không có dự phòng sẽ hỏng.

Phía người làm crawler

Crawler thường dùng thư viện HTTP, không chạy WebTransport. Khi cào trang dùng WebTransport cho dữ liệu thời gian thực, crawler dựa trên trình duyệt sẽ gặp đúng vấn đề như người dùng thường. Nếu trang có dự phòng WebSocket, trình duyệt sẽ tự chuyển và crawler vẫn lấy được dữ liệu qua proxy HTTP.

Nếu dữ liệu cần thiết chỉ đi qua WebTransport, cân nhắc lấy dữ liệu từ nguồn khác như API công khai của trang. Dựng hạ tầng proxy UDP chỉ cho một nguồn dữ liệu thường không đáng.

Giới hạn suy luận của bài

Lab chạy trên loopback với một trình duyệt dựa trên Chrome 152 và máy chủ aioquic, không có proxy giữa hai bên. Hành vi của trình duyệt khi có proxy HTTP, SOCKS5 UDP hay CONNECT-UDP chưa được thử. Bảng khả năng của từng loại proxy dựa theo đặc tả giao thức, không phải kết quả đo.

Ba datagram mất là quan sát một lần trên loopback. Tỷ lệ mất trên mạng thật sẽ khác.

Theo dõi khi đặc tả thay đổi

WebTransport còn đang phát triển. Đặc tả của W3C và các bản nháp của IETF cho HTTP/3 và HTTP/2 vẫn được cập nhật. Tên header như sec-webtransport-http3-draft thay đổi theo phiên bản bản nháp. Thư viện máy chủ và trình duyệt phải cùng hỗ trợ một phiên bản thì mới bắt tay được.

Khi nâng cấp trình duyệt hay thư viện máy chủ, chạy lại phép thử bốn lần kết nối như lab để chắc vẫn bắt tay được. Lỗi do lệch phiên bản bản nháp cũng hiện ra thành Opening handshake failed.

Checklist WebTransport và proxy

• Xác định proxy đang dùng có chuyển UDP hay không.
• Thử WebTransport ở mạng không proxy để có mốc.
• So với WebSocket trong cùng môi trường để tách lỗi UDP.
• Dùng công cụ log mạng của trình duyệt khi lỗi chỉ hiện Opening handshake failed.
• Kiểm chứng chỉ: ECDSA, thời hạn ngắn, mã băm đúng khi dùng serverCertificateHashes.
• Máy chủ kiểm header origin.
• Ứng dụng có đường dự phòng WebSocket.
• Không giả định proxy HTTP mang được WebTransport.

Với các việc chạy trên HTTP, HTTPS và WebSocket, proxy HTTP và SOCKS5 thông thường là đủ. ProxyVN có proxy dân cư tĩnh, datacenter, 4G và proxy xoay qua HTTP hoặc SOCKS5. Anh em có thể mua proxy giá rẻ tại trang chủ ProxyVN và hỏi trước nếu công việc cần chuyển tiếp UDP.

Câu hỏi thường gặp về WebTransport và proxy

WebTransport có thay WebSocket không?

Không thay hẳn. WebTransport thêm luồng song song và datagram, nhưng cần UDP. WebSocket vẫn cần làm dự phòng trong mạng chặn UDP hoặc có proxy HTTP.

Có thư viện Python làm client WebTransport không?

aioquic có thể làm client HTTP/3 và WebTransport, nhưng cần viết thêm mã. Với mục đích kiểm thử máy chủ, chạy trong trình duyệt như lab đơn giản hơn và phản ánh đúng người dùng thật.

Proxy HTTP có đọc được dữ liệu WebTransport không?

Không, vì dữ liệu không đi qua proxy HTTP. Nếu đi qua proxy hỗ trợ UDP, dữ liệu vẫn được mã hóa bởi QUIC, proxy không đọc được nội dung.

Firefox và Safari có hỗ trợ WebTransport không?

MDN theo dõi mức hỗ trợ theo trình duyệt và phiên bản. Kiểm bảng tương thích trên MDN trước khi dùng, vì mức hỗ trợ thay đổi theo bản phát hành.

Có cần cổng 443 không?

Không bắt buộc. Lab dùng cổng 9590. Nhưng trên Internet, nhiều mạng chỉ mở UDP 443 cho HTTP/3, nên máy chủ thật nên nghe ở 443 để tăng khả năng kết nối được.

Vì sao lab dùng 127.0.0.1 mà không dùng localhost?

Chứng chỉ có cả hai tên, nhưng localhost có thể phân giải ra ::1 trước. Máy chủ chỉ nghe IPv4, nên dùng thẳng địa chỉ để tránh phụ thuộc thứ tự phân giải.

WebTransport có lộ IP thật khi dùng proxy không?

Nếu trình duyệt đi thẳng bằng UDP khi có proxy HTTP, kết nối WebTransport sẽ dùng IP thật của máy, giống rò rỉ qua WebRTC. Bài WebRTC proxy là gì có cách kiểm rò IP qua UDP. Nên kiểm hành vi trình duyệt của mình trên một máy chủ thử trước khi giả định.

Datagram mất có cần gửi lại không?

Tùy ứng dụng. Nếu dữ liệu cần tới đủ, dùng stream. Datagram dành cho dữ liệu mà mất một vài gói không sao.

WebTransport và proxy và những điều cần nhớ

WebTransport và proxy không hợp nhau theo mặc định vì WebTransport chạy trên UDP còn proxy HTTP chỉ mang TCP. Lab thật trên Chrome 152 cho thấy kết nối thành công 54 ms, stream tới đủ, 17 trên 20 datagram quay về, và mọi lỗi bắt tay đều chung một thông báo. Có dự phòng WebSocket, kiểm UDP từng lớp. Cần proxy cho HTTP và WebSocket khi làm việc với WebTransport và proxy, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam.