IoT, ໝອກ ແລະ ເມກ: ມາລົມກັນກ່ຽວກັບເທັກໂນໂລຢີບໍ?

ການພັດທະນາຂອງເຕັກໂນໂລຢີໃນຂົງເຂດຊອບແວແລະຮາດແວ, ການປະກົດຕົວຂອງໂປໂຕຄອນການສື່ສານໃຫມ່ໄດ້ເຮັດໃຫ້ການຂະຫຍາຍຕົວຂອງອິນເຕີເນັດຂອງສິ່ງຕ່າງໆ (IoT). ຈໍາ​ນວນ​ຂອງ​ອຸ​ປະ​ກອນ​ແມ່ນ​ເພີ່ມ​ຂຶ້ນ​ແຕ່​ລະ​ມື້​ແລະ​ພວກ​ເຂົາ​ເຈົ້າ​ກໍາ​ລັງ​ສ້າງ​ຈໍາ​ນວນ​ຫຼາຍ​ຂອງ​ຂໍ້​ມູນ​. ດັ່ງນັ້ນ, ຈໍາເປັນຕ້ອງມີສະຖາປັດຕະຍະກໍາລະບົບທີ່ສະດວກທີ່ສາມາດປຸງແຕ່ງ, ເກັບຮັກສາແລະສົ່ງຂໍ້ມູນນີ້.

ດຽວນີ້ການບໍລິການຄລາວຖືກໃຊ້ເພື່ອຈຸດປະສົງເຫຼົ່ານີ້. ແນວໃດກໍ່ຕາມ, ຮູບແບບຄອມພິວເຕີ້ໝອກ (Fog) ທີ່ໄດ້ຮັບຄວາມນິຍົມເພີ່ມຂຶ້ນສາມາດເສີມສ້າງການແກ້ໄຂຄລາວໂດຍການປັບຂະໜາດ ແລະ ການເພີ່ມປະສິດທິພາບໂຄງສ້າງພື້ນຖານຂອງ IoT.

Clouds ສາມາດກວມເອົາການຮ້ອງຂໍ IoT ສ່ວນໃຫຍ່. ຕົວຢ່າງ, ເພື່ອສະຫນອງການຕິດຕາມການບໍລິການ, ການປຸງແຕ່ງໄວຂອງຂໍ້ມູນໃດໆທີ່ຜະລິດໂດຍອຸປະກອນ, ເຊັ່ນດຽວກັນກັບການເບິ່ງເຫັນຂອງພວກເຂົາ. ຄອມພິວເຕີ້ໝອກແມ່ນມີປະສິດທິພາບຫຼາຍຂຶ້ນເມື່ອແກ້ໄຂບັນຫາໃນເວລາຈິງ. ພວກເຂົາເຈົ້າສະຫນອງການຕອບສະຫນອງໄວຕໍ່ການຮ້ອງຂໍແລະການ latency ຫນ້ອຍໃນການປະມວນຜົນຂໍ້ມູນ. ນັ້ນແມ່ນ, Fog ເສີມ "ຟັງ" ແລະຂະຫຍາຍຄວາມສາມາດຂອງມັນ.

ຢ່າງໃດກໍຕາມ, ຄໍາຖາມຕົ້ນຕໍແມ່ນແຕກຕ່າງກັນ: ທັງຫມົດນີ້ຄວນຈະມີການພົວພັນກັນແນວໃດໃນສະພາບການຂອງ IoT? ໂປໂຕຄອນການສື່ສານອັນໃດຈະມີປະສິດທິພາບຫຼາຍທີ່ສຸດເມື່ອເຮັດວຽກຢູ່ໃນລະບົບ IoT-Fog-Cloud ປະສົມປະສານ?

ເຖິງວ່າຈະມີຄວາມເດັ່ນຊັດຂອງ HTTP, ມີວິທີແກ້ໄຂອື່ນໆຈໍານວນຫລາຍທີ່ໃຊ້ໃນລະບົບ IoT, Fog ແລະ Cloud. ນີ້ແມ່ນຍ້ອນວ່າ IoT ຕ້ອງສົມທົບການທໍາງານຂອງອຸປະກອນທີ່ຫຼາກຫຼາຍຂອງເຊັນເຊີກັບຄວາມປອດໄພ, ຄວາມເຂົ້າກັນໄດ້ແລະຄວາມຕ້ອງການອື່ນໆຂອງຜູ້ໃຊ້.

ແຕ່ບໍ່ມີຄວາມຄິດດຽວກ່ຽວກັບສະຖາປັດຕະຍະກໍາອ້າງອີງແລະມາດຕະຖານການສື່ສານ. ດັ່ງນັ້ນ, ການສ້າງໂປໂຕຄອນໃຫມ່ຫຼືປັບປຸງແກ້ໄຂທີ່ມີຢູ່ແລ້ວສໍາລັບວຽກງານ IoT ສະເພາະແມ່ນວຽກງານຫນຶ່ງທີ່ສໍາຄັນທີ່ສຸດທີ່ກໍາລັງປະເຊີນກັບຊຸມຊົນ IT.

ປະຈຸບັນມີໂປໂຕຄອນໃດແດ່ ແລະສິ່ງທີ່ເຂົາເຈົ້າສາມາດສະເໜີໃຫ້ໄດ້? ໃຫ້ຄິດອອກ. ແຕ່ທໍາອິດ, ໃຫ້ພິຈາລະນາຫຼັກການຂອງລະບົບນິເວດທີ່ຟັງ, ຫມອກແລະອິນເຕີເນັດຂອງສິ່ງຕ່າງໆມີການພົວພັນກັນ.

ສະຖາປັດຕະຍະກຳ IoT Fog-to-Cloud (F2C).

ທ່ານອາດຈະສັງເກດເຫັນວ່າມີຄວາມພະຍາຍາມຫຼາຍປານໃດໃນການຂຸດຄົ້ນຂໍ້ດີແລະຜົນປະໂຫຍດທີ່ກ່ຽວຂ້ອງກັບການຈັດການທີ່ສະຫລາດແລະການປະສານງານຂອງ IoT, cloud ແລະ fog. ຖ້າບໍ່ແມ່ນ, ນີ້ແມ່ນສາມຂໍ້ລິເລີ່ມສ້າງມາດຕະຖານ: ສະມາຄົມ OpenFog, Edge Computing Consortium и ໂຄງການ mF2C H2020 EU.

ຖ້າກ່ອນຫນ້ານີ້ພຽງແຕ່ 2 ລະດັບໄດ້ຖືກພິຈາລະນາ, ຟັງແລະອຸປະກອນສິ້ນສຸດ, ຫຼັງຈາກນັ້ນສະຖາປັດຕະຍະກໍາທີ່ສະເຫນີແນະນໍາລະດັບໃຫມ່ - fog computing . ໃນກໍລະນີນີ້, ລະດັບຫມອກສາມາດແບ່ງອອກເປັນຫຼາຍ sublevels, ອີງຕາມການສະເພາະຂອງຊັບພະຍາກອນຫຼືຊຸດນະໂຍບາຍທີ່ກໍານົດການນໍາໃຊ້ອຸປະກອນທີ່ແຕກຕ່າງກັນໃນ sublevels ເຫຼົ່ານີ້.

