ພອດພຣັອກຊີໜຶ່ງສາມາດຮັບ HTTP ແລະ SOCKS ໄດ້ຢ່າງໃດ

ຜູ້ຟັງພຣັອກຊີແບບປະສົມສາມາດຮັບ HTTP ແລະ SOCKS ເທິງພອດ TCP ດຽວ ເພາະເຊີບເວີກວດສອບໄບຕ໌ໂປຣໂຕຄອນເບື້ອງຕົ້ນ. ໝາຍເລກພອດບໍ່ໄດ້ເຮັດການກວດຫານັ້ນ.

ຄຳຮ້ອງພຣັອກຊີ HTTP ເລີ່ມດ້ວຍວິທີ HTTP ເຊັ່ນ GET ຫຼື CONNECT. ການທັກທາຍ SOCKS ເລີ່ມດ້ວຍຊ່ອງຂໍ້ມູນໂປຣໂຕຄອນແບບຖານສອງ. ຊອບແວທີ່ອອກແບບສຳລັບຂໍ້ມູນເຫຼົ່ານີ້ສາມາດສົ່ງການເຊື່ອມຕໍ່ໄປຫາຕົວຈັດການທີ່ເໝາະສົມ.

ນີ້ແມ່ນລັກສະນະການຈັດຕັ້ງທີ່ຊັດເຈນ. ຜູ້ຟັງ HTTP ທຳມະດາຂອງ Squid ບໍ່ກາຍເປັນແບບປະສົມເພາະພອດຂອງມັນຖືກປ່ຽນເປັນ 1080, ແລະ ຜູ້ຟັງ SOCKS ຢ່າງດຽວບໍ່ໄດ້ຮຽນຮູ້ HTTP ຈາກການຕັ້ງຄ່າບຣາວເຊີ.

TLS ເພີ່ມຂອບເຂດອີກອັນໜຶ່ງ: ການເຊື່ອມຕໍ່ພຣັອກຊີທີ່ເຂົ້າລະຫັດເລີ່ມດ້ວຍ TLS, ບໍ່ແມ່ນວິທີ HTTP ທີ່ເຫັນໄດ້. ການສະໜັບສະໜູນມັນເທິງຈຸດປາຍທາງດຽວກັນຕ້ອງການການຈັດການແບບຕັ້ງໃຈເພີ່ມເຕີມ; ການຮັບຮູ້ HTTP ແບບຂໍ້ຄວາມທຳມະດາ ແລະ SOCKS ບໍ່ໄດ້ຢືນຢັນຄວາມສາມາດນັ້ນ.

ໃຊ້ໂປຣໂຕຄອນລູກຄ້າທີ່ເອກະສານໄວ້ສຳລັບຈຸດປາຍທາງ. ຖ້າທັງສອງເຮັດວຽກ, ນັ້ນແມ່ນຫຼັກຖານກ່ຽວກັບຜູ້ຟັງແບບປະສົມຂອງເຊີບເວີນັ້ນ, ບໍ່ແມ່ນເຫດຜົນທີ່ຈະປະໂປຣໂຕຄອນໄວ້ບໍ່ລະບຸໃນທຸກລູກຄ້າ.

ຜູ້ຟັງແບບປະສົມຂອງ Glider ໃຫ້ຕົວຢ່າງທີ່ຊັດເຈນ: ມັນແນມເບິ່ງໄບຕ໌ໜຶ່ງໂດຍບໍ່ບໍລິໂພກມັນ, ສົ່ງ 0x05 ໄປຫາຕົວຈັດການ SOCKS5 ຂອງມັນ, ແລະ ຖ້າບໍ່ດັ່ງນັ້ນກໍເອີ້ນຕົວແຍກວິເຄາະ HTTP ຂອງມັນ. ຕົວແຍກວິເຄາະນັ້ນຍັງກວດສອບຄຳຮ້ອງທີ່ເຂົ້າມາ; ການເລືອກສົ່ງບໍ່ໄດ້ເຮັດໃຫ້ຂໍ້ມູນຕາມອຳເພີໃຈກາຍເປັນ HTTP ທີ່ຖືກຕ້ອງ.

ການແບ່ງປັນຜູ້ຟັງ TCP ບໍ່ໄດ້ໃຫ້ການເຊື່ອມໂຍງ UDP ຂອງ SOCKS5 ໂດຍຕົວມັນເອງ. Glider ເລີ່ມຜູ້ຟັງ UDP ຂອງມັນແຍກຕ່າງຫາກ. ການເລືອກໂປຣໂຕຄອນ TCP ແລະ ການສົ່ງຕໍ່ເດຕາກຣາມໃນພາຍຫຼັງແມ່ນຄວາມສາມາດແຍກກັນ.