ເປັນຫຍັງຄວາມລົ້ມເຫຼວຂອງ SockJS proxy ຈຶ່ງອາດປາກົດພຽງແຕ່ຫຼັງການສຳຮອງ

ເມື່ອ WebSocket ເຮັດວຽກຢູ່ໃນເຄືອຂ່າຍໜຶ່ງ ແຕ່ SockJS ລົ້ມເຫຼວຢູ່ໃນເຄືອຂ່າຍອື່ນ, ເຄືອຂ່າຍທີສອງອາດໄດ້ເປີດໃຊ້ການສຳຮອງ XHR. ສິ່ງນີ້ອາດປ່ຽນການຈັດຕັ້ງ HTTP ທີ່ເຮັດຄຳຂໍ — ແລະດັ່ງນັ້ນກໍປ່ຽນການຕັ້ງຄ່າ proxy ທີ່ໃຊ້.

ຊອກຫາ URL ທຳອິດທີ່ລົ້ມເຫຼວ ແລະການຂົນສົ່ງທີ່ມັນເລືອກ. SockJS ອາດສົ່ງຄຳຂໍຂໍ້ມູນ HTTP ກ່ອນເລືອກການຂົນສົ່ງ; ການຈັບມື WebSocket ແລະຄຳຂໍ polling ຕໍ່ໄປເປັນການດຳເນີນການແຍກກັນ. ການຕັ້ງຄ່າການຈັບມືທີ່ເຮັດວຽກບໍ່ໄດ້ພິສູດເສັ້ນທາງທີ່ໃຊ້ສຳລັບແຕ່ລະອັນ.

ໃນ Java client ຂອງ Spring, RestTemplateXhrTransport ຮັບ RestTemplate ທີ່ຕັ້ງຄ່າແລ້ວ. ໂຮງງານຄຳຂໍ ແລະ HTTP client ພື້ນຖານຂອງມັນໃຫ້ເສັ້ນທາງ proxy ແລະການພິສູດຢືນຢັນທີ່ການສຳຮອງຮອງຮັບ. ສຳລັບ Spring 6 ກັບ HttpClient 5, ຕັ້ງຄ່າໂຮງງານຄຳຂໍຕົວຈິງຂອງ RestTemplate ນັ້ນ. ຖ້າການຈັດຕັ້ງນັ້ນໃຊ້ອົງປະກອບ Apache HTTP, ລຸ້ນຂອງມັນຕ້ອງກົງກັບການເຊື່ອມໂຍງ.

WebSocket client ມີການຕັ້ງຄ່າການເຊື່ອມຕໍ່ທີ່ບັນທຶກໄວ້ເອງ. ຄຸນສົມບັດ proxy ຂອງ JVM ມີຜົນຕໍ່ເສັ້ນທາງພຽງແຕ່ເມື່ອ client ສະເພາະຂອງມັນອ່ານຄຸນສົມບັດເຫຼົ່ານັ້ນ. ປຽບທຽບສະພາບແວດລ້ອມທີ່ເຮັດວຽກ ແລະທີ່ລົ້ມເຫຼວ ຕາມການຂົນສົ່ງ, ການຈັດຕັ້ງ client, proxy ທີ່ເລືອກ ແລະຄວາມຜິດພາດທຳອິດ. ຖ້າພຽງແຕ່ XHR ລົ້ມເຫຼວ, ໃຫ້ຕິດຕາມເສັ້ນທາງ, ການພິສູດຢືນຢັນ ແລະການຕອບສະໜອງທີ່ຍືນຍາວຂອງມັນ ແທນທີ່ຈະປ່ຽນການຕັ້ງຄ່າຂອງ WebSocket client ທີ່ເຮັດວຽກຊ້ຳໆ.