ສິ່ງທີ່ບໍ່ມີຕົວຕົນນີ້ອາດມີລັກສະນະແນວໃດ? ນີ້ແມ່ນລະບົບນິເວດ IoT-Fog-Cloud ປົກກະຕິ. ອຸປະກອນ IoT ສົ່ງຂໍ້ມູນໄປຫາເຊີບເວີທີ່ໄວຂຶ້ນ ແລະອຸປະກອນຄອມພິວເຕີເພື່ອແກ້ໄຂບັນຫາທີ່ຕ້ອງການການຕອບສະໜອງຕໍ່າ. ໃນລະບົບດຽວກັນ, ຟັງມີຄວາມຮັບຜິດຊອບໃນການແກ້ໄຂບັນຫາທີ່ຕ້ອງການຊັບພະຍາກອນຄອມພິວເຕີຫຼືພື້ນທີ່ເກັບຮັກສາຂໍ້ມູນຈໍານວນຫລາຍ.

ໂທລະສັບສະມາດໂຟນ, ໂມງອັດສະລິຍະ ແລະອຸປະກອນອື່ນໆສາມາດເປັນສ່ວນໜຶ່ງຂອງ IoT ໄດ້. ແຕ່ອຸປະກອນດັ່ງກ່າວ, ຕາມກົດລະບຽບ, ໃຊ້ໂປໂຕຄອນການສື່ສານທີ່ເປັນເຈົ້າຂອງຈາກຜູ້ພັດທະນາຂະຫນາດໃຫຍ່. ຂໍ້ມູນ IoT ທີ່ສ້າງຂຶ້ນຈະຖືກໂອນໄປໃສ່ຊັ້ນໝອກຜ່ານໂປຣໂຕຄໍ REST HTTP, ເຊິ່ງໃຫ້ຄວາມຍືດຫຍຸ່ນ ແລະການໂຕ້ຕອບກັນໃນເວລາສ້າງບໍລິການ RESTful. ນີ້ແມ່ນສິ່ງສໍາຄັນໃນແງ່ຂອງຄວາມຕ້ອງການເພື່ອຮັບປະກັນຄວາມເຂົ້າກັນໄດ້ກັບໂຄງສ້າງພື້ນຖານຄອມພິວເຕີ້ທີ່ມີຢູ່ແລ້ວທີ່ເຮັດວຽກຢູ່ໃນຄອມພິວເຕີທ້ອງຖິ່ນ, ເຄື່ອງແມ່ຂ່າຍຫຼືກຸ່ມເຄື່ອງແມ່ຂ່າຍ. ຊັບພະຍາກອນທ້ອງຖິ່ນ, ເອີ້ນວ່າ "fog nodes," ການກັ່ນຕອງຂໍ້ມູນທີ່ໄດ້ຮັບແລະປຸງແຕ່ງມັນຢູ່ໃນທ້ອງຖິ່ນຫຼືສົ່ງມັນໄປຫາຄລາວສໍາລັບການຄິດໄລ່ຕື່ມອີກ.

Clouds ສະຫນັບສະຫນູນໂປໂຕຄອນການສື່ສານທີ່ແຕກຕ່າງກັນ, ທົ່ວໄປທີ່ສຸດແມ່ນ AMQP ແລະ REST HTTP. ນັບຕັ້ງແຕ່ HTTP ເປັນທີ່ຮູ້ຈັກດີແລະເຫມາະສົມກັບອິນເຕີເນັດ, ຄໍາຖາມອາດຈະເກີດຂື້ນ: "ພວກເຮົາບໍ່ຄວນໃຊ້ມັນເພື່ອເຮັດວຽກກັບ IoT ແລະ fog?" ຢ່າງໃດກໍຕາມ, ອະນຸສັນຍານີ້ມີບັນຫາການປະຕິບັດ. ເພີ່ມເຕີມກ່ຽວກັບເລື່ອງນີ້ຕໍ່ມາ.

ໂດຍທົ່ວໄປ, ມີ 2 ແບບຂອງໂປໂຕຄອນການສື່ສານທີ່ເຫມາະສົມສໍາລັບລະບົບທີ່ພວກເຮົາຕ້ອງການ. ເຫຼົ່າ​ນີ້​ແມ່ນ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ຕອບ​ສະ​ຫນອງ​ແລະ​ເຜີຍ​ແຜ່​ການ​ສະ​ຫມັກ​. ຮູບແບບທໍາອິດແມ່ນເປັນທີ່ຮູ້ຈັກກັນຢ່າງກວ້າງຂວາງ, ໂດຍສະເພາະໃນສະຖາປັດຕະຍະກໍາ server-client. ລູກຄ້າຮ້ອງຂໍຂໍ້ມູນຈາກເຄື່ອງແມ່ຂ່າຍ, ແລະເຄື່ອງແມ່ຂ່າຍໄດ້ຮັບການຮ້ອງຂໍ, ດໍາເນີນການແລະສົ່ງຄືນຂໍ້ຄວາມຕອບສະຫນອງ. ໂປຣໂຕຄໍ REST HTTP ແລະ CoAP ເຮັດວຽກຢູ່ໃນຕົວແບບນີ້.

ຮູບແບບທີສອງເກີດຂື້ນຈາກຄວາມຕ້ອງການທີ່ຈະສະຫນອງ asynchronous, ແຈກຢາຍ, ການເຊື່ອມຕົວວ່າງລະຫວ່າງແຫຼ່ງສ້າງຂໍ້ມູນແລະຜູ້ຮັບຂໍ້ມູນນີ້.

ຮູບແບບສົມມຸດສາມຜູ້ເຂົ້າຮ່ວມ: ຜູ້ເຜີຍແຜ່ (ແຫຼ່ງຂໍ້ມູນ), ນາຍຫນ້າ (ຜູ້ຈັດສົ່ງ) ແລະຜູ້ຈອງ (ຜູ້ຮັບ). ທີ່ນີ້, ລູກຄ້າທີ່ເຮັດຫນ້າທີ່ເປັນຜູ້ຈອງບໍ່ຈໍາເປັນຕ້ອງຮ້ອງຂໍຂໍ້ມູນຈາກເຄື່ອງແມ່ຂ່າຍ. ແທນທີ່ຈະສົ່ງຄໍາຮ້ອງຂໍ, ມັນຈອງກັບເຫດການບາງຢ່າງໃນລະບົບຜ່ານນາຍຫນ້າ, ເຊິ່ງຮັບຜິດຊອບໃນການກັ່ນຕອງຂໍ້ຄວາມທີ່ເຂົ້າມາທັງຫມົດແລະຈັດເສັ້ນທາງລະຫວ່າງຜູ້ເຜີຍແຜ່ແລະຜູ້ຈອງ. ແລະຜູ້ເຜີຍແຜ່, ເມື່ອເຫດການເກີດຂື້ນກ່ຽວກັບຫົວຂໍ້ໃດຫນຶ່ງ, ເຜີຍແຜ່ມັນໃຫ້ກັບນາຍຫນ້າ, ເຊິ່ງສົ່ງຂໍ້ມູນໃນຫົວຂໍ້ທີ່ຮ້ອງຂໍໃຫ້ກັບຜູ້ຈອງ.

