Java DatagramSocket ແລະ ການສົ່ງຕໍ່ UDP ຜ່ານ SOCKS5
ເຂົ້າໃຈວ່າເປັນຫຍັງ Java UDP socket ຈຶ່ງຕ້ອງການການຈັດຕັ້ງ SOCKS5 UDP ເຖິງແມ່ນວ່າການເຊື່ອມຕໍ່ TCP ໃຊ້ SOCKS ແລ້ວ.
ຄຳຮ້ອງ HTTP ຂອງ Java ເຮັດວຽກຜ່ານ SOCKS ແຕ່ຄຸນສົມບັດ UDP ຍັງສົ່ງທຣາຟິກໂດຍກົງ ຫຼື ລົ້ມເຫຼວ. ການຕັ້ງຄຸນສົມບັດ SOCKS ຂອງ JVM ບໍ່ໄດ້ໃຫ້ DatagramSocket ການຈັດຕັ້ງ SOCKS5 UDP.
API DatagramSocket ສົ່ງ ແລະ ຮັບ datagram ທີ່ກຳນົດທີ່ຢູ່ປາຍທາງເຄືອຂ່າຍ. ວິທີ connect() ຂອງມັນເລືອກຄູ່ຮ່ວມສຳລັບ socket ນັ້ນ. ມັນບໍ່ໄດ້ເຈລະຈາ SOCKS ກັບຄູ່ຮ່ວມ.
ເສັ້ນທາງ UDP ຜ່ານ SOCKS5 ຕ້ອງການວຽກເພີ່ມ
SOCKS5 ກຳນົດ ການເຊື່ອມຕໍ່ UDP ທີ່ສ້າງຂຶ້ນເທິງການເຊື່ອມຕໍ່ຄວບຄຸມ TCP. ຫຼັງຈາກນັ້ນ ລູກຄ້າແລກປ່ຽນ datagram ທີ່ຫໍ່ຫຸ້ມກັບທີ່ຢູ່ສົ່ງຕໍ່ທີ່ proxy ໃຫ້. ຂໍ້ຄວາມທີ່ຫໍ່ຫຸ້ມແຕ່ລະອັນລະບຸປາຍທາງຂອງມັນ. ການຈັດຕັ້ງລູກຄ້າຕ້ອງຈັດການການຫໍ່ຫຸ້ມນັ້ນ ແລະ ອາຍຸຂອງການເຊື່ອມຕໍ່ຄວບຄຸມ.
ການຊີ້ UDP socket ທຳມະດາໄປຫາພອດຮັບຟັງ TCP ຂອງ proxy ຂ້າມຂັ້ນຕອນເຫຼົ່ານັ້ນ. ການສົ່ງ datagram ດິບ ຂອງແອັບພລິເຄຊັນທ່ານໄປຫາທີ່ຢູ່ນັ້ນບໍ່ແມ່ນການທົດແທນການເຊື່ອມຕໍ່.
ເລືອກຫ້ອງສະໝຸດ ຫຼື ຄຸນສົມບັດແອັບພລິເຄຊັນທີ່ຮອງຮັບການສົ່ງຕໍ່ UDP ຜ່ານ SOCKS5 ຢ່າງຊັດເຈນ ແລະ ຢືນຢັນວ່າເຊີບເວີກໍຮອງຮັບມັນ. ຫ້ອງສະໝຸດທີ່ໂຄສະນາການຮອງຮັບ SOCKS ອາດຈັດຕັ້ງພຽງ TCP CONNECT. ຂໍ້ກຳນົດໂປຣໂຕຄອນແຍກຄຳສັ່ງເຫຼົ່ານັ້ນ.
ການສົ່ງຕໍ່ UDP ກໍຕ້ອງການເສັ້ນທາງທີ່ໃຊ້ໄດ້
ການເຊື່ອມຕໍ່ TCP ທີ່ສຳເລັດໄປຫາ proxy ສ້າງພຽງເສັ້ນທາງຄວບຄຸມ. ຝາໄຟ ຫຼື ພຶດຕິກຳ NAT ຍັງສາມາດລົບກວນ datagram ທີ່ສົ່ງໄປຫາການສົ່ງຕໍ່ໄດ້. ເກັບປາຍທາງການສົ່ງຕໍ່ທີ່ສົ່ງຄືນ ແລະ ຂໍ້ຜິດພາດການສົ່ງຕໍ່ໃດໆ ກ່ອນຈະສະຫຼຸບວ່າປາຍທາງຂອງແອັບພລິເຄຊັນອອບລາຍ.
ສຸດທ້າຍ, ການຮອງຮັບການຂົນສົ່ງ SOCKS ບໍ່ໄດ້ເພີ່ມການຮັບປະກັນການສົ່ງມອບໃຫ້ UDP. ເວລາຈຳກັດ, ການຈັດການການສູນເສຍ ແລະ ຂໍ້ຈຳກັດຂະໜາດຂໍ້ຄວາມຂອງແອັບພລິເຄຊັນທ່ານຍັງໃຊ້ຢູ່ຫຼັງຈາກເສັ້ນທາງປ່ຽນ.