Програм хангамж, техник хангамжийн салбарт технологийн хөгжил, харилцааны шинэ протоколууд гарч ирснээр зүйлсийн интернет (IoT) өргөжин тэлэхэд хүргэсэн. Төхөөрөмжийн тоо өдрөөс өдөрт нэмэгдэж, асар их хэмжээний өгөгдөл үүсгэж байна. Тиймээс энэ өгөгдлийг боловсруулах, хадгалах, дамжуулах чадвартай, тохиромжтой системийн архитектур хэрэгтэй байна.
Одоо эдгээр зорилгоор үүлэн үйлчилгээг ашиглаж байна. Гэсэн хэдий ч улам бүр түгээмэл болж буй манан тооцооллын парадигм (Манан) нь IoT дэд бүтцийг өргөжүүлэх, оновчтой болгох замаар үүлний шийдлүүдийг нөхөж чадна.
Клоуд нь ихэнх IoT хүсэлтийг хангах чадвартай. Жишээлбэл, үйлчилгээнд хяналт тавих, төхөөрөмжүүдийн үүсгэсэн ямар ч хэмжээний өгөгдлийг хурдан боловсруулах, мөн тэдгээрийг дүрслэн харуулах. Бодит цагийн асуудлыг шийдвэрлэхэд манан тооцоолох нь илүү үр дүнтэй байдаг. Эдгээр нь хүсэлтэд хурдан хариу өгч, өгөгдөл боловсруулахад хамгийн бага хоцрогдолтой болгодог. Өөрөөр хэлбэл, Манан нь "үүл" -ийг нөхөж, чадавхийг нь өргөжүүлдэг.
Гэсэн хэдий ч гол асуулт бол IoT-ийн хүрээнд энэ бүхэн хэрхэн харилцан үйлчлэх ёстой вэ? IoT-Fog-Cloud хосолсон системд ажиллахад ямар харилцааны протоколууд хамгийн үр дүнтэй байх вэ?
HTTP нь илэрхий давамгайлж байгаа хэдий ч IoT, Fog болон Cloud системд ашигладаг бусад олон тооны шийдлүүд байдаг. Учир нь IoT нь төрөл бүрийн төхөөрөмжийн мэдрэгчийн функцийг аюулгүй байдал, нийцтэй байдал болон хэрэглэгчдийн бусад шаардлагуудтай хослуулах ёстой.
Гэхдээ лавлагааны архитектур, харилцааны стандартын талаар ганц санаа байдаггүй. Тиймээс IoT-ийн тодорхой ажлуудад зориулж шинэ протокол үүсгэх эсвэл одоо байгаа протоколыг өөрчлөх нь мэдээллийн технологийн нийгэмлэгийн өмнө тулгарч буй хамгийн чухал ажлуудын нэг юм.
Одоогоор ямар протоколууд ашиглагдаж байгаа бөгөөд тэд юу санал болгож чадах вэ? Үүнийг олж мэдье. Гэхдээ эхлээд үүл, манан, интернетийн харилцан үйлчлэлцдэг экосистемийн зарчмуудын талаар ярилцъя.
IoT Манан-Үүлэн (F2C) Архитектур
IoT, үүл, манангийн ухаалаг, зохицуулалттай менежменттэй холбоотой давуу болон үр өгөөжийг судлахын тулд хичнээн их хүчин чармайлт гаргаж байгааг та анзаарсан байх. Хэрэв тийм биш бол стандартчиллын гурван санаачилга энд байна: , и .
Хэрэв өмнө нь үүл ба төгсгөлийн төхөөрөмжийг зөвхөн 2 түвшинг авч үзсэн бол санал болгож буй архитектур нь манангийн тооцоолол гэсэн шинэ түвшинг нэвтрүүлж байна. Энэ тохиолдолд манангийн түвшинг нөөцийн онцлогоос хамааран хэд хэдэн дэд түвшинд хувааж болно, эсвэл эдгээр дэд түвшинд өөр өөр төхөөрөмжүүдийн хэрэглээг тодорхойлдог багц бодлого.
Энэ хийсвэрлэл ямар байж болох вэ? Энд ердийн IoT-Fog-Cloud экосистем байна. IoT төхөөрөмжүүд нь хоцролт бага шаарддаг асуудлуудыг шийдвэрлэхийн тулд илүү хурдан серверүүд болон тооцоолох төхөөрөмжүүд рүү өгөгдөл илгээдэг. Үүнтэй ижил системд үүл нь их хэмжээний тооцоолох нөөц эсвэл өгөгдөл хадгалах зай шаарддаг асуудлыг шийдвэрлэх үүрэгтэй.
Ухаалаг утас, ухаалаг цаг болон бусад хэрэгслүүд нь IoT-ийн нэг хэсэг байж болно. Гэхдээ ийм төхөөрөмжүүд нь дүрмээр бол томоохон хөгжүүлэгчдийн өмчлөлийн харилцааны протоколуудыг ашигладаг. Үүсгэсэн IoT өгөгдлийг REST HTTP протоколоор дамжуулан манангийн давхарга руу шилжүүлдэг бөгөөд энэ нь RESTful үйлчилгээг бий болгоход уян хатан байдал, харилцан ажиллах боломжийг олгодог. Орон нутгийн компьютер, сервер эсвэл серверийн кластер дээр ажиллаж байгаа одоо байгаа тооцоолох дэд бүтэцтэй хоцрогдсон нийцтэй байдлыг хангах хэрэгцээ шаардлагад энэ нь чухал юм. "Манан зангилаа" гэж нэрлэгддэг орон нутгийн нөөцүүд нь хүлээн авсан өгөгдлийг шүүж, дотооддоо боловсруулдаг эсвэл цаашдын тооцоололд зориулж үүлэн рүү илгээдэг.
Клоуд нь өөр өөр харилцааны протоколуудыг дэмждэг бөгөөд хамгийн түгээмэл нь AMQP болон REST HTTP юм. HTTP нь сайн мэддэг бөгөөд интернетэд зориулагдсан тул "бид үүнийг IoT болон манантай ажиллахад ашиглах ёсгүй гэж үү?" Гэсэн асуулт гарч ирж магадгүй юм. Гэсэн хэдий ч, энэ протокол нь гүйцэтгэлийн асуудалтай байдаг. Энэ талаар дараа дэлгэрэнгүй.
Ерөнхийдөө бидэнд хэрэгтэй системд тохирсон харилцааны протоколын 2 загвар байдаг. Эдгээр нь хүсэлт-хариу, нийтлэх-захиалга юм. Эхний загвар нь ялангуяа сервер-клиент архитектурт илүү алдартай. Үйлчлүүлэгч серверээс мэдээлэл авахыг хүсдэг бөгөөд сервер нь хүсэлтийг хүлээн авч, боловсруулж, хариу мессежийг буцаана. REST HTTP болон CoAP протоколууд энэ загвар дээр ажилладаг.
Хоёрдахь загвар нь өгөгдөл үүсгэгч эх сурвалж ба энэ өгөгдлийг хүлээн авагчдын хооронд асинхрон, тархсан, сул холболтыг хангах хэрэгцээ шаардлагаас үүдэлтэй юм.
Энэхүү загвар нь нийтлэгч (өгөгдлийн эх сурвалж), брокер (диспетчер) болон захиалагч (хүлээн авагч) гэсэн гурван оролцогчийг авч үздэг. Энд захиалагчийн үүрэг гүйцэтгэж байгаа үйлчлүүлэгч серверээс мэдээлэл авах шаардлагагүй. Хүсэлт илгээхийн оронд энэ нь ирж буй бүх мессежийг шүүж, хэвлэн нийтлэгчид болон захиалагчдын хооронд чиглүүлэх үүрэгтэй брокероор дамжуулан систем дэх тодорхой үйл явдлуудад бүртгүүлдэг. Мөн нийтлэгч нь тодорхой сэдэвтэй холбоотой үйл явдал тохиолдоход үүнийг брокерт нийтэлдэг бөгөөд энэ нь хүссэн сэдвийн талаархи мэдээллийг захиалагч руу илгээдэг.
Үндсэндээ энэ архитектур нь үйл явдалд суурилсан байдаг. Энэхүү харилцан үйлчлэлийн загвар нь IoT, үүл, манан зэрэг програмуудад сонирхолтой байдаг, учир нь түүний өргөтгөх чадварыг хангах, янз бүрийн төхөөрөмжүүдийн хоорондын холболтыг хялбаршуулах, динамик олон-олон харилцаа холбоо, асинхрон холбоог дэмждэг. Нийтлэх-захиалах загварыг ашигладаг хамгийн алдартай стандартчилагдсан мессежийн протоколуудын зарим нь MQTT, AMQP, DDS орно.
Мэдээжийн хэрэг, нийтлэх-захиалах загвар нь маш олон давуу талтай:
- Хэвлэн нийтлэгчид болон захиалагчид бие биенийхээ оршин тогтнох талаар мэдэх шаардлагагүй;
- Нэг захиалагч олон янзын хэвлэлээс мэдээлэл хүлээн авах боломжтой бөгөөд нэг нийтлэгч олон өөр захиалагчдад өгөгдөл илгээх боломжтой (олоноос олон зарчим);
- Нийтлэгч болон захиалагч хоорондоо харилцахын тулд нэгэн зэрэг идэвхтэй байх шаардлагагүй, учир нь брокер (дарааллын системээр ажилладаг) одоогоор сүлжээнд холбогдоогүй байгаа үйлчлүүлэгчдэд зориулсан мессежийг хадгалах боломжтой болно.
Гэсэн хэдий ч хүсэлт-хариу загвар нь давуу талтай. Серверийн тал олон үйлчлүүлэгчийн хүсэлтийг шийдвэрлэх чадвар нь асуудалгүй тохиолдолд батлагдсан, найдвартай шийдлүүдийг ашиглах нь зүйтэй юм.
Хоёр загварыг дэмждэг протоколууд бас байдаг. Жишээлбэл, "сервер түлхэх" сонголтыг дэмждэг XMPP болон HTTP 2.0. IETF мөн CoAP гаргасан. Мессежийн асуудлыг шийдэхийн тулд WebSockets протокол эсвэл QUIC (Quick UDP Internet Connections) дээр HTTP протокол ашиглах зэрэг хэд хэдэн шийдлийг бий болгосон.
WebSockets-ийн хувьд энэ нь серверээс вэб клиент рүү бодит цаг хугацаанд өгөгдөл дамжуулахад ашиглагддаг бөгөөд нэгэн зэрэг хоёр чиглэлтэй холболтоор байнгын холболтоор хангадаг боловч энэ нь хязгаарлагдмал тооцоолох нөөцтэй төхөөрөмжүүдэд зориулагдаагүй болно. Тээврийн шинэ протокол нь маш олон шинэ боломжийг олгодог тул QUIC нь анхаарал татахуйц байх ёстой. Гэвч QUIC нь стандартчилагдаагүй байгаа тул түүний хэрэглээ болон IoT шийдэлд үзүүлэх нөлөөллийг урьдчилан таамаглахад эрт байна. Тиймээс бид WebSockets болон QUIC-ийг ирээдүйгээ харж байгаа боловч одоохондоо үүнийг нарийвчлан судлахгүй.
Дэлхий дээрх хамгийн хөөрхөн нь хэн бэ: протоколуудыг харьцуулах
Одоо протоколын давуу болон сул талуудын талаар ярилцъя. Урагшаа хараад, тодорхой удирдагч байхгүй гэж нэн даруй тайлбар хийцгээе. Протокол бүр давуу болон сул талуудтай.
Хариу өгөх хугацаа
Харилцааны протоколуудын хамгийн чухал шинж чанаруудын нэг нь, ялангуяа интернетийн зүйлстэй холбоотой бол хариу өгөх хугацаа юм. Гэхдээ одоо байгаа протоколуудын дунд янз бүрийн нөхцөлд ажиллахдаа хоцрогдлын хамгийн бага түвшинг харуулсан тодорхой ялагч байдаггүй. Гэхдээ протоколын чадавхийг судлах, харьцуулах бүхэл бүтэн багц байдаг.
Жишээ нь, IoT-тэй ажиллахдаа HTTP ба MQTT-ийн үр нөлөөг харьцуулах нь MQTT-ийн хүсэлтэд хариу өгөх хугацаа HTTP-ээс бага байгааг харуулж байна. Тэгээд хэзээ MQTT болон CoAP-ийн эргэлтийн хугацаа (RTT) нь CoAP-ийн дундаж RTT нь MQTT-ээс 20%-иар бага байгааг харуулж байна.
Бусад MQTT болон CoAP протоколуудад зориулсан RTT-тэй ажиллах нь дотоод сүлжээ болон IoT сүлжээ гэсэн хоёр хувилбараар явагдсан. IoT сүлжээнд дундаж RTT нь 2-3 дахин их байдаг нь тогтоогдсон. QoS0-тай MQTT нь CoAP-тай харьцуулахад бага үр дүнг харуулсан ба QoS1-тэй MQTT нь хэрэглээний болон тээвэрлэлтийн давхарга дахь ACK-ийн улмаас өндөр RTT-ийг харуулсан. Өөр өөр QoS түвшний хувьд сүлжээний саатал нь MQTT-д миллисекунд, CoAP-д хэдэн зуун микросекунд байсан. Гэсэн хэдий ч найдвар багатай сүлжээн дээр ажиллах үед TCP дээр ажилладаг MQTT нь огт өөр үр дүнг харуулах болно гэдгийг санах нь зүйтэй.
Ачааллыг нэмэгдүүлэх замаар AMQP болон MQTT протоколуудад хариу өгөх хугацаа нь бага ачаалалтай үед хоцролтын түвшин бараг ижил байгааг харуулж байна. Гэхдээ их хэмжээний өгөгдөл дамжуулах үед MQTT нь илүү хурдан хариу үйлдэл үзүүлдэг. дахиад нэгд Хийн мэдрэгч, цаг агаарын мэдрэгч, байршил мэдрэгч (GPS) болон хөдөлгөөнт сүлжээний интерфейс (GPRS) -ээр тоноглогдсон тээврийн хэрэгслийн дээд талд суурилуулсан төхөөрөмжүүдтэй машин хоорондын харилцааны хувилбарт CoAP-ийг HTTP-тэй харьцуулсан. Мобайл сүлжээгээр CoAP мессежийг дамжуулахад шаардагдах хугацаа нь HTTP мессежийг ашиглахад шаардагдах хугацаанаас бараг гурав дахин богино байсан.
Хоёр биш гурван протоколыг харьцуулсан судалгаа хийсэн. Жишээлбэл, сүлжээний эмулятор ашиглан эмнэлгийн хэрэглээний хувилбарт IoT протоколуудын MQTT, DDS болон CoAP гүйцэтгэл. DDS нь янз бүрийн муу сүлжээний нөхцөлд туршсан телеметрийн хоцрогдлын хувьд MQTT-ээс давсан. UDP-д суурилсан CoAP нь хурдан хариу өгөх хугацаа шаардсан програмуудад сайн ажилладаг байсан ч UDP-д суурилсан учраас багцын алдагдал ихээхэн гарсан.
Зурвасын өргөн
Мессеж бүрээр дамжуулсан өгөгдлийн нийт хэмжээг тооцоолохдоо зурвасын өргөний үр ашгийн хувьд MQTT ба CoAP-ийг хийсэн. CoAP нь жижиг мессеж дамжуулах үед MQTT-ээс бага дамжуулах чадварыг харуулсан. Гэхдээ ашигтай мэдээллийн байтын тоог шилжүүлсэн нийт байттай харьцуулсан протоколын үр ашгийг харьцуулж үзэхэд CoAP илүү үр дүнтэй болсон.
үед MQTT, DDS (тээвэрлэлтийн протокол болгон TCP) болон CoAP зурвасын өргөнийг ашигласнаар CoAP нь ерөнхийдөө харьцангуй бага зурвасын өргөн зарцуулалтыг харуулсан бөгөөд энэ нь MQTT болон DDS-ээс ялгаатай нь сүлжээний багцын алдагдал ихсэх эсвэл сүлжээний хоцрогдол ихсэх үед нэмэгддэггүй. дурдсан хувилбаруудад зурвасын өргөн ашиглалтын өсөлт. Өөр нэг хувилбарт олон тооны төхөөрөмжүүд нэгэн зэрэг өгөгдөл дамжуулдаг байсан нь IoT орчинд ердийн зүйл юм. Үр дүн нь өндөр ашиглалтын хувьд CoAP ашиглах нь дээр гэдгийг харуулсан.
Хөнгөн ачааллын үед CoAP нь хамгийн бага зурвасын өргөнийг ашигласан бол дараа нь MQTT болон REST HTTP ашигладаг. Гэсэн хэдий ч ачааллын хэмжээ нэмэгдэхэд REST HTTP хамгийн сайн үр дүнд хүрсэн.
Цахилгаан зарцуулалт
Эрчим хүчний хэрэглээний асуудал үргэлж, ялангуяа IoT системд чухал ач холбогдолтой байдаг. Хэрэв MQTT болон HTTP нь цахилгаан зарцуулдаг бол HTTP нь илүү их эрчим хүч хэрэглэдэг. Мөн CoAP илүү их юм MQTT-тай харьцуулахад эрчим хүчний менежментийг зөвшөөрдөг. Гэсэн хэдий ч энгийн хувилбаруудад MQTT нь интернетийн зүйлсийн сүлжээнд мэдээлэл солилцоход илүү тохиромжтой, ялангуяа эрчим хүчний хязгаарлалт байхгүй тохиолдолд.
Хөдөлгөөнт эсвэл тогтворгүй утасгүй сүлжээний туршилтын тавцан дээрх AMQP болон MQTT-ийн чадавхийг харьцуулсан туршилт нь AMQP нь аюулгүй байдлын илүү боломжуудыг санал болгодог бол MQTT нь эрчим хүчний хэмнэлттэй байдаг.
Аюулгүй байдал
Аюулгүй байдал бол зүйлсийн интернет болон манан/үүл тооцооллын сэдвийг судлахад хөндөгдсөн өөр нэг чухал асуудал юм. Хамгаалалтын механизм нь ихэвчлэн HTTP, MQTT, AMQP болон XMPP дахь TLS эсвэл CoAP дахь DTLS дээр суурилдаг бөгөөд DDS хувилбаруудыг хоёуланг нь дэмждэг.
TLS болон DTLS нь дэмжигдсэн шифрийн багц болон түлхүүрүүдийг солилцохын тулд үйлчлүүлэгч болон серверийн талуудын хооронд харилцаа холбоо тогтоох үйл явцаас эхэлдэг. Хоёр тал цаашдын харилцаа холбоог найдвартай сувгаар явуулахын тулд багцуудыг хэлэлцдэг. Энэ хоёрын ялгаа нь UDP-д суурилсан DTLS-ийг найдваргүй холболтоор ажиллах боломжийг олгодог жижиг өөрчлөлтүүд юм.
үед TLS болон DTLS-ийн хэд хэдэн өөр хувилбарууд нь TLS илүү сайн ажилласан болохыг олж мэдсэн. DTLS-ийн халдлага нь алдааг тэсвэрлэх чадвартай тул илүү амжилттай болсон.
Гэсэн хэдий ч эдгээр протоколуудын хамгийн том асуудал бол тэдгээрийг IoT-д ашиглахаар төлөвлөөгүй бөгөөд манан эсвэл үүлэн дунд ажиллахад зориулагдаагүй явдал юм. Тэд гар барилцах замаар холболт бүрд нэмэлт урсгалыг нэмж, тооцоолох нөөцийг шавхдаг. Аюулгүй байдлын давхаргагүй харилцаа холбоотой харьцуулахад дундажаар TLS 6,5%, DTLS 11% нэмэгджээ. Ихэвчлэн дээр байрладаг нөөцөөр баялаг орчинд түвшин, энэ нь асуудал биш байх болно, гэхдээ IoT болон манангийн түвшин хоорондын холболтод энэ нь чухал хязгаарлалт болж байна.
Юу сонгох вэ? Тодорхой хариулт алга. MQTT болон HTTP нь бусад протоколуудтай харьцуулахад илүү боловсронгуй, тогтвортой IoT шийдэл гэж тооцогддог тул хамгийн ирээдүйтэй протоколууд юм.
Харилцааны нэгдсэн протоколд суурилсан шийдэл
Нэг протоколын шийдлийн практик нь олон сул талуудтай. Жишээлбэл, хязгаарлагдмал орчинд тохирсон протокол нь аюулгүй байдлын хатуу шаардлага бүхий домэйнд ажиллахгүй байж болно. Үүнийг харгалзан бид MQTT болон REST HTTP-ээс бусад IoT-ийн Манан-Үүлэн экосистемийн бараг бүх боломжит нэг протоколын шийдлүүдийг хаях хэрэгтэй.
REST HTTP нь нэг протоколын шийдэл юм
REST HTTP хүсэлт болон хариултууд IoT-to-Fog зайд хэрхэн харилцан үйлчилдэг сайн жишээ байна: . Эдгээр амьтдыг өмсөж болох мэдрэгчээр (IoT клиент, C) тоноглогдсон бөгөөд ухаалаг фермерийн системээр (Fog server, S) үүлэн тооцоололоор удирддаг.
POST аргын толгой хэсэг нь өөрчлөх нөөцийг (/ферм/амьтад) мөн HTTP хувилбар болон агуулгын төрлийг зааж өгдөг бөгөөд энэ тохиолдолд системийн удирдах ёстой амьтны фермийг (Dulcinea/cow) төлөөлөх JSON объект юм. . Серверийн хариулт нь HTTPS статусын код 201 (нөөц үүсгэсэн) илгээснээр хүсэлт амжилттай болсныг харуулж байна. GET арга нь серверээс тухайн ID-тай амьтны JSON дүрслэлийг буцаадаг URI-д зөвхөн хүссэн нөөцийг (жишээ нь, /ферм/амьтад/1) зааж өгөх ёстой.
Зарим нөөцийн бүртгэлийг шинэчлэх шаардлагатай үед PUT аргыг ашигладаг. Энэ тохиолдолд нөөц нь өөрчлөх гэж буй параметрийн URI болон одоогийн утгыг (жишээ нь, үнээ яг одоо алхаж байна, /ферм/амьтад/1? төлөв=алхаж байна) зааж өгнө. Эцэст нь DELETE аргыг GET аргатай адилхан ашигладаг боловч үйл ажиллагааны үр дүнд нөөцийг устгадаг.
MQTT нь нэг протоколын шийдэл юм
Ижил ухаалаг фермийг авч үзье, гэхдээ REST HTTP-ийн оронд бид MQTT протоколыг ашигладаг. Mosquitto номын сан суулгасан локал сервер нь брокерын үүргийг гүйцэтгэдэг. Энэ жишээнд Raspberry Pi нь энгийн компьютер (фермийн сервер гэж нэрлэдэг) нь Mosquitto брокерт бүрэн нийцдэг Paho MQTT номын сангийн суулгацаар хэрэгжсэн MQTT үйлчлүүлэгчийн үүрэг гүйцэтгэдэг.
Энэ үйлчлүүлэгч нь мэдрэгч, тооцоолох чадвартай төхөөрөмжийг төлөөлөх IoT хийсвэрлэлийн давхаргатай тохирч байна. Нөгөө талаас зуучлагч нь хийсвэрлэлийн өндөр түвшинд тохирч, илүү их боловсруулах, хадгалах хүчин чадалтай манан тооцооллын зангилааг төлөөлдөг.
Санал болгож буй ухаалаг фермийн хувилбарт Raspberry Pi нь акселерометр, GPS, температур мэдрэгчтэй холбогдож, эдгээр мэдрэгчээс авсан өгөгдлийг манангийн зангилаа руу нийтэлдэг. MQTT сэдвүүдийг шаталсан байдлаар авч үздэгийг та мэдэх байх. Ганц MQTT нийтлэгч нь тодорхой сэдвүүдэд мессеж нийтлэх боломжтой. Манай тохиолдолд эдгээрийн гурав нь байдаг. Амьтны хашаан дахь температурыг хэмждэг мэдрэгчийн хувьд үйлчлүүлэгч сэдэв (амьтны ферм/амбаар/температур) сонгоно. Акселерометрээр дамжуулан GPS-ийн байршил, амьтны хөдөлгөөнийг хэмждэг мэдрэгчийн хувьд үйлчлүүлэгч (амьтны ферм/амьтан/GPS) болон (амьтны ферм/амьтан/хөдөлгөөн) шинэчлэлтүүдийг нийтлэх болно.
Энэ мэдээллийг зуучлагч руу шилжүүлэх бөгөөд дараа нь өөр сонирхож буй захиалагч ирэх тохиолдолд локал мэдээллийн санд түр хадгалах боломжтой.
Манан дунд MQTT брокерын үүрэг гүйцэтгэдэг, Raspberry Pis нь MQTT үйлчлүүлэгчийн үүрэг гүйцэтгэдэг мэдрэгчийн өгөгдлийг илгээдэг локал серверээс гадна үүл түвшинд өөр MQTT брокер байж магадгүй юм. Энэ тохиолдолд орон нутгийн брокер руу дамжуулсан мэдээллийг локал мэдээллийн санд түр хугацаагаар хадгалах ба/эсвэл үүлэн рүү илгээх боломжтой. Энэ нөхцөлд манан MQTT брокер нь бүх өгөгдлийг үүлэн MQTT брокертой холбоход ашиглагддаг. Энэхүү архитектурын тусламжтайгаар гар утасны програмын хэрэглэгч хоёр брокерт бүртгүүлж болно.
Хэрэв брокеруудын аль нэгэнд (жишээлбэл, үүл) холболт амжилтгүй болвол эцсийн хэрэглэгч нөгөөгөөсөө мэдээлэл хүлээн авах болно (манан). Энэ нь манан ба үүлэн тооцооллын хосолсон системийн онцлог шинж юм. Анхдагч байдлаар, мобайл програмыг эхлээд манан MQTT брокерт холбох, хэрэв амжилтгүй болвол үүлэн MQTT брокерт холбогдохоор тохируулж болно. Энэхүү шийдэл нь IoT-F2C системүүдийн олон хувилбарын зөвхөн нэг нь юм.
Олон протоколын шийдэл
Нэг протоколын шийдлүүд нь хэрэгжүүлэхэд хялбар тул түгээмэл байдаг. Гэхдээ IoT-F2C системд өөр өөр протоколуудыг нэгтгэх нь ойлгомжтой. Өөр өөр протоколууд өөр өөр түвшинд ажиллах боломжтой гэсэн санаа юм. Жишээлбэл, IoT, манан ба үүлэн тооцоолол гэсэн гурван хийсвэрлэлийг авч үзье. IoT түвшний төхөөрөмжүүд ерөнхийдөө хязгаарлагдмал гэж тооцогддог. Энэхүү тоймыг үзэхийн тулд IoT шатлалыг хамгийн хязгаарлагдмал, үүл нь хамгийн бага хязгаарлалттай, манантай тооцоололыг "дунд хаа нэгтээ" гэж авч үзье. IoT болон манангийн хийсвэрлэлийн хооронд одоогийн протоколын шийдэлд MQTT, CoAP болон XMPP багтдаг болох нь харагдаж байна. Нөгөө талаас манан ба үүлний хооронд AMQP нь REST HTTP-ийн хамт хэрэглэгддэг гол протоколуудын нэг бөгөөд уян хатан байдлаасаа шалтгаалан IoT болон манангийн давхаргын хооронд ашиглагддаг.
Энд гол асуудал бол протоколуудын харилцан ажиллах чадвар, мессежийг нэг протоколоос нөгөө протокол руу дамжуулахад хялбар байдал юм. Ирээдүйд үүлэн болон манан нөөц бүхий зүйлсийн интернетийн системийн архитектур нь ашигласан харилцааны протоколоос хамааралгүй байх бөгөөд өөр өөр протоколуудын хооронд сайн уялдаа холбоотой байх болно.
Энэ нь одоогоор тийм биш байгаа тул мэдэгдэхүйц ялгаагүй протоколуудыг нэгтгэх нь зүйтэй юм. Үүний тулд нэг боломжит шийдэл нь REST HTTP болон CoAP гэсэн ижил архитектурын хэв маягийг дагаж мөрддөг хоёр протоколын хослол дээр суурилдаг. Санал болгож буй өөр нэг шийдэл нь MQTT болон AMQP гэсэн нийтлэх-захиалах харилцааг санал болгодог хоёр протоколын хослол дээр суурилдаг. Ижил төстэй ойлголтуудыг ашиглах нь (MQTT ба AMQP хоёулаа брокер ашигладаг, CoAP болон HTTP нь REST ашигладаг) эдгээр хослолыг хэрэгжүүлэхэд хялбар болгож, нэгтгэх хүчин чармайлт бага шаарддаг.
Зураг (а) нь хүсэлтийн хариуд суурилсан HTTP болон CoAP гэсэн хоёр загвар болон тэдгээрийг IoT-F2C шийдэлд байршуулах боломжтойг харуулж байна. HTTP нь орчин үеийн сүлжээн дэх хамгийн алдартай, батлагдсан протоколуудын нэг тул түүнийг бусад мессежийн протоколоор бүрэн солих магадлал багатай юм. Үүл ба манангийн хооронд байрладаг хүчирхэг төхөөрөмжүүдийг төлөөлдөг зангилааны дунд REST HTTP нь ухаалаг шийдэл юм.
Нөгөөтэйгүүр, Манан ба IoT давхаргын хооронд харилцах хязгаарлагдмал тооцоолох нөөцтэй төхөөрөмжүүдийн хувьд CoAP ашиглах нь илүү үр дүнтэй байдаг. CoAP-ийн нэг том давуу тал бол HTTP-тэй нийцтэй байх явдал юм, учир нь хоёр протокол нь REST зарчим дээр суурилдаг.
Зураг (б)-д MQTT болон AMQP зэрэг нэг хувилбарт нийтлэх-захиалах харилцааны хоёр загварыг харуулав. Хэдийгээр хоёр протоколыг хийсвэрлэх давхарга бүрийн зангилаа хоорондын харилцаанд ашиглаж болох ч гүйцэтгэл дээр үндэслэн тэдгээрийн байрлалыг тодорхойлох хэрэгтэй. MQTT нь хязгаарлагдмал тооцоолох нөөцтэй төхөөрөмжүүдэд зориулсан хөнгөн протокол хэлбэрээр бүтээгдсэн тул IoT-Fog харилцаанд ашиглаж болно. AMQP нь илүү хүчирхэг төхөөрөмжүүдэд илүү тохиромжтой бөгөөд үүнийг манан болон үүлний зангилааны хооронд байрлуулахад тохиромжтой. MQTT-ийн оронд XMPP протоколыг хөнгөн жинтэй гэж үздэг тул IoT-д ашиглаж болно. Гэхдээ ийм хувилбарт тийм ч өргөн хэрэглэгддэггүй.
үр дүн нь
Хэлэлцсэн протоколуудын аль нэг нь тооцооллын нөөц хязгаарлагдмал төхөөрөмжөөс эхлээд үүл сервер хүртэл систем дэх бүх харилцаа холбоог хамрахад хангалттай байх магадлал багатай юм. Судалгаанаас харахад хөгжүүлэгчид хамгийн их ашигладаг хамгийн ирээдүйтэй хоёр сонголт бол MQTT болон RESTful HTTP юм. Эдгээр хоёр протокол нь хамгийн боловсронгуй, тогтвортой төдийгүй олон сайн баримтжуулсан, амжилттай хэрэгжүүлэлт, онлайн эх сурвалжуудыг агуулдаг.
Тогтвортой байдал, энгийн тохиргооныхоо ачаар MQTT нь IoT түвшинд хязгаарлагдмал төхөөрөмжүүдтэй ашиглахад цаг хугацааны явцад дээд зэргийн гүйцэтгэлээ баталсан протокол юм. Зарим манантай домэйн болон ихэнх үүлэн тооцоолол зэрэг хязгаарлагдмал харилцаа холбоо, батерейны хэрэглээ асуудалгүй системийн зарим хэсэгт RESTful HTTP нь хялбар сонголт юм. CoAP нь IoT мессежийн стандартын хувьд хурдацтай хөгжиж байгаа тул ойрын ирээдүйд MQTT болон HTTP-тэй төстэй тогтвортой байдал, төлөвшлийн түвшинд хүрэх магадлалтай тул үүнийг анхаарч үзэх хэрэгтэй. Гэхдээ стандарт нь одоогоор хөгжиж байгаа бөгөөд энэ нь богино хугацааны нийцтэй байдлын асуудалтай тулгардаг.
Та блог дээрээс өөр юу уншиж чадах вэ?
→
→
→
→
→
Манай захиалах Дараагийн нийтлэлийг алдахгүйн тулд суваг! Бид долоо хоногт хоёроос илүүгүй удаа, зөвхөн ажил хэргийн талаар бичдэг.
Эх сурвалж: www.habr.com