ໂດຍພື້ນຖານແລ້ວ, ສະຖາປັດຕະຍະກໍານີ້ແມ່ນອີງໃສ່ເຫດການ. ແລະຮູບແບບການໂຕ້ຕອບນີ້ແມ່ນຫນ້າສົນໃຈສໍາລັບຄໍາຮ້ອງສະຫມັກໃນ IoT, cloud, fog ເນື່ອງຈາກຄວາມສາມາດທີ່ຈະສະຫນອງການຂະຫຍາຍແລະງ່າຍດາຍຂອງການເຊື່ອມຕໍ່ລະຫວ່າງອຸປະກອນຕ່າງໆ, ສະຫນັບສະຫນູນການສື່ສານແບບເຄື່ອນໄຫວຫຼາຍຕໍ່ຫຼາຍແລະການສື່ສານ asynchronous. ບາງໂປຣໂຕຄອນການສົ່ງຂໍ້ຄວາມມາດຕະຖານທີ່ຮູ້ຈັກກັນດີທີ່ສຸດທີ່ໃຊ້ຮູບແບບການສະໝັກຮັບຂ່າວສານລວມມີ MQTT, AMQP, ແລະ DDS.

ແນ່ນອນ, ຮູບແບບການພິມເຜີຍແຜ່ມີຂໍ້ດີຫຼາຍ:

• ຜູ້ເຜີຍແຜ່ແລະຜູ້ຈອງບໍ່ຈໍາເປັນຕ້ອງຮູ້ກ່ຽວກັບການມີຢູ່ຂອງກັນແລະກັນ;
• ຜູ້ຈອງຫນຶ່ງສາມາດໄດ້ຮັບຂໍ້ມູນຈາກຫຼາຍສິ່ງພິມທີ່ແຕກຕ່າງກັນ, ແລະຜູ້ຈັດພິມຫນຶ່ງສາມາດສົ່ງຂໍ້ມູນໄປຫາຜູ້ຈອງທີ່ແຕກຕ່າງກັນຫຼາຍ (ຫຼັກການຫຼາຍຕໍ່ຫຼາຍ);
• ຜູ້ເຜີຍແຜ່ແລະຜູ້ຈອງບໍ່ຈໍາເປັນຕ້ອງມີການເຄື່ອນໄຫວໃນເວລາດຽວກັນເພື່ອຕິດຕໍ່ສື່ສານ, ເພາະວ່ານາຍຫນ້າ (ເຮັດວຽກເປັນລະບົບຄິວ) ຈະສາມາດເກັບຮັກສາຂໍ້ຄວາມສໍາລັບລູກຄ້າທີ່ບໍ່ໄດ້ເຊື່ອມຕໍ່ກັບເຄືອຂ່າຍໃນປະຈຸບັນ.

ຢ່າງໃດກໍຕາມ, ຮູບແບບການຕອບສະຫນອງຄໍາຮ້ອງຂໍຍັງມີຈຸດແຂງຂອງມັນ. ໃນກໍລະນີທີ່ຄວາມສາມາດຂອງຝ່າຍເຊີຟເວີໃນການຈັດການຄໍາຮ້ອງຂໍຂອງລູກຄ້າຫຼາຍບໍ່ແມ່ນບັນຫາ, ມັນເຮັດໃຫ້ຄວາມຮູ້ສຶກທີ່ຈະນໍາໃຊ້ການແກ້ໄຂທີ່ເຊື່ອຖືໄດ້, ພິສູດແລ້ວ.

ຍັງມີໂປໂຕຄອນທີ່ສະຫນັບສະຫນູນທັງສອງແບບ. ຕົວຢ່າງ, XMPP ແລະ HTTP 2.0, ເຊິ່ງສະຫນັບສະຫນູນທາງເລືອກ "server push". IETF ຍັງໄດ້ເປີດເຜີຍ CoAP. ໃນຄວາມພະຍາຍາມທີ່ຈະແກ້ໄຂບັນຫາການສົ່ງຂໍ້ຄວາມ, ວິທີແກ້ໄຂອື່ນໆຈໍານວນຫນຶ່ງໄດ້ຖືກສ້າງຂື້ນ, ເຊັ່ນ: ໂປໂຕຄອນ WebSockets ຫຼືການນໍາໃຊ້ໂປໂຕຄອນ HTTP ຜ່ານ QUIC (ການເຊື່ອມຕໍ່ອິນເຕີເນັດໄວ UDP).

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

ໃຜເປັນທີ່ຮັກທີ່ສຸດໃນໂລກ: ການປຽບທຽບໂປໂຕຄອນ

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

ເວລາຕອບສະ ໜອງ

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

ສໍາລັບຕົວຢ່າງ, ຜົນໄດ້ຮັບ ການປຽບທຽບປະສິດທິພາບຂອງ HTTP ແລະ MQTT ເມື່ອເຮັດວຽກກັບ IoT ສະແດງໃຫ້ເຫັນວ່າເວລາຕອບສະຫນອງສໍາລັບການຮ້ອງຂໍສໍາລັບ MQTT ແມ່ນຫນ້ອຍກວ່າ HTTP. ແລະເວລາໃດ ຮຽນ ເວລາເດີນທາງຮອບ (RTT) ຂອງ MQTT ແລະ CoAP ເປີດເຜີຍວ່າ RTT ສະເລ່ຍຂອງ CoAP ແມ່ນຫນ້ອຍກວ່າ MQTT 20%.

ອື່ນໆ ທົດລອງ ກັບ RTT ສໍາລັບ MQTT ແລະໂປໂຕຄອນ CoAP ໄດ້ຖືກປະຕິບັດໃນສອງສະຖານະການ: ເຄືອຂ່າຍທ້ອງຖິ່ນແລະເຄືອຂ່າຍ IoT. ມັນໄດ້ຫັນອອກວ່າ RTT ສະເລ່ຍແມ່ນສູງກວ່າ 2-3 ເທົ່າໃນເຄືອຂ່າຍ IoT. MQTT ກັບ QoS0 ສະແດງໃຫ້ເຫັນຜົນໄດ້ຮັບຕ່ໍາເມື່ອທຽບກັບ CoAP, ແລະ MQTT ກັບ QoS1 ສະແດງໃຫ້ເຫັນ RTT ສູງຂຶ້ນເນື່ອງຈາກ ACKs ຢູ່ໃນຄໍາຮ້ອງສະຫມັກແລະຊັ້ນການຂົນສົ່ງ. ສໍາລັບລະດັບ QoS ທີ່ແຕກຕ່າງກັນ, ຄວາມແຝງຂອງເຄືອຂ່າຍທີ່ບໍ່ມີຄວາມແອອັດແມ່ນ milliseconds ສໍາລັບ MQTT, ແລະຫຼາຍຮ້ອຍ microseconds ສໍາລັບ CoAP. ຢ່າງໃດກໍ່ຕາມ, ມັນເປັນມູນຄ່າທີ່ຈື່ໄວ້ວ່າເມື່ອເຮັດວຽກຢູ່ໃນເຄືອຂ່າຍທີ່ເຊື່ອຖືໄດ້ຫນ້ອຍ, MQTT ແລ່ນຢູ່ເທິງສຸດຂອງ TCP ຈະສະແດງໃຫ້ເຫັນຜົນໄດ້ຮັບທີ່ແຕກຕ່າງກັນຫມົດ.

