WSS ຜ່ານ Squid ບໍ່ຄືກັບການອັບເກຣດ WebSocket ທຳມະດາ
ແຍກ WebSocket ທີ່ເຂົ້າລະຫັດພາຍໃນ CONNECT ອອກຈາກການຈັດການ HTTP Upgrade ແບບທຳມະດາໃນ forward proxy.
Squid ເຫັນຄຳຮ້ອງ HTTP Upgrade ຫຼື ເຫັນພຽງອຸໂມງທີ່ຂົນສົ່ງທຣາຟຟິກເຂົ້າລະຫັດ? ສິ່ງນີ້ກຳນົດວ່າການຄວບຄຸມ HTTP Upgrade ຂອງມັນແກ້ໄຂຄວາມຜິດພາດຫຼືບໍ່.
| ເສັ້ນທາງ proxy ແບບຊັດເຈນທຳມະດາ | ສິ່ງທີ່ Squid ພົບ |
|---|---|
wss:// | ໂດຍປົກກະຕິ CONNECT ແລ້ວຕາມດ້ວຍ TLS ປາຍທາງທີ່ຂົນສົ່ງການຈັບມື WebSocket |
ws:// | ຄຳຮ້ອງ HTTP Upgrade ແບບທຳມະດາ ທີ່ proxy ສາມາດປະມວນຜົນໄດ້ |
ການຄວບຄຸມການອັບເກຣດຂອງ Squid ກ່ຽວຂ້ອງກັບຄຳຮ້ອງທີ່ມັນປະມວນຜົນ. ມັນບໍ່ເປີດເຜີຍຫົວຂໍ້ HTTP ທີ່ເຂົ້າລະຫັດພາຍໃນອຸໂມງ WSS ແບບທຶບທຳມະດາ. ການດັກຈັບ TLS ຫຼື ການຈັດການ proxy ພິເສດອື່ນໆ ປ່ຽນການເບິ່ງເຫັນ ແລະ ອາດນຳເອົາຂໍ້ກຳນົດຄວາມເຂົ້າກັນຂອງຕົວມັນເອງ.
ສຳລັບ WSS, ຊອກຫາວ່າລຳດັບຢຸດຢູ່ໃສ: ການເຊື່ອມຕໍ່ກັບ proxy, CONNECT ທີ່ຮັບແລ້ວ, TLS ທີ່ກວດສອບແລ້ວ, ແລ້ວການຈັບມືຂອງແອັບພລິເຄຊັນ. ການປະຕິເສດກ່ອນ TLS ເປັນຄວາມຜິດພາດຄົນລະຢ່າງກັບຄຳຮ້ອງ Upgrade ທຳມະດາທີ່ຖືກປະຕິເສດ.
ຖ້າຕ້ອງການປ່ຽນນະໂຍບາຍການອັບເກຣດ, ໃຫ້ໃຊ້ຄຳສັ່ງສຳລັບເວີຊັນ Squid ທີ່ຕິດຕັ້ງ ແລະ ອະນຸຍາດພຶດຕິກຳທີ່ຕ້ອງການຢ່າງຈຳເພາະ. ການອະນຸຍາດທຸກໂປຣໂຕຄໍການອັບເກຣດ ຂະຫຍາຍນະໂຍບາຍເກີນກວ່າແອັບພລິເຄຊັນນັ້ນ.
ຄຳຮ້ອງໜ້າ HTTPS ທີ່ສຳເລັດພຽງແຕ່ສ້າງບາງສ່ວນຂອງເສັ້ນທາງ. ທຣາຟຟິກ WebSocket ອາຍຸຍືນຍາວຍັງອາດລົ້ມເຫຼວຍ້ອນຂໍ້ກຳນົດແອັບພລິເຄຊັນ, ອາຍຸການເຊື່ອມຕໍ່ ຫຼື ຂໍ້ຈຳກັດຂອງຕົວກາງ ແມ່ນແຕ່ຊື່ໂຮສຕ໌ດຽວກັນ.