Программалык жана аппараттык камсыздоо тармагындагы технологиялардын өнүгүшү, жаңы коммуникация протоколдорунун пайда болушу нерселердин интернетинин (IoT) кеңейишине алып келди. Аппараттардын саны күндөн-күнгө өсүп жатат жана алар чоң көлөмдөгү маалыматтарды жаратууда. Ошондуктан, бул маалыматтарды иштетүүгө, сактоого жана берүүгө жөндөмдүү ыңгайлуу система архитектурасына муктаждык бар.
Азыр бул максаттар үчүн булут кызматтары колдонулат. Бирок, барган сайын популярдуу болгон туманды эсептөө парадигмасы (Туман) IoT инфраструктурасын масштабдоо жана оптималдаштыруу аркылуу булут чечимдерин толуктай алат.
Булуттар IoT суроо-талаптарынын көбүн жабууга жөндөмдүү. Мисалы, кызматтарга мониторинг жүргүзүү, түзмөктөр тарабынан түзүлгөн маалыматтардын каалаган көлөмүн тез иштетүү, ошондой эле аларды визуалдаштыруу. Туманды эсептөө реалдуу убакыттагы маселелерди чечүүдө натыйжалуураак. Алар суроо-талаптарга тез жооп берет жана маалыматтарды иштетүүдө минималдуу кечигүү менен камсыз кылат. Башкача айтканда, Туман "булуттарды" толуктап, анын мүмкүнчүлүктөрүн кеңейтет.
Бирок, негизги суроо башка: мунун баары IoT контекстинде кантип өз ара аракеттениши керек? Кайсы байланыш протоколдору бириккен IoT-Туман-Булут тутумунда иштөөдө эң натыйжалуу болот?
HTTP ачык үстөмдүгүнө карабастан, IoT, Туман жана Булут системаларында колдонулган көптөгөн башка чечимдер бар. Себеби, IoT коопсуздук, шайкештик жана колдонуучулардын башка талаптары менен ар кандай түзмөк сенсорлорунун функционалдуулугун айкалыштырышы керек.
Бирок маалымдама архитектурасы жана коммуникация стандарты жөнүндө бирдиктүү идея жок. Ошондуктан, IoT конкреттүү тапшырмалары үчүн жаңы протоколду түзүү же учурдагыны өзгөртүү IT коомчулугунун алдында турган эң маанилүү милдеттердин бири болуп саналат.
Учурда кандай протоколдор колдонулуп жатат жана алар эмнени сунуштай алат? Келгиле, аны аныктап көрөлү. Бирок, адегенде, булуттар, туман жана нерселердин Интернети өз ара аракеттенген экосистеманын принциптерин талкуулайлы.
IoT тумандан булутка (F2C) архитектурасы
Сиз IoT, булут жана туманды акылдуу жана координацияланган башкаруу менен байланышкан артыкчылыктарды жана артыкчылыктарды изилдөөгө канчалык көп күч жумшалып жатканын байкаган чыгарсыз. Эгерде жок болсо, анда бул жерде үч стандартташтыруу демилгеси болуп саналат: , и .
Эгерде мурда 2 гана деңгээл каралса, булуттар жана акыркы түзүлүштөр, анда сунушталган архитектура жаңы деңгээлди - туманды эсептөөнү киргизет. Бул учурда, туман деңгээли ресурстардын өзгөчөлүгүнө же бул поддеңгээлдерде ар кандай түзүлүштөрдү колдонууну аныктаган саясаттардын жыйындысына жараша бир нече поддеңгээлдерге бөлүнүшү мүмкүн.
Бул абстракция кандай болушу мүмкүн? Бул жерде типтүү IoT-Туман-Булут экосистемасы. IoT түзмөктөрү аз күтүүнү талап кылган көйгөйлөрдү чечүү үчүн ылдамыраак серверлерге жана эсептөө шаймандарына маалыматтарды жөнөтөт. Ошол эле системада булуттар көп сандагы эсептөө ресурстарын же маалыматтарды сактоо мейкиндигин талап кылган маселелерди чечүүгө жооптуу.
Смартфондор, акылдуу сааттар жана башка гаджеттер да IoTдин бир бөлүгү болушу мүмкүн. Бирок мындай түзмөктөр, эреже катары, ири иштеп чыгуучулардын менчик байланыш протоколдорун колдонушат. Түзүлгөн IoT маалыматтары RESTful кызматтарын түзүүдө ийкемдүүлүктү жана өз ара аракеттенүүнү камсыз кылган REST HTTP протоколу аркылуу туман катмарына өткөрүлүп берилет. Бул локалдык компьютерлерде, серверлерде же сервер кластеринде иштеген учурдагы эсептөө инфраструктурасы менен артка карай шайкеш келүүнү камсыз кылуу зарылдыгынан улам маанилүү. "Туман түйүндөрү" деп аталган жергиликтүү ресурстар алынган маалыматтарды чыпкалап, аны жергиликтүү түрдө иштетет же андан аркы эсептөөлөр үчүн булутка жөнөтөт.
Булуттар ар кандай байланыш протоколдорун колдойт, эң кеңири таралганы AMQP жана REST HTTP. HTTP жакшы белгилүү жана Интернет үчүн ылайыкташтырылган болгондуктан, суроо туулат: "биз аны IoT жана туман менен иштөө үчүн колдонбошубуз керекпи?" Бирок, бул протоколдун аткаруу маселелери бар. Бул тууралуу кийинчерээк.
Жалпысынан бизге керек болгон системага ылайыктуу байланыш протоколдорунун 2 модели бар. Бул суроо-жооп жана жарыялоо-жазылуу. Биринчи модель өзгөчө сервер-кардар архитектурасында кеңири белгилүү. Кардар серверден маалымат сурайт, ал эми сервер суроо-талапты кабыл алып, аны иштеп чыгат жана жооп билдирүүсүн кайтарат. REST HTTP жана CoAP протоколдору бул моделде иштейт.
Экинчи модель маалыматтарды түзүүчү булактар менен бул маалыматтарды алуучулардын ортосунда асинхрондуу, бөлүштүрүлгөн, бош байланышты камсыз кылуу зарылчылыгынан келип чыккан.
Модель үч катышуучуну болжолдойт: жарыялоочу (маалымат булагы), брокер (диспетчер) жана абонент (алуучу). Бул жерде абоненттин ролун аткарган кардар серверден маалыматты талап кылбайт. Сурамдарды жөнөтүүнүн ордуна, ал брокер аркылуу системадагы белгилүү окуяларга жазылат, ал бардык келген билдирүүлөрдү чыпкалоо жана аларды басып чыгаруучулар менен жазылуучулар ортосунда багыттоо үчүн жооптуу. Ал эми жарыялоочу, белгилүү бир темага байланыштуу окуя болгондо, аны брокерге жарыялайт, ал абонентке суралган тема боюнча маалыматтарды жөнөтөт.
Негизинен, бул архитектура окуяга негизделген. Жана бул өз ара аракеттенүү модели IoT, булут, туман тиркемелери үчүн кызыктуу, анткени анын масштабдуулугун камсыз кылуу жана ар кандай түзүлүштөрдүн ортосундагы байланышты жөнөкөйлөтүү, динамикалык көптөн көпкө байланышты жана асинхрондук байланышты колдоо. Жарыялоо-жазылуу моделин колдонгон эң белгилүү стандартташтырылган кабарлашуу протоколдоруна MQTT, AMQP жана DDS кирет.
Албетте, жарыялоо-жазылуу моделинин көптөгөн артыкчылыктары бар:
- Басмачылар жана жазылуучулар бири-биринин бар экендиги жөнүндө билиши керек эмес;
- Бир абонент көп түрдүү басылмалардан маалымат ала алат, ал эми бир басып чыгаруучу көптөгөн ар кандай жазылуучуларга маалыматтарды жөнөтө алат (көптөн көпкө принциби);
- Жарыялоочу менен абоненттин баарлашуу үчүн бир эле учурда активдүү болушу шарт эмес, анткени брокер (кезекте туруу системасы катары иштеген) учурда тармакка туташпаган кардарлар үчүн билдирүүнү сактай алат.
Бирок, суроо-жооп моделинин да күчтүү жактары бар. Сервер тараптын бир нече кардардын суроо-талаптарын аткаруу жөндөмү көйгөй болбогон учурларда, далилденген, ишенимдүү чечимдерди колдонуу мааниси бар.
Эки моделди колдогон протоколдор да бар. Мисалы, XMPP жана HTTP 2.0, алар "сервер түртүү" опциясын колдойт. IETF ошондой эле CoAP чыгарды. Кабарлашуу маселесин чечүү аракетинде, WebSockets протоколу же QUIC (Quick UDP Интернет байланышы) аркылуу 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 колдонмо жана транспорт катмарларында ACKs улам жогору 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-то-Туман мейкиндигинде кандайча өз ара аракеттенишээринин жакшы мисалы бар: . Жаныбарлар тагынуучу сенсорлор менен жабдылган (IoT кардары, C) жана акылдуу айыл чарба системасы (Fog Server, S) тарабынан булуттагы эсептөө аркылуу башкарылат.
POST ыкмасынын аталышы өзгөртүү үчүн ресурсту (/ферм/жаныбарлар), ошондой эле HTTP версиясын жана мазмундун түрүн көрсөтөт, бул учурда система башкара турган жаныбарлар фермасын билдирген JSON объекти (Dulcinea/уй) . Серверден келген жооп HTTPS статус кодун 201 (ресурс түзүлгөн) жөнөтүү аркылуу сурам ийгиликтүү болгонун көрсөтөт. GET ыкмасы серверден ошол идентификатору бар жаныбардын JSON көрүнүшүн кайтарган URIдагы суралган ресурсту гана көрсөтүшү керек (мисалы, /farm/animals/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 брокеринин милдетин аткарган жана MQTT кардарлары катары иштеген Raspberry Pis сенсор маалыматтарын жөнөткөн жергиликтүү серверден тышкары, булут деңгээлинде дагы бир 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-Туман байланышы үчүн колдонсо болот. AMQP аны туман жана булут түйүндөрүнүн ортосунда идеалдуу жайгаштырган күчтүүрөөк түзүлүштөр үчүн ылайыктуу. MQTTдин ордуна, XMPP протоколун IoTде колдонсо болот, анткени ал жеңил деп эсептелет. Бирок мындай сценарийлерде анчалык көп колдонулбайт.
табылгалары
Эсептөө ресурстары чектелген түзүлүштөрдөн тартып булут серверлерине чейин тутумдагы бардык коммуникацияларды камтуу үчүн талкууланган протоколдордун бири жетиштүү болушу күмөн. Изилдөө көрсөткөндөй, иштеп чыгуучулар эң көп колдонгон эки келечектүү вариант MQTT жана RESTful HTTP. Бул эки протокол эң жетилген жана туруктуу гана эмес, ошондой эле көптөгөн жакшы документтештирилген жана ийгиликтүү ишке ашырууларды жана онлайн ресурстарды камтыйт.
Туруктуулугуна жана жөнөкөй конфигурациясына байланыштуу, MQTT чектелген түзмөктөр менен IoT деңгээлинде колдонулганда убакыттын өтүшү менен өзүнүн жогорку натыйжалуулугун далилдеген протокол. Кээ бир туман домендери жана көпчүлүк булут эсептөөлөрү сыяктуу чектелген байланыш жана батареяны керектөө көйгөй болбогон системанын бөлүктөрүндө RESTful HTTP оңой тандоо. CoAP да эске алынышы керек, анткени ал IoT билдирүүлөрүнүн стандарты катары тез өнүгүп жатат жана ал жакынкы келечекте MQTT жана HTTP сыяктуу туруктуулуктун жана жетилгендиктин деңгээлине жетиши мүмкүн. Бирок стандарт учурда өнүгүп жатат, ал кыска мөөнөттүү шайкештик маселелери менен коштолот.
Блогдон дагы эмнени окуй аласыз?
→
→
→
→
→
Биздин жазылуу -канал, кийинки макаланы өткөрүп жибербөө үчүн! Биз жумасына эки жолудан ашык эмес жана бизнес боюнча гана жазабыз.
Source: www.habr.com