ປຽບທຽບ ເວລາຕອບສະຫນອງສໍາລັບໂປໂຕຄອນ AMQP ແລະ MQTT ໂດຍການເພີ່ມ payload ສະແດງໃຫ້ເຫັນວ່າການໂຫຼດແສງສະຫວ່າງລະດັບ latency ແມ່ນເກືອບຄືກັນ. ແຕ່ເມື່ອໂອນຂໍ້ມູນຈໍານວນຫຼວງຫຼາຍ, MQTT ສະແດງໃຫ້ເຫັນເວລາຕອບສະຫນອງສັ້ນກວ່າ. ໃນອີກອັນນຶ່ງ ການຄົ້ນຄວ້າ CoAP ໄດ້ຖືກປຽບທຽບກັບ HTTP ໃນສະຖານະການການສື່ສານແບບເຄື່ອງຈັກກັບເຄື່ອງຈັກກັບອຸປະກອນທີ່ຖືກນໍາໃຊ້ຢູ່ເທິງຍານພາຫະນະທີ່ຕິດຕັ້ງແກັບແກັດ, ເຊັນເຊີສະພາບອາກາດ, ເຊັນເຊີສະຖານທີ່ (GPS) ແລະການໂຕ້ຕອບເຄືອຂ່າຍມືຖື (GPRS). ເວລາທີ່ຕ້ອງການເພື່ອສົ່ງຂໍ້ຄວາມ CoAP ຜ່ານເຄືອຂ່າຍມືຖືແມ່ນເກືອບສາມເທົ່າສັ້ນກວ່າເວລາທີ່ຕ້ອງການໃຊ້ຂໍ້ຄວາມ HTTP.

ການສຶກສາໄດ້ຖືກປະຕິບັດທີ່ປຽບທຽບບໍ່ແມ່ນສອງ, ແຕ່ສາມໂປໂຕຄອນ. ຍົກ​ຕົວ​ຢ່າງ, ການປຽບທຽບ ການປະຕິບັດຂອງ IoT protocols MQTT, DDS ແລະ CoAP ໃນສະຖານະການຄໍາຮ້ອງສະຫມັກທາງການແພດໂດຍໃຊ້ emulator ເຄືອຂ່າຍ. DDS ເຮັດວຽກໄດ້ດີກວ່າ MQTT ໃນແງ່ຂອງການແຝງ telemetry ທົດສອບພາຍໃຕ້ເງື່ອນໄຂເຄືອຂ່າຍທີ່ບໍ່ດີຫຼາຍຊະນິດ. CoAP ທີ່ອີງໃສ່ UDP ເຮັດວຽກໄດ້ດີສໍາລັບແອັບພລິເຄຊັນທີ່ຕ້ອງການເວລາຕອບສະຫນອງໄວ, ຢ່າງໃດກໍຕາມ, ເນື່ອງຈາກມັນເປັນ UDP, ມີການສູນເສຍແພັກເກັດທີ່ບໍ່ສາມາດຄາດເດົາໄດ້ຢ່າງຫຼວງຫຼາຍ.

ແບນວິດ

ປຽບທຽບ MQTT ແລະ CoAP ໃນແງ່ຂອງປະສິດທິພາບແບນວິດໄດ້ຖືກປະຕິບັດເປັນການຄິດໄລ່ຈໍານວນຂໍ້ມູນທັງຫມົດທີ່ສົ່ງຕໍ່ຂໍ້ຄວາມ. CoAP ໄດ້ສະແດງໃຫ້ເຫັນການສົ່ງຜ່ານຕ່ໍາກວ່າ MQTT ໃນເວລາທີ່ສົ່ງຂໍ້ຄວາມຂະຫນາດນ້ອຍ. ແຕ່ເມື່ອປຽບທຽບປະສິດທິພາບຂອງໂປໂຕຄອນໃນແງ່ຂອງອັດຕາສ່ວນຂອງຈໍານວນ bytes ຂໍ້ມູນທີ່ເປັນປະໂຫຍດກັບຈໍານວນ bytes ທັງຫມົດທີ່ຖືກໂອນ, CoAP ໄດ້ກາຍເປັນປະສິດທິພາບຫຼາຍ.

ທີ່ ການວິເຄາະ ການນໍາໃຊ້ MQTT, DDS (ກັບ TCP ເປັນໂປໂຕຄອນການຂົນສົ່ງ) ແລະ CoAP ແບນວິດ, ພົບວ່າໂດຍທົ່ວໄປແລ້ວ CoAP ສະແດງໃຫ້ເຫັນການບໍລິໂພກແບນວິດທີ່ຕ່ໍາກວ່າ, ເຊິ່ງບໍ່ໄດ້ເພີ່ມຂຶ້ນກັບການສູນເສຍແພັກເກັດເຄືອຂ່າຍເພີ່ມຂຶ້ນຫຼືຄວາມເລັ່ງເຄືອຂ່າຍເພີ່ມຂຶ້ນ, ບໍ່ເຫມືອນກັບ MQTT ແລະ DDS, ບ່ອນທີ່ມີ ການເພີ່ມຂຶ້ນຂອງການນໍາໃຊ້ແບນວິດໃນສະຖານະການທີ່ໄດ້ກ່າວມາ. ສະຖານະການອື່ນກ່ຽວຂ້ອງກັບອຸປະກອນຈໍານວນຫລາຍສົ່ງຂໍ້ມູນພ້ອມໆກັນ, ເຊິ່ງເປັນປົກກະຕິໃນສະພາບແວດລ້ອມ IoT. ຜົນໄດ້ຮັບສະແດງໃຫ້ເຫັນວ່າສໍາລັບການນໍາໃຊ້ທີ່ສູງຂຶ້ນ, ມັນດີກວ່າທີ່ຈະໃຊ້ CoAP.

ພາຍໃຕ້ການໂຫຼດເບົາ, CoAP ໃຊ້ແບນວິດຫນ້ອຍທີ່ສຸດ, ຕິດຕາມມາດ້ວຍ MQTT ແລະ REST HTTP. ຢ່າງໃດກໍຕາມ, ເມື່ອຂະຫນາດຂອງ payloads ເພີ່ມຂຶ້ນ, REST HTTP ມີຜົນໄດ້ຮັບທີ່ດີທີ່ສຸດ.

ການໃຊ້ພະລັງງານ

ບັນຫາການບໍລິໂພກພະລັງງານແມ່ນມີຄວາມສໍາຄັນຫຼາຍ, ແລະໂດຍສະເພາະໃນລະບົບ IoT. ຖ້າ ປຽບທຽບ ໃນຂະນະທີ່ MQTT ແລະ HTTP ບໍລິໂພກໄຟຟ້າ, HTTP ໃຊ້ຫຼາຍ. ແລະ CoAP ແມ່ນຫຼາຍກວ່າ ພະລັງງານປະສິດທິພາບ ເມື່ອທຽບກັບ MQTT, ອະນຸຍາດໃຫ້ການຄຸ້ມຄອງພະລັງງານ. ຢ່າງໃດກໍ່ຕາມ, ໃນສະຖານະການທີ່ງ່າຍດາຍ, MQTT ແມ່ນເຫມາະສົມສໍາລັບການແລກປ່ຽນຂໍ້ມູນໃນເຄືອຂ່າຍ Internet of Things, ໂດຍສະເພາະຖ້າບໍ່ມີຂໍ້ຈໍາກັດດ້ານພະລັງງານ.

ອື່ນໆ ການທົດລອງທີ່ປຽບທຽບຄວາມສາມາດຂອງ AMQP ແລະ MQTT ໃນການທົດສອບເຄືອຂ່າຍໄຮ້ສາຍແບບມືຖືຫຼືບໍ່ສະຖຽນພົບວ່າ AMQP ສະຫນອງຄວາມສາມາດດ້ານຄວາມປອດໄພຫຼາຍຂຶ້ນ ໃນຂະນະທີ່ MQTT ມີປະສິດທິພາບພະລັງງານຫຼາຍຂຶ້ນ.

ຄວາມປອດໄພ

