WebSocket Ping ທຽບກັບ TCP Keepalive ຜ່ານ Proxy
ເລືອກການກວດສອບການມີຊີວິດສຳລັບ WebSocket peer ແທນການຖືວ່າ TCP socket ທີ່ຍັງມີຊີວິດເປັນຫຼັກຖານວ່າເສັ້ນທາງ application ຕອບສະໜອງ.
TCP socket ທີ່ຍັງມີຊີວິດ, WebSocket peer ທີ່ຕອບສະໜອງ, ແລະ ຄວາມຄືບໜ້າຂອງ application ທີ່ມີປະໂຫຍດ ແມ່ນການສັງເກດທີ່ແຕກຕ່າງກັນ:
| ຫຼັກຖານ | ສິ່ງທີ່ມັນຢືນຢັນ |
|---|---|
| ການມີຊີວິດຢູ່ລະດັບ TCP | ເສັ້ນທາງ transport ທີ່ຖືກກວດສອບຕອບສະໜອງໃນລະດັບນັ້ນ |
| WebSocket Pong ທີ່ກົງກັນ | peer ໄດ້ຕອບ control frame ນັ້ນ |
| ການຢືນຢັນຈາກ application | application ໄດ້ຢືນຢັນການດຳເນີນການພາຍໃຕ້ໂປຣໂຕຄອນຂອງມັນເອງ |
forward proxy ໂດຍປົກກະຕິຮັກສາການເຊື່ອມຕໍ່ແຍກຕ່າງຫາກສຳລັບຝັ່ງ client ແລະ ຝັ່ງ destination. TCP peer ຂອງ client ແມ່ນ proxy, ໃນຂະນະທີ່ Ping ພາຍໃນ tunnel ທີ່ສ້າງແລ້ວຈະເດີນທາງໄປຫາ WebSocket endpoint.
Pong ທີ່ກົງກັນ
ໂປຣໂຕຄອນກຳນົດໃຫ້ Pong ທີ່ຕອບກັບຕ້ອງມີ application data ຂອງ Ping. ໃຊ້ຄວາມສອດຄ່ອງນັ້ນເພື່ອລະບຸ probe ທີ່ຍັງຄ້າງຢູ່. Pong ທີ່ບໍ່ໄດ້ຮ້ອງຂໍແມ່ນອະນຸຍາດ ແຕ່ບໍ່ໄດ້ຮ້ອງຂໍການຢືນຢັນ; ການສົ່ງມັນຫຼັງຈາກຂໍ້ຄວາມຂໍ້ມູນແຕ່ລະຄັ້ງໃຫ້ຫຼັກຖານທີ່ແຕກຕ່າງກັນ.
ຄວນໃຊ້ກົນໄກ heartbeat ທີ່ library ຮອງຮັບ. JavaScript ໃນ browser ຕ້ອງການສັນຍາ heartbeat ຂອງ applicationແທນ. ເລືອກໄລຍະຫ່າງ ແລະ ເກນຄວາມລົ້ມເຫຼວໃຫ້ເໝາະກັບພາລະວຽກ ແລະ ນະໂຍບາຍເຄືອຂ່າຍ. ການຢຸດຊົ່ວຄາວຂອງການຈັດຕາຕະລາງ ຫຼື event loop ທີ່ໜັກເກີນໄປສາມາດພາດເກນທີ່ເຂັ້ມງວດ ໂດຍບໍ່ໄດ້ຢືນຢັນວ່າເຄືອຂ່າຍລົ້ມເຫຼວ.
ຮັກສາ receiver ໃຫ້ເຮັດວຽກ
client ຕ້ອງການ I/O ຢ່າງຕໍ່ເນື່ອງເພື່ອຮັບ ແລະ ປະມວນຜົນ control frame. ການຂັດຂວາງກົນໄກນັ້ນສາມາດເຮັດໃຫ້ການຂາດແຫຼ່ງຊັບພະຍາກອນພາຍໃນອຸປະກອນເບິ່ງຄືວ່າເປັນການຂາດການເຊື່ອມຕໍ່.
Ping ສ້າງການຈະລາຈອນໃນ tunnel, ແຕ່ແຕ່ລະ intermediary ເປັນຜູ້ຕັດສິນວ່າສິ່ງໃດຕອບສະໜອງນະໂຍບາຍ idle ຂອງຕົນ. ບໍ່ມີ heartbeat ໃດຮັບປະກັນການປົກປ້ອງຈາກຂີດຈຳກັດອາຍຸການເຊື່ອມຕໍ່ແບບສົມບູນ.
peer ສາມາດຕອບ Ping ໄດ້ ໃນຂະນະທີ່ application ຂອງມັນຢຸດຜະລິດຂໍ້ມູນອັບເດດ, ແລະ subscription ທີ່ງຽບສະຫງັດກໍ່ສາມາດມີສຸຂະພາບດີ. ຕິດຕາມ Pong ທີ່ຖືກຕ້ອງຄັ້ງຫຼ້າສຸດ ແລະ ເຫດການ application ທີ່ມີຄວາມໝາຍແຍກຈາກກັນເມື່ອທັງສອງມີຄວາມສຳຄັນ. ເມື່ອລົ້ມເຫຼວ, ໃຫ້ເກັບ route, ເວລາທີ່ຜ່ານໄປ ແລະ probe ທີ່ຄ້າງຢູ່, ແລ້ວປິດ ຫຼື ຟື້ນຟູຜ່ານ lifecycle ທີ່ຮອງຮັບ.