ຄຳຂໍ HTTP/3 ຕ້ອງການເສັ້ນທາງ proxy ທີ່ຮອງຮັບ UDP
ແຍກການຂົນສົ່ງ QUIC ຂອງ HTTP/3 ອອກຈາກ tunnel TCP ຂອງ HTTP CONNECT ທຳມະດາ ແລະ ຈາກການຮອງຮັບ UDP ທາງເລືອກຂອງບໍລິການ SOCKS5.
ລູກຄ້າທີ່ໄປຮອດ HTTPS ຜ່ານ proxy TCP ຢ່າງສຳເລັດ ຍັງບໍ່ໄດ້ສ້າງເສັ້ນທາງສຳລັບ HTTP/3. HTTP/3 ໃຊ້ QUIC, ແລະ QUIC ໃຊ້ UDP.
tunnel HTTP CONNECT ທຳມະດາໃຫ້ stream TCP ໄປຫາປາຍທາງ. ມັນບໍ່ປ່ຽນເປັນ relay UDP ເມື່ອ URL ເລີ່ມດ້ວຍ HTTPS ຫຼື ເມື່ອປາຍທາງຟັງຢູ່ port 443.
SOCKS5 ກໍຕ້ອງການເສັ້ນທາງ UDP
SOCKS5 ກຳນົດ ສະມາຄົມ UDP, ແຕ່ທັງລູກຄ້າ ແລະ ເຊີບເວີຕ້ອງຈັດຕັ້ງມັນ, ແລະ ຈຸດປາຍທາງຂອງ relay ຕ້ອງເຂົ້າເຖິງໄດ້. ຫ້ອງສະໝຸດທີ່ໃຫ້ພຽງ dialer TCP ຂອງ SOCKS ບໍ່ສາມາດໃຫ້ການຂົນສົ່ງ datagram ພຽງເພາະຊື່ຊະນິດຂອງມັນວ່າ SOCKS5.
ຄືກັນ, ອົງປະກອບຂອງເຄື່ອງມືທີ່ຊື່ proxy ອາດເປັນໂປຣແກຣມຈຳລອງການສູນເສຍແພັກເກັດສຳລັບການພັດທະນາ ບໍ່ແມ່ນລູກຄ້າ proxy ຊັ້ນເທິງທົ່ວໄປ. ກວດເບິ່ງສ່ວນຕິດຕໍ່ຕົວຈິງ ແລະ ການຂົນສົ່ງທີ່ຮອງຮັບ.
ມາດຕະຖານເຊັ່ນ CONNECT-UDP ກຳນົດວິທີອື່ນໃນການຂົນ UDP ຜ່ານລະບົບ proxy HTTP. ພວກມັນຕ້ອງການການຮອງຮັບທັງສອງດ້ານ ແລະ ບໍ່ຄວນສັບສົນກັບ CONNECT ແບບເດີມ.
ຖ້າລູກຄ້າ HTTP ຖອຍກັບໄປ HTTP/2 ຫຼື HTTP/1.1 ເທິງ TCP, ຄຳຂໍອາດສຳເລັດຜ່ານ proxy ທຳມະດາ ໂດຍບໍ່ໄດ້ໃຊ້ການເຊື່ອມຕໍ່ HTTP/3. ບັນທຶກໂປຣໂຕຄໍທີ່ເຈລະຈາ ເມື່ອຄວາມແຕກຕ່າງນັ້ນສຳຄັນ.
ດັ່ງນັ້ນຄຳຖາມຄວາມເຂົ້າກັນໄດ້ທີ່ມີປະໂຫຍດແມ່ນສະເພາະ: ລູກຄ້ານີ້ສາມາດຂົນ datagram QUIC ຂອງມັນຜ່ານ proxy ນີ້ ດ້ວຍກົນໄກທີ່ຮອງຮັບນີ້ໄດ້ບໍ່? ໜ້າເບຣົາວ໌ເຊີທີ່ໃຊ້ໄດ້ ຫຼື ການກວດ port TCP ຕອບຄຳຖາມທີ່ນ້ອຍກວ່າ.