ຄວາມ​ປອດ​ໄພ​ແມ່ນ​ອີກ​ບັນ​ຫາ​ທີ່​ສໍາ​ຄັນ​ທີ່​ຍົກ​ຂຶ້ນ​ມາ​ໃນ​ເວ​ລາ​ທີ່​ການ​ສຶກ​ສາ​ຫົວ​ຂໍ້​ຂອງ​ອິນ​ເຕີ​ເນັດ​ຂອງ​ສິ່ງ​ທີ່​ແລະ​ການ​ຄອມ​ພິວ​ເຕີ​ຫມອກ / cloud​. ໂດຍປົກກະຕິກົນໄກຄວາມປອດໄພແມ່ນອີງໃສ່ TLS ໃນ HTTP, MQTT, AMQP ແລະ XMPP, ຫຼື DTLS ໃນ CoAP, ແລະຮອງຮັບທັງສອງຕົວແປຂອງ DDS.

TLS ແລະ DTLS ເລີ່ມຕົ້ນດ້ວຍຂະບວນການສ້າງການສື່ສານລະຫວ່າງລູກຄ້າ ແລະຝ່າຍເຊີບເວີເພື່ອແລກປ່ຽນຊຸດລະຫັດລັບ ແລະກະແຈທີ່ຮອງຮັບ. ສອງ​ຝ່າຍ​ໄດ້​ດຳ​ເນີນ​ການ​ເຈລະຈາ​ກັນ​ເພື່ອ​ຮັບປະກັນ​ໃຫ້​ມີ​ການ​ສື່ສານ​ໃນ​ຊ່ອງ​ທາງ​ທີ່​ປອດ​ໄພ​ຕື່ມ​ອີກ. ຄວາມແຕກຕ່າງລະຫວ່າງສອງແມ່ນຢູ່ໃນການດັດແປງຂະຫນາດນ້ອຍທີ່ອະນຸຍາດໃຫ້ DTLS ທີ່ອີງໃສ່ UDP ເຮັດວຽກໃນໄລຍະການເຊື່ອມຕໍ່ທີ່ບໍ່ຫນ້າເຊື່ອຖື.

ທີ່ ການ​ທົດ​ສອບ​ການ​ໂຈມ​ຕີ​ ການປະຕິບັດທີ່ແຕກຕ່າງກັນຂອງ TLS ແລະ DTLS ພົບວ່າ TLS ເຮັດໄດ້ດີກວ່າ. ການໂຈມຕີ DTLS ປະສົບຜົນສໍາເລັດຫຼາຍຂຶ້ນເນື່ອງຈາກຄວາມທົນທານຕໍ່ຄວາມຜິດພາດຂອງມັນ.

ຢ່າງໃດກໍຕາມ, ບັນຫາໃຫຍ່ທີ່ສຸດກັບໂປໂຕຄອນເຫຼົ່ານີ້ແມ່ນວ່າພວກເຂົາບໍ່ໄດ້ຖືກອອກແບບມາໃນເບື້ອງຕົ້ນສໍາລັບການນໍາໃຊ້ໃນ IoT ແລະບໍ່ໄດ້ມີຈຸດປະສົງທີ່ຈະເຮັດວຽກຢູ່ໃນຫມອກຫຼືຟັງ. ໂດຍຜ່ານການຈັບມື, ພວກເຂົາເພີ່ມການຈະລາຈອນເພີ່ມເຕີມກັບແຕ່ລະສະຖານທີ່ເຊື່ອມຕໍ່, ເຊິ່ງເຮັດໃຫ້ຊັບພະຍາກອນຄອມພິວເຕີ້ຫຼຸດລົງ. ໂດຍສະເລ່ຍແລ້ວ, ມີການເພີ່ມຂຶ້ນ 6,5% ສໍາລັບ TLS ແລະ 11% ສໍາລັບ DTLS ໃນດ້ານເທິງທຽບກັບການສື່ສານທີ່ບໍ່ມີຊັ້ນຄວາມປອດໄພ. ໃນສະພາບແວດລ້ອມທີ່ອຸດົມສົມບູນຂອງຊັບພະຍາກອນ, ເຊິ່ງປົກກະຕິແລ້ວແມ່ນຕັ້ງຢູ່ ມີເມກ ລະດັບ, ນີ້ຈະບໍ່ເປັນບັນຫາ, ແຕ່ໃນການເຊື່ອມຕໍ່ລະຫວ່າງ IoT ແລະລະດັບ fog, ນີ້ກາຍເປັນຂໍ້ຈໍາກັດທີ່ສໍາຄັນ.

ສິ່ງທີ່ຈະເລືອກເອົາ? ບໍ່ມີຄໍາຕອບທີ່ຊັດເຈນ. MQTT ແລະ HTTP ເບິ່ງຄືວ່າເປັນໂປໂຕຄອນທີ່ໂດດເດັ່ນທີ່ສຸດຍ້ອນວ່າພວກມັນຖືກພິຈາລະນາປຽບທຽບກັບການແກ້ໄຂ IoT ທີ່ໃຫຍ່ກວ່າແລະມີຄວາມຫມັ້ນຄົງຫຼາຍເມື່ອທຽບກັບໂປໂຕຄອນອື່ນໆ.

ການ​ແກ້​ໄຂ​ໂດຍ​ອີງ​ໃສ່​ອະ​ນຸ​ສັນ​ຍາ​ການ​ສື່​ສານ​ເປັນ​ເອ​ກະ​ພາບ​

ການປະຕິບັດການແກ້ໄຂພິທີການດຽວມີຂໍ້ເສຍປຽບຫຼາຍ. ຕົວຢ່າງ, ໂປໂຕຄອນທີ່ເຫມາະສົມກັບສະພາບແວດລ້ອມທີ່ຖືກຈໍາກັດອາດຈະບໍ່ເຮັດວຽກຢູ່ໃນໂດເມນທີ່ມີຄວາມຕ້ອງການຄວາມປອດໄພທີ່ເຄັ່ງຄັດ. ດ້ວຍນີ້ຢູ່ໃນໃຈ, ພວກເຮົາຖືກປະຖິ້ມເກືອບທຸກວິທີແກ້ໄຂທີ່ອາດເປັນໄປໄດ້ດຽວໃນລະບົບນິເວດ Fog-to-Cloud ໃນ IoT, ຍົກເວັ້ນ MQTT ແລະ REST HTTP.

REST HTTP ເປັນການແກ້ໄຂໂປຣໂຕຄໍດຽວ

ມີຕົວຢ່າງທີ່ດີຂອງວິທີການຮ້ອງຂໍ REST HTTP ແລະການຕອບໂຕ້ໂຕ້ຕອບໃນພື້ນທີ່ IoT-to-Fog: ຟາມອັດສະລິຍະ. ສັດໄດ້ຖືກຕິດຕັ້ງດ້ວຍເຊັນເຊີທີ່ສວມໃສ່ໄດ້ (ລູກຄ້າ IoT, C) ແລະຄວບຄຸມໂດຍຜ່ານຄອມພິວເຕີ້ຟັງໂດຍລະບົບການກະສິກໍາອັດສະລິຍະ (Fog server, S).

