UDP và QUIC qua proxy
Proxy có thể vượt qua kiểm tra web nhưng vẫn không mang được lưu lượng chương trình cần. Ví dụ, trò chơi đăng nhập được qua proxy nhưng không trao đổi được cập nhật trong trận. Website có thể mở bình thường trong khi trình duyệt dùng HTTP/2 thay vì HTTP/3. Những thao tác này cần khả năng mạng khác nhau.
Về lựa chọn giao thức rộng hơn, xem Proxy SOCKS và HTTP. Bài này giải thích cách UDP đến đích qua proxy, yêu cầu của QUIC với tuyến đó và cách kiểm tra ứng dụng dùng đúng phương thức truyền cùng IP đầu ra.
Vai trò của UDP, QUIC và HTTP/3
TCP giao luồng byte có thứ tự. Nếu mất dữ liệu, nó tổ chức truyền lại và giữ các byte sau khỏi ứng dụng đến khi lấp chỗ thiếu. UDP gửi thông điệp riêng, gọi là datagram. Bản thân UDP không đảm bảo giao đến, thứ tự hay chống trùng lặp; phần mềm dùng nó quyết định xử lý các tình huống.
Điều này cho ứng dụng chọn hành vi khác nhau. Ứng dụng thoại có thể bỏ gói âm thanh đến quá trễ để phát. Trò chơi có thể ưu tiên vị trí mới thay vì bản cũ. Trao đổi DNS có thể chỉ là câu hỏi và trả lời ngắn. Phương thức truyền thực tùy chương trình: ví dụ không có nghĩa mọi cuộc gọi, trò chơi hay yêu cầu DNS dùng UDP.
QUIC là giao thức truyền tải trên UDP. Nó thêm thiết lập kết nối, khôi phục dữ liệu mất, kiểm soát tắc nghẽn và luồng tin cậy. Tệp truyền qua luồng QUIC tin cậy có thể đến đầy đủ, đúng thứ tự. Gói đi trong datagram UDP không loại bỏ tính tin cậy mà QUIC cung cấp.
QUIC cũng cho nhiều luồng chung kết nối. Khi mất dữ liệu một luồng, các luồng khác có dữ liệu đã tới vẫn tiếp tục. Điều này có thể giảm chờ so với mang mọi luồng qua một kết nối TCP có thứ tự. Kết quả vẫn tùy tuyến, mất gói, máy chủ và máy khách; chỉ chọn QUIC không đảm bảo ứng dụng nhanh hơn.
HTTP/3 mang HTTP trên QUIC. HTTP/1.1 và HTTP/2 thường dùng TCP. Cả ba phục vụ được website HTTPS, nên https:// không xác định phiên bản HTTP hay xác nhận có dùng UDP.
Mã hóa là thuộc tính riêng. UDP không mã hóa dữ liệu. QUIC dùng TLS 1.3 để thiết lập bảo vệ lưu lượng ứng dụng. Ứng dụng UDP thường có thể dùng cơ chế bảo mật khác hoặc truyền nội dung không mã hóa; đưa qua proxy không tự thêm bảo vệ đó.
Cách SOCKS5 mang UDP
SOCKS5 định nghĩa bộ chuyển tiếp UDP: dịch vụ nhận datagram máy khách, gửi nội dung đến đích rồi trả phản hồi. Máy khách trước hết bố trí chuyển tiếp này qua TCP. Kết nối điều khiển và tuyến datagram tồn tại song song.
- Máy khách kết nối máy chủ SOCKS5 qua TCP và hoàn tất xác thực đã thỏa thuận.
- Nó yêu cầu
UDP ASSOCIATE. Nếu proxy chấp nhận, phản hồi cung cấp địa chỉ và cổng UDP bộ chuyển tiếp. - Máy khách gửi datagram đến bộ chuyển tiếp kèm tiêu đề SOCKS xác định đích. Bộ chuyển tiếp gỡ tiêu đề trước khi gửi nội dung tiếp. Với phản hồi, nó thêm tiêu đề SOCKS trước khi trả datagram về máy khách.
- Máy khách giữ kết nối điều khiển TCP mở trong khi dùng chuyển tiếp. Đóng nó kết thúc chuyển tiếp UDP đã bố trí qua kết nối. Mối gắn kết giữa điều khiển TCP và chuyển tiếp UDP gọi là liên kết UDP.
Bộ chuyển tiếp có thể dùng địa chỉ hoặc cổng khác điểm TCP nhập trong cài đặt proxy. Gửi UDP thuần đến điểm quen đó không thực hiện trao đổi SOCKS5. Máy khách chỉ triển khai CONNECT dùng SOCKS5 cho TCP được nhưng thiếu thủ tục cần ở đây. SOCKS4 không định nghĩa khả năng chuyển tiếp UDP này.
Điều đó giải thích thành công một phần thường gặp: tường lửa cho TCP và xác thực nhưng chặn datagram tới bộ chuyển tiếp đã thương lượng. Mật khẩu hoạt động, ứng dụng vẫn không nhận phản hồi UDP. Cả hai phần tuyến phải khả dụng.
Proxy HTTP có chuyển tiếp UDP được không?
Yêu cầu HTTP CONNECT thông thường yêu cầu proxy mở TCP tới đích và mang luồng byte. Nó không thiết lập chuyển tiếp UDP. TLS đến proxy HTTPS bảo vệ kết nối đó mà không đổi loại đường hầm yêu cầu.
HTTP có cơ chế đường hầm UDP bổ sung, thường gọi CONNECT-UDP, phát triển trong MASQUE. Với máy khách và máy chủ tương thích, máy khách yêu cầu đường hầm đến đích UDP. Proxy gửi datagram đến đích và mang phản hồi trở về. Cần hỗ trợ rõ ràng ở cả hai bên.
Trên kết nối máy khách–proxy, HTTP Datagrams có thể đi trong khung QUIC DATAGRAM khi có HTTP/3 và các phần mở rộng cần thiết. Chúng cũng có thể đi trong capsule: thông điệp có khung trong luồng HTTP tin cậy, gồm HTTP/2 trên TCP. Khi đó proxy vẫn gửi UDP đến đích dù đoạn đầu dùng TCP.
Lựa chọn ảnh hưởng thời gian. Nếu TCP mất dữ liệu, byte sau có thể chờ khôi phục, làm trễ datagram bên trong. Đường hầm có thể chạy nhưng không phù hợp tải thời gian thực cụ thể. Chỉ nhập địa chỉ proxy http:// trong chương trình không bật các cơ chế UDP bổ sung này.
Kết nối nào dùng QUIC?
Cụm “proxy QUIC” cần ngữ cảnh. Nó có thể mô tả cách đến proxy hoặc kết nối ứng dụng tới đích. Đây là hai phần trao đổi riêng.
| Nơi dùng QUIC | Proxy làm gì | Điều được xác nhận |
|---|---|---|
| Giữa máy khách và proxy | Nhận kết nối qua QUIC. Chẳng hạn, CONNECT thông thường qua HTTP/3 vẫn yêu cầu mở TCP tới đích. | Đường đến proxy dùng QUIC. Kết nối website cần kiểm tra riêng. |
| Giữa ứng dụng và đích, qua bộ chuyển tiếp UDP | Chuyển datagram mang gói QUIC của ứng dụng bằng chuyển tiếp UDP SOCKS5 hoặc đường hầm UDP HTTP phù hợp. | Ứng dụng có thể thiết lập QUIC tới đích nếu toàn tuyến hoạt động. Hai đầu cũng phải hỗ trợ và chọn HTTP/3. |
Với chuyển tiếp UDP thông thường, proxy không cần kết thúc kết nối QUIC của ứng dụng tại mình. Nó chuyển gói trong khi ứng dụng và đích vẫn là hai đầu trao đổi mã hóa. Proxy vẫn biết nơi gửi lưu lượng và quan sát được dung lượng, thời gian.
Vì sao hỗ trợ ứng dụng quan trọng
Chương trình cần triển khai cách chuyển tiếp dịch vụ cung cấp. Ô chọn SOCKS5 không cho biết có UDP ASSOCIATE không. Tương tự, chương trình có thể hỗ trợ HTTP/3 khi kết nối trực tiếp nhưng chỉ có kết nối proxy TCP.
Chrome là ví dụ cụ thể: SOCKS5 tích hợp chỉ đưa các yêu cầu URL dựa trên TCP qua proxy, không chuyển UDP qua SOCKS5. Tải trang bằng cấu hình đó không thể thử khả năng chuyển tiếp UDP của dịch vụ. Giới hạn thuộc riêng chế độ máy khách đó; máy khách khác hoặc phần mềm định tuyến ngoài có thể có khả năng khác.
Cũng kiểm tra phạm vi thiết lập. Đăng nhập, tải tệp, thoại và trò chơi có thể dùng thành phần mạng khác nhau trong cùng ứng dụng. Proxy đặt cho yêu cầu web có thể chỉ bao phủ một phần. Proxy hệ thống cũng tùy từng chương trình có tuân theo không.
Chương trình chuyển hướng lưu lượng ứng dụng khác có thể gửi UDP qua proxy nếu hỗ trợ UDP và cơ chế dịch vụ. Chỉ chuyển TCP không đủ. Nếu dùng giao diện mạng ảo, quy tắc định tuyến quyết định lưu lượng đi vào. Hãy thử đầy đủ tổ hợp: ứng dụng, chương trình định tuyến và điểm proxy.
Dự phòng, thất bại và kết nối trực tiếp
Khi tuyến cần thiết không khả dụng, kết quả tùy khả năng và chính sách ứng dụng. Ba kết quả có thể trông giống nhau nếu chỉ hỏi nội dung có mở không:
| Kết quả quan sát | Cách hiểu |
|---|---|
| Thao tác thất bại | Trao đổi cần thiết chưa hoàn tất. Xác định lỗi ở máy khách, thiết lập đường hầm, tuyến mạng hay đích. |
| Website mở bằng HTTP/2 hoặc HTTP/1.1 | Trao đổi website dùng phiên bản HTTP trên TCP. Truy cập web hoạt động nhưng không xác nhận HTTP/3 đến website. Đường đến proxy riêng có thể dùng phương thức truyền khác. |
| Trao đổi UDP thành công trực tiếp | Lưu lượng đi ngoài tuyến proxy dự kiến. Phải kiểm tra riêng địa chỉ đầu ra. |
Chuyển sang phiên bản HTTP trên TCP gọi là phương án dự phòng. Nó có thể duy trì duyệt web bình thường khi QUIC không khả dụng. Máy khách mở kết nối khác; bản thân QUIC không biến thành TCP. Vì vậy, tắt QUIC có thể giúp ứng dụng web dùng tuyến TCP sẵn có nhưng không cung cấp UDP cho tính năng bắt buộc cần nó.
Đi thẳng đến đích là quyết định định tuyến. UDP không được hỗ trợ không phải lúc nào cũng đi trực tiếp: phần mềm có thể dừng, thử cách truyền khác hoặc theo quy tắc bỏ qua. Nếu mọi lưu lượng tác vụ phải qua proxy, dùng chế độ dừng khi tuyến lỗi và kiểm tra hành vi khi proxy không khả dụng.
Vì sao UDP có thể ngừng sau khi thiết lập
Quy tắc cổng và tuyến trả về
Cổng TCP 443 và UDP 443 thuộc hai giao thức truyền khác nhau. Cho một không mở cái còn lại. Với SOCKS5, máy khách phải đến được điểm UDP chuyển tiếp trả về; bộ chuyển tiếp phải được phép đến cổng UDP đích. HTTP/3 có thể dùng cổng khác 443, nên kiểm tra điểm ứng dụng thực dùng.
Phản hồi phải qua bộ chuyển tiếp, tường lửa và NAT nếu có; NAT chuyển địa chỉ và thường cả cổng giữa mạng. Chỉ gửi datagram không chứng minh tuyến về chạy. Đổi mạng có thể đổi IP công cộng hoặc ánh xạ cổng máy khách. Bộ chuyển tiếp SOCKS5 phải từ chối datagram có IP nguồn khác IP lưu cho liên kết UDP đó, nên địa chỉ đổi có thể cần liên kết mới.
Khoảng nghỉ và trạng thái hết hạn
Bộ chuyển tiếp và NAT giữ bản ghi tạm cho trao đổi UDP. Chúng có thể hết hạn trong khoảng nghỉ. Cuộc gọi hoặc phiên có thể chạy ban đầu rồi mất tuyến UDP đến khi máy khách thiết lập lại. Giữ cùng IP đầu ra không tránh điều đó: trạng thái cần để chuyển tiếp UDP và cấp phát IP là hai việc riêng.
Kích thước datagram và MTU
MTU là gói IP lớn nhất liên kết mạng có thể mang mà không phân mảnh. Kích thước dùng được trên tuyến bị giới hạn bởi mức nhỏ nhất, gọi là MTU tuyến. Tiêu đề IP, UDP và đường hầm bổ sung đều chiếm chỗ. Tin nhắn thử nhỏ có thể qua trong khi datagram lớn bị loại, nên ứng dụng phải tính cả tuyến và tiêu đề thêm.
Tuyến QUIC phải mang ít nhất 1.200 byte nội dung UDP, chưa tính tiêu đề IP và UDP. Máy khách đệm datagram UDP chứa gói QUIC Initial đến ít nhất kích thước nội dung đó. Tiêu đề proxy ở đoạn máy khách–proxy cần thêm chỗ. Đây không phải khuyên đặt MTU giao diện thành 1.200: nó giải thích vì sao hỏi và trả lời DNS nhỏ chạy được nhưng bắt tay QUIC lớn hơn không qua.
Độ trễ, mất gói và tải
Với cuộc gọi hay trò chơi, thời điểm giao có thể quan trọng như giao được. Trễ biến động, mất gói và giới hạn tần suất gói có thể làm suy giảm đường chuyển tiếp UDP vốn đang chạy. Chỉ băng thông không mô tả các điều kiện. Proxy thêm một phần tuyến; nó có thể đổi hiệu năng theo cả hai hướng tùy mạng và tải.
Cách xác minh UDP và HTTP/3 qua proxy
Thử ứng dụng định dùng hoặc máy khách có cùng cơ chế chuyển tiếp. Phép thử hữu ích kiểm tra phản hồi, phương thức truyền và địa chỉ đầu ra cho cùng trao đổi.
- Chọn đích trả lời loại lưu lượng cần. Dùng máy chủ ứng dụng thật hoặc máy trả lời UDP do bạn kiểm soát. Với HTTP/3, chọn đích biết có hỗ trợ. Im lặng từ cổng UDP bất kỳ không cho biết phần nào lỗi.
- Xác nhận bộ chuyển tiếp hoặc đường hầm được chấp nhận. Với SOCKS5, xem kết quả
UDP ASSOCIATE, địa chỉ và cổng được trả. Với đường hầm UDP HTTP, xác nhận nó được nhận. Chỉ xác thực chưa bao gồm bước này. - Hoàn thành yêu cầu và phản hồi. Máy trả lời do bạn kiểm soát có thể trả mã yêu cầu và ghi IP nguồn đã thấy. Điều này kiểm tra đầu ra của trao đổi UDP đó. Phép kiểm tra IP web riêng chỉ bao phủ yêu cầu của nó.
- Với HTTP/3, xác nhận giao thức tại trao đổi với đích. Tìm HTTP/3 hoặc
h3trong nhật ký máy khách hoặc máy chủ cùng bằng chứng tuyến proxy. Nếu máy khách có chế độ chỉ HTTP/3, nó có thể lộ lỗi bị cơ chế dự phòng tự động che mất. - Lặp dưới điều kiện liên quan: kích thước datagram thực tế, lưu lượng duy trì và nghỉ rồi hoạt động lại. Nếu tác vụ cấm lưu lượng trực tiếp, thử cả lúc proxy không khả dụng. Lưu phiên bản máy khách và cài đặt cùng kết quả.
Bắt gói có thể giúp nhận diện tuyến. Chuyển tiếp UDP SOCKS5 tiêu chuẩn gửi datagram đến điểm đã thương lượng. Đường hầm UDP HTTP có thể dùng kết nối TCP ngoài, nên không thấy UDP ở đoạn đầu không đủ chứng minh lỗi.
DNS từ xa và ping thử các việc khác nhau. Proxy tra tên cho kết nối TCP được mà không chuyển UDP ứng dụng. ping thông thường dùng ICMP. Cả hai không thay thế yêu cầu và phản hồi UDP quan sát trên đúng tuyến proxy.
Khi nào đáng chọn hỗ trợ UDP
Bắt đầu từ lưu lượng tác vụ cần. Công việc website và API trên HTTP/1.1 hoặc HTTP/2 có thể được proxy chỉ TCP đáp ứng đầy đủ. Thử HTTP/3, truyền thông UDP và tính năng khác phụ thuộc UDP cần bộ chuyển tiếp hoặc đường hầm phù hợp cùng máy khách dùng được.
Hỏi dịch vụ cơ chế UDP và cấu hình máy khách được hỗ trợ. Sau đó kiểm tra đích và cổng được phép, giới hạn kích thước datagram, hành vi nhàn rỗi và giới hạn lưu lượng hoặc tần suất gói liên quan. Nếu TCP và UDP phải dùng cùng IP đầu ra hoặc vị trí, xác minh trong ứng dụng thật. Chung tài khoản hay kiểm tra web thành công không xác lập hành vi đầu ra giống nhau.