ສ່ວນຫົວຂອງວິທີການ POST ລະບຸຊັບພະຍາກອນເພື່ອດັດແປງ (/farm/animals) ເຊັ່ນດຽວກັນກັບເວີຊັນ HTTP ແລະປະເພດເນື້ອຫາ, ເຊິ່ງໃນກໍລະນີນີ້ແມ່ນວັດຖຸ JSON ທີ່ເປັນຕົວແທນຂອງຟາມສັດທີ່ລະບົບຈະຈັດການ (Dulcinea/cow) . ການຕອບສະຫນອງຈາກເຄື່ອງແມ່ຂ່າຍຊີ້ໃຫ້ເຫັນວ່າຄໍາຮ້ອງຂໍປະສົບຜົນສໍາເລັດໂດຍການສົ່ງລະຫັດສະຖານະ HTTPS 201 (ຊັບພະຍາກອນທີ່ສ້າງ). ວິທີການ GET ຕ້ອງລະບຸພຽງແຕ່ຊັບພະຍາກອນທີ່ຮ້ອງຂໍໃນ URI (ຕົວຢ່າງ, /farm/animals/1), ເຊິ່ງສົ່ງຄືນການເປັນຕົວແທນ JSON ຂອງສັດທີ່ມີ ID ນັ້ນຈາກເຄື່ອງແມ່ຂ່າຍ.

ວິທີການ PUT ຖືກນໍາໃຊ້ໃນເວລາທີ່ບັນທຶກຊັບພະຍາກອນສະເພາະບາງຢ່າງຕ້ອງໄດ້ຮັບການປັບປຸງ. ໃນກໍລະນີນີ້, ຊັບພະຍາກອນກໍານົດ URI ສໍາລັບພາລາມິເຕີທີ່ຈະປ່ຽນແປງແລະມູນຄ່າປະຈຸບັນ (ຕົວຢ່າງ, ສະແດງໃຫ້ເຫັນວ່າງົວກໍາລັງຍ່າງຢູ່, /farm/animals/1? state=walking). ສຸດທ້າຍ, ວິທີການ DELETE ຖືກນໍາໃຊ້ເທົ່າທຽມກັນກັບວິທີການ GET, ແຕ່ພຽງແຕ່ລຶບຊັບພະຍາກອນທີ່ເປັນຜົນມາຈາກການດໍາເນີນງານ.

MQTT ເປັນການແກ້ໄຂໂປຣໂຕຄໍດຽວ

ໃຫ້ເອົາຟາມອັດສະລິຍະດຽວກັນ, ແຕ່ແທນທີ່ຈະ REST HTTP ພວກເຮົາໃຊ້ໂປໂຕຄອນ MQTT. ເຊີບເວີທ້ອງຖິ່ນທີ່ມີຫ້ອງສະໝຸດ Mosquitto ຕິດຕັ້ງເຮັດໜ້າທີ່ເປັນນາຍໜ້າ. ໃນຕົວຢ່າງນີ້, ຄອມພິວເຕີແບບງ່າຍໆ (ເອີ້ນວ່າເຄື່ອງແມ່ຂ່າຍກະສິກໍາ) Raspberry Pi ໃຫ້ບໍລິການລູກຄ້າ MQTT, ປະຕິບັດໂດຍຜ່ານການຕິດຕັ້ງຫ້ອງສະຫມຸດ Paho MQTT, ເຊິ່ງເຫມາະສົມກັບນາຍຫນ້າ Mosquitto.

ລູກຄ້ານີ້ສອດຄ່ອງກັບຊັ້ນ abstraction IoT ທີ່ເປັນຕົວແທນຂອງອຸປະກອນທີ່ມີຄວາມສາມາດໃນການຮັບຮູ້ແລະຄອມພິວເຕີ້. ໃນທາງກົງກັນຂ້າມ, ຜູ້ໄກ່ເກ່ຍກົງກັບລະດັບທີ່ສູງກວ່າຂອງ abstraction, ເປັນຕົວແທນຂອງ node ຄອມພິວເຕີ້ຫມອກທີ່ມີລັກສະນະໂດຍການປຸງແຕ່ງແລະການເກັບຮັກສາຫຼາຍກວ່າເກົ່າ.

ໃນສະຖານະການຟາມອັດສະລິຍະທີ່ສະເໜີ, Raspberry Pi ເຊື່ອມຕໍ່ກັບເຄື່ອງວັດແທກຄວາມໄວ, GPS, ແລະເຊັນເຊີອຸນຫະພູມ ແລະເຜີຍແຜ່ຂໍ້ມູນຈາກເຊັນເຊີເຫຼົ່ານີ້ໄປຫາຈຸດໝອກ. ດັ່ງທີ່ທ່ານອາດຈະຮູ້, MQTT ປະຕິບັດຫົວຂໍ້ຕ່າງໆເປັນລໍາດັບຊັ້ນ. ຜູ້ເຜີຍແຜ່ MQTT ດຽວສາມາດເຜີຍແຜ່ຂໍ້ຄວາມໄປຫາຫົວຂໍ້ສະເພາະ. ໃນກໍລະນີຂອງພວກເຮົາມີສາມຂອງພວກເຂົາ. ສໍາລັບເຊັນເຊີທີ່ວັດແທກອຸນຫະພູມໃນສວນສັດ, ລູກຄ້າເລືອກຮູບແບບ (ການລ້ຽງສັດ / ຕູ້ / ອຸນຫະພູມ). ສຳລັບເຊັນເຊີທີ່ວັດແທກສະຖານທີ່ GPS ແລະການເຄື່ອນໄຫວຂອງສັດຜ່ານເຄື່ອງວັດແທກຄວາມເລັ່ງ, ລູກຄ້າຈະເຜີຍແຜ່ການອັບເດດ (ສັດ/ສັດ/GPS) ແລະ (ສັດ/ສັດ/ການເຄື່ອນໄຫວ).

ຂໍ້ມູນນີ້ຈະຖືກສົ່ງກັບນາຍຫນ້າ, ຜູ້ທີ່ສາມາດເກັບຮັກສາມັນຊົ່ວຄາວໃນຖານຂໍ້ມູນທ້ອງຖິ່ນໃນກໍລະນີທີ່ຜູ້ສະຫມັກທີ່ສົນໃຈອື່ນມາຕາມພາຍຫຼັງ.

ນອກເຫນືອຈາກເຄື່ອງແມ່ຂ່າຍທ້ອງຖິ່ນ, ເຊິ່ງເຮັດຫນ້າທີ່ເປັນນາຍຫນ້າ MQTT ໃນຫມອກແລະທີ່ Raspberry Pis, ເຮັດຫນ້າທີ່ເປັນລູກຄ້າ MQTT, ສົ່ງຂໍ້ມູນເຊັນເຊີ, ອາດຈະມີນາຍຫນ້າ MQTT ອື່ນໃນລະດັບເມຄ. ໃນກໍລະນີນີ້, ຂໍ້ມູນທີ່ຖືກສົ່ງໄປຫານາຍຫນ້າທ້ອງຖິ່ນສາມາດຖືກເກັບໄວ້ຊົ່ວຄາວໃນຖານຂໍ້ມູນທ້ອງຖິ່ນແລະ / ຫຼືຖືກສົ່ງໄປຫາຄລາວ. ນາຍຫນ້າ MQTT fog ໃນສະຖານະການນີ້ຖືກນໍາໃຊ້ເພື່ອເຊື່ອມໂຍງຂໍ້ມູນທັງຫມົດກັບນາຍຫນ້າຟັງ MQTT. ດ້ວຍສະຖາປັດຕະຍະກໍານີ້, ຜູ້ໃຊ້ແອັບພລິເຄຊັນມືຖືສາມາດລົງທະບຽນກັບນາຍຫນ້າທັງສອງ.

ຖ້າການເຊື່ອມຕໍ່ກັບຫນຶ່ງຂອງນາຍຫນ້າ (ຕົວຢ່າງ, ຟັງ) ລົ້ມເຫລວ, ຜູ້ໃຊ້ສຸດທ້າຍຈະໄດ້ຮັບຂໍ້ມູນຈາກຄົນອື່ນ (fog). ນີ້​ແມ່ນ​ລັກ​ສະ​ນະ​ລັກ​ສະ​ນະ​ຂອງ fog ລວມ​ແລະ​ລະ​ບົບ​ຄອມ​ພິວ​ເຕີ​ຟັງ​. ໂດຍຄ່າເລີ່ມຕົ້ນ, ແອັບຯມືຖືສາມາດຖືກຕັ້ງຄ່າເພື່ອເຊື່ອມຕໍ່ກັບນາຍຫນ້າ MQTT fog ກ່ອນ, ແລະຖ້າສິ່ງນັ້ນລົ້ມເຫລວ, ເພື່ອເຊື່ອມຕໍ່ກັບ cloud MQTT broker. ການແກ້ໄຂນີ້ແມ່ນພຽງແຕ່ຫນຶ່ງໃນຈໍານວນຫຼາຍໃນລະບົບ IoT-F2C.

ການແກ້ໄຂຫຼາຍໂປໂຕຄອນ

ການແກ້ໄຂໂປໂຕຄອນດຽວແມ່ນເປັນທີ່ນິຍົມອັນເນື່ອງມາຈາກການປະຕິບັດທີ່ງ່າຍຂຶ້ນຂອງພວກເຂົາ. ແຕ່ວ່າມັນເປັນທີ່ຊັດເຈນວ່າໃນລະບົບ IoT-F2C ມັນເຮັດໃຫ້ຄວາມຮູ້ສຶກທີ່ຈະປະສົມປະສານໂປໂຕຄອນທີ່ແຕກຕ່າງກັນ. ແນວຄວາມຄິດແມ່ນວ່າໂປໂຕຄອນທີ່ແຕກຕ່າງກັນສາມາດດໍາເນີນການໃນລະດັບທີ່ແຕກຕ່າງກັນ. ສໍາລັບຕົວຢ່າງ, ສາມ abstractions: ຊັ້ນຂອງ IoT, fog ແລະຄອມພິວເຕີ້ຟັງ. ອຸປະກອນໃນລະດັບ IoT ໂດຍທົ່ວໄປຖືວ່າມີຈໍາກັດ. ສໍາລັບພາບລວມນີ້, ໃຫ້ພິຈາລະນາຊັ້ນ IoT ເປັນຂໍ້ຈໍາກັດທີ່ສຸດ, ຟັງການຈໍາກັດຫນ້ອຍທີ່ສຸດ, ແລະຄອມພິວເຕີ້ຫມອກເປັນ "ບາງບ່ອນໃນກາງ." ມັນປະກົດວ່າລະຫວ່າງ IoT ແລະການ abstractions fog, ການແກ້ໄຂໂປໂຕຄອນໃນປະຈຸບັນປະກອບມີ MQTT, CoAP ແລະ XMPP. ລະຫວ່າງຫມອກແລະເມຄ, ໃນທາງກົງກັນຂ້າມ, AMQP ແມ່ນຫນຶ່ງໃນໂປໂຕຄອນຕົ້ນຕໍທີ່ໃຊ້, ພ້ອມກັບ REST HTTP, ເຊິ່ງເນື່ອງຈາກຄວາມຍືດຫຍຸ່ນຂອງມັນຍັງຖືກນໍາໃຊ້ລະຫວ່າງຊັ້ນ IoT ແລະ fog.

ບັນຫາຕົ້ນຕໍຢູ່ທີ່ນີ້ແມ່ນການເຮັດວຽກຮ່ວມກັນຂອງໂປໂຕຄອນແລະຄວາມງ່າຍດາຍຂອງການໂອນຂໍ້ຄວາມຈາກໂປໂຕຄອນຫນຶ່ງໄປຫາອີກ. ໂດຍຫລັກການແລ້ວ, ໃນອະນາຄົດ, ສະຖາປັດຕະຍະກໍາຂອງລະບົບ Internet of Things ທີ່ມີຊັບພະຍາກອນຄລາວແລະຫມອກຈະເປັນເອກະລາດຂອງໂປໂຕຄອນການສື່ສານທີ່ນໍາໃຊ້ແລະຈະຮັບປະກັນການຕິດຕໍ່ພົວພັນທີ່ດີລະຫວ່າງໂປໂຕຄອນທີ່ແຕກຕ່າງກັນ.

ເນື່ອງຈາກວ່ານີ້ບໍ່ແມ່ນກໍລະນີ, ມັນເຮັດໃຫ້ຄວາມຮູ້ສຶກທີ່ຈະສົມທົບການອະນຸສັນຍາທີ່ບໍ່ມີຄວາມແຕກຕ່າງທີ່ສໍາຄັນ. ເພື່ອເຮັດສິ່ງນີ້, ຫນຶ່ງໃນການແກ້ໄຂທີ່ເປັນໄປໄດ້ແມ່ນອີງໃສ່ການປະສົມປະສານຂອງສອງໂປໂຕຄອນທີ່ປະຕິບັດຕາມແບບສະຖາປັດຕະຍະກໍາດຽວກັນ, REST HTTP ແລະ CoAP. ການແກ້ໄຂທີ່ສະເຫນີອີກອັນຫນຶ່ງແມ່ນອີງໃສ່ການລວມກັນຂອງສອງໂປໂຕຄອນທີ່ສະຫນອງການສື່ສານເຜີຍແຜ່ - ຈອງ, MQTT ແລະ AMQP. ການນໍາໃຊ້ແນວຄວາມຄິດທີ່ຄ້າຍຄືກັນ (ທັງ MQTT ແລະ AMQP ໃຊ້ນາຍຫນ້າ, CoAP ແລະ HTTP ໃຊ້ REST) ​​​​ເຮັດໃຫ້ການປະສົມປະສານເຫຼົ່ານີ້ງ່າຍຕໍ່ການປະຕິບັດແລະຮຽກຮ້ອງໃຫ້ມີຄວາມພະຍາຍາມການເຊື່ອມໂຍງຫນ້ອຍລົງ.

ຮູບ (a) ສະແດງສອງຕົວແບບການຕອບສະຫນອງຄໍາຮ້ອງຂໍ, HTTP ແລະ CoAP, ແລະການຈັດວາງທີ່ເປັນໄປໄດ້ຂອງພວກເຂົາໃນການແກ້ໄຂ IoT-F2C. ເນື່ອງຈາກ HTTP ແມ່ນຫນຶ່ງໃນບັນດາໂປໂຕຄອນທີ່ມີຊື່ສຽງທີ່ສຸດແລະຖືກຮັບຮອງເອົາໃນເຄືອຂ່າຍທີ່ທັນສະໄຫມ, ມັນຄົງຈະບໍ່ຖືກແທນທີ່ຢ່າງສົມບູນໂດຍໂປໂຕຄອນການສົ່ງຂໍ້ຄວາມອື່ນໆ. ໃນບັນດາຂໍ້ທີ່ເປັນຕົວແທນຂອງອຸປະກອນທີ່ມີປະສິດທິພາບທີ່ນັ່ງຢູ່ລະຫວ່າງເມຄແລະຫມອກ, REST HTTP ແມ່ນການແກ້ໄຂທີ່ສະຫຼາດ.

ໃນທາງກົງກັນຂ້າມ, ສໍາລັບອຸປະກອນທີ່ມີຊັບພະຍາກອນຄອມພິວເຕີ້ຈໍາກັດທີ່ຕິດຕໍ່ສື່ສານລະຫວ່າງຊັ້ນ Fog ແລະ IoT, ມັນມີປະສິດທິພາບຫຼາຍທີ່ຈະໃຊ້ CoAP. ຫນຶ່ງໃນຂໍ້ໄດ້ປຽບໃຫຍ່ຂອງ CoAP ແມ່ນຕົວຈິງແລ້ວຄວາມເຂົ້າກັນໄດ້ກັບ HTTP, ເນື່ອງຈາກວ່າທັງສອງໂປໂຕຄອນແມ່ນອີງໃສ່ຫຼັກການ REST.

ຮູບ (b) ສະແດງໃຫ້ເຫັນສອງຮູບແບບການສື່ສານ publish-subscribe ໃນສະຖານະການດຽວກັນ, ລວມທັງ MQTT ແລະ AMQP. ເຖິງແມ່ນວ່າທັງສອງໂປໂຕຄອນສາມາດສົມມຸດຕິຖານໄດ້ຖືກນໍາໃຊ້ສໍາລັບການສື່ສານລະຫວ່າງ nodes ໃນແຕ່ລະຊັ້ນ abstraction, ຕໍາແຫນ່ງຂອງເຂົາເຈົ້າຄວນຈະຖືກກໍານົດໂດຍອີງໃສ່ການປະຕິບັດ. MQTT ຖືກອອກແບບມາເປັນໂປໂຕຄອນທີ່ມີນ້ໍາຫນັກເບົາສໍາລັບອຸປະກອນທີ່ມີຊັບພະຍາກອນຄອມພິວເຕີ້ຈໍາກັດ, ດັ່ງນັ້ນມັນສາມາດຖືກນໍາໃຊ້ສໍາລັບການສື່ສານ IoT-Fog. AMQP ແມ່ນ ເໝາະ ສົມກວ່າ ສຳ ລັບອຸປະກອນທີ່ມີປະສິດທິພາບຫຼາຍ, ເຊິ່ງໂດຍສະເພາະຈະຈັດວາງມັນລະຫວ່າງໝອກແລະເມກ. ແທນທີ່ຈະເປັນ MQTT, ໂປໂຕຄອນ XMPP ສາມາດຖືກນໍາໃຊ້ໃນ IoT ຍ້ອນວ່າມັນຖືກຖືວ່າເປັນນ້ໍາຫນັກເບົາ. ແຕ່ມັນບໍ່ໄດ້ຖືກນໍາໃຊ້ຢ່າງກວ້າງຂວາງໃນສະຖານະການດັ່ງກ່າວ.

ການຄົ້ນພົບ

ມັນເປັນໄປບໍ່ໄດ້ວ່າຫນຶ່ງໃນໂປໂຕຄອນທີ່ສົນທະນາຈະພຽງພໍທີ່ຈະກວມເອົາການສື່ສານທັງຫມົດໃນລະບົບ, ຈາກອຸປະກອນທີ່ມີຊັບພະຍາກອນຄອມພິວເຕີ້ຈໍາກັດໄປຫາເຄື່ອງແມ່ຂ່າຍຟັງ. ການສຶກສາພົບວ່າສອງທາງເລືອກທີ່ໂດດເດັ່ນທີ່ນັກພັດທະນາໃຊ້ຫຼາຍທີ່ສຸດແມ່ນ MQTT ແລະ RESTful HTTP. ອະນຸສັນຍາທັງສອງນີ້ບໍ່ພຽງແຕ່ເປັນຜູ້ໃຫຍ່ ແລະ ໝັ້ນຄົງທີ່ສຸດເທົ່ານັ້ນ, ແຕ່ຍັງລວມເອົາການຈັດຕັ້ງປະຕິບັດຢ່າງມີເອກະສານ ແລະ ປະສົບຜົນສຳເລັດຫຼາຍຢ່າງ ແລະ ຊັບພະຍາກອນອອນໄລນ໌.

ເນື່ອງຈາກຄວາມຫມັ້ນຄົງແລະການຕັ້ງຄ່າທີ່ງ່າຍດາຍຂອງມັນ, MQTT ແມ່ນໂປໂຕຄອນທີ່ໄດ້ພິສູດປະສິດທິພາບທີ່ເຫນືອກວ່າຂອງມັນໃນໄລຍະເວລາເມື່ອນໍາໃຊ້ໃນລະດັບ IoT ກັບອຸປະກອນຈໍາກັດ. ໃນບາງສ່ວນຂອງລະບົບທີ່ຈໍາກັດການສື່ສານແລະການບໍລິໂພກແບດເຕີຣີບໍ່ແມ່ນບັນຫາ, ເຊັ່ນ: ບາງໂດເມນຫມອກແລະຄອມພິວເຕີ້ຟັງສ່ວນໃຫຍ່, RESTful HTTP ແມ່ນທາງເລືອກທີ່ງ່າຍ. CoAP ຄວນຖືກພິຈາລະນາຍ້ອນວ່າມັນຍັງພັດທະນາຢ່າງໄວວາເປັນມາດຕະຖານການສົ່ງຂໍ້ຄວາມ IoT ແລະມັນເປັນໄປໄດ້ວ່າມັນຈະບັນລຸລະດັບຄວາມຫມັ້ນຄົງແລະການເຕີບໂຕທີ່ຄ້າຍຄືກັບ MQTT ແລະ HTTP ໃນອະນາຄົດອັນໃກ້ນີ້. ແຕ່ມາດຕະຖານໃນປະຈຸບັນກໍາລັງພັດທະນາ, ເຊິ່ງມາພ້ອມກັບບັນຫາຄວາມເຂົ້າກັນໄດ້ໃນໄລຍະສັ້ນ.

ມີຫຍັງອີກແດ່ທີ່ທ່ານສາມາດອ່ານໃນ blog ໄດ້? Cloud4Y

→ ຄອມພິວເຕີຈະເຮັດໃຫ້ເຈົ້າແຊບ
→ AI ຊ່ວຍໃນການສຶກສາສັດຂອງອາຟຣິກາ
→ ລະດູຮ້ອນໃກ້ຈະໝົດແລ້ວ. ເກືອບບໍ່ມີຂໍ້ມູນທີ່ຮົ່ວໄຫຼໄວ້
→ 4 ວິ​ທີ​ທີ່​ຈະ​ຊ່ວຍ​ປະ​ຢັດ​ໃນ​ການ​ສໍາ​ຮອງ​ຂໍ້​ມູນ​ຟັງ​
→ ກ່ຽວກັບຊັບພະຍາກອນຂໍ້ມູນຂອງລັດຖະບານກາງທີ່ເປັນເອກະພາບທີ່ມີຂໍ້ມູນກ່ຽວກັບປະຊາກອນ

ຈອງຂອງພວກເຮົາ ໂທລະເລກ-channel, ເພື່ອບໍ່ໃຫ້ພາດບົດຄວາມຕໍ່ໄປ! ພວກເຮົາຂຽນບໍ່ເກີນສອງຄັ້ງຕໍ່ອາທິດແລະພຽງແຕ່ກ່ຽວກັບທຸລະກິດ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com