Proqram təminatı və avadanlıq sahəsində texnologiyaların inkişafı, yeni əlaqə protokollarının meydana gəlməsi internetin şeylər (IoT) genişlənməsinə səbəb oldu. Cihazların sayı gündən-günə artır və onlar böyük miqdarda məlumat istehsal edirlər. Buna görə də, bu məlumatları işləmək, saxlamaq və ötürmək üçün rahat bir sistem arxitekturasına ehtiyac var.
Hal-hazırda bu məqsədlər üçün bulud xidmətlərindən istifadə edilir. Lakin tədricən daha populyarlaşan dumanlı hesablama (Fog) paradigması bulud çözümlerini əlavə edərək IoT infrastrukturunu genişləndirmək və optimallaşdırmaq üçün kifayət qədər faydalıdır.
Buludlar IoT-nin əksər tələblərini qarşılayır. Məsələn, xidmətlərin monitorinqini təmin etmək, cihazlar tərəfindən istehsal olunan hər hansı miqdarda məlumatı sürətlə işləmək və onların vizualizasiyasını etmək. Lakin dumanlı hesablama real vaxt problemlərinin həllində daha məhsuldardır. Onlar suallara tez cavab verərək məlumatların işlənməsində minimal gecikmə təmin edirlər. Yəni Fog, məhz buludları tamamlayaraq, onun imkanlarını genişləndirir.
Lakin əsas sual başqadır: bütün bunlar IoT kontekstində necə qarşılıqlı əlaqədə olmalıdır? Hansı əlaqə protokolları IoT-Fog-Bulud birləşmiş sistemində ən effektiv olacaq?
HTTP-nin müəyyən edici üstünlüyü görünməsinə baxmayaraq, IoT, Fog və Bulud sistemlərində bir çox digər həllər istifadə edilir. Bunun səbəbi IoT-nin müxtəlif cihaz sensorlarının funksional imkanlarını təhlükəsizlik, uyumluluk və istifadəçilər tərəfindən irəlilədilən digər tələblərlə birləşdirməsidir.
Amma mükəmməl arxitektur və əlaqə standartı ilə bağlı vahid bir təsəvvür yoxdur. Buna görə də, yeni bir protokol yaratmaq və ya mövcud olanı spesifik IoT tələblərinə uyğunlaşdırmağı IT icmasının qarşısında duran ən mühüm vəzifələrdən biridir.
Hal-hazırda hansı protokollar istifadə olunur və nələri təklif edir? Gəlin anlayışa varaq. Amma əvvəlcə buludlar, duman və internet şeylərində qarşılıqlı əlaqə prinsiplərini müzakirə edək.
IoT Fog-to-Cloud (F2C) Arxitekturası
Yəqin ki, IoT, buludlar və dumanın səmərəli və koordinasiyalı idarə edilməsinin üstünlüklərini öyrənmək üçün nə qədər əhəmiyyətli səylər sərf olunduğunu görmüsünüz. Əgər görməmisinizsə, sizə üç standartlaşdırma təşəbbüsünü təqdim edirik: , və .
Əvvəllər yalnız 2 səviyyə - buludlar və uc cihazlar müzakirə edilirdisə, təklif olunan arxitektura yeni bir səviyyə - dumanlı hesablama təqdim edir. Eyni zamanda, duman səviyyəsi resursların spesifikasiyasına və bu alt səviyyələrdəki fərqli cihazların istifadəsini təyin edən siyasət dəstinə əsasən bir neçə alt səviyyəyə bölünə bilər.
Bu abstraksiyanın görünüşü necə ola bilər? Budur, tipik bir IoT-Tutulmuş-Bulud ekosistemi. IoT cihazları, aşağı gecikmə tələb edən problemləri həll etmək üçün məlumatları daha güclü serverlərə və hesablama cihazlarına göndərirlər. Eyni sistemdə buludlar, böyük miqdarda hesablama resursları və ya məlumat saxlanması tələb edən məsələlərin həlli üçün məsuliyyət daşıyır.
Smartfonlar, ağıllı saatlar və digər cihazlar da IoT-nin bir hissəsi ola bilər. Amma bu cür cihazlar adətən iri istehsalçılardan proprietary kommunikasiya protokollarını istifadə edir. İnternetin şeylərindən yaradılan məlumatlar, REST HTTP protokolu vasitəsilə tutqunluq səviyyəsinə göndərilir ki, bu da RESTful xidmətlərin yaradılmasında çeviklik və funksional uyğunluq təmin edir. Bu, yerli kompüterlərdə, serverlərdə və ya server klasterlərində çalışan mövcud hesablama infrastrukturunun geriyə uyğunluğunun təmin edilməsi baxımından vacibdir.
Buludlar müxtəlif kommunikasiya protokollarını dəstəkləyir, bunlar arasında ən çox rast gəlinənləri AMQP və REST HTTP-dir. HTTP ümumi bilindikdə və internet üçün optimallaşdırıldığından, "IoT və tutqunluqla işləmək üçün bunu istifadə etmək olmazmı?" sualı ortaya çıxa bilər. Lakin, bu protokolun performans problemləri var. Bunu daha sonra müzakirə edəcəyik.
Ümumiyyətlə, lazım olan sistemə uyğun iki kommunikasiya protokolu modeli mövcuddur. Bunlar sorğu-cavab modeli və nəşr-abunə modelidir. Birinci model daha geniş tanınır, xüsusən də server-müştəri arxitekturasında. Müştəri serverdən məlumat istəyir, server isə sorğunu alır, onu işləyir və cavab mesajı qaytarır. Bu model REST HTTP və CoAP protokollarında fəaliyyət göstərir.
İkinci model, məlumat yaradan mənbələr ilə bu məlumatların alıcıları arasında asinxron, paylanmış, zəif əlaqəni təmin etmə ehtiyacı səbəbindən ortaya çıxmışdır.
Modeldə üç iştirakçı var: nəşr edən (məlumat mənbəyi), broker (dispeçer) və abunəçi (alıcı). Burada abunəçi rolunu oynayan müştəri serverdən məlumat istəməməlidir. Sorğular göndərmək əvəzinə, o broker vasitəsilə sistemdə müəyyən hadisələrə abunə olur ki, bu broker bütün daxil olan mesajların filtrlenməsi və nəşr edənlər ilə abunəçilər arasında yönləndirilməsi üçün məsuliyyət daşıyır. Nəşr edən, müəyyən bir mövzu ilə əlaqədar hadisə baş verdikdə, onu brokerə nəşr edir, broker isə abunəyə görə tələb olunan mövzu üzrə məlumatı alıcıya göndərir.
Əslində, bu arxitektura hadisələrə əsaslanır. Belə bir qarşılıqlı əlaqə modeli IoT, bulud və duman tətbiqləri üçün maraqlıdır, çünki bu, miqyaslana bilmək və müxtəlif cihazlar arasında qarşılıqlı əlaqəni asanlaşdırmaq, 'çoxdan-çoxa' dinamik əlaqəni və asinxron əlaqəni təmin etmək qabiliyyətinə malikdir. 'Nəşr-abunə' modelini istifadə edən ən tanınmış standartlaşdırılmış mesajlaşma protokollarından bəziləri MQTT, AMQP və DDS-dir.
Aydındır ki, 'nəşr-abunə' modelinin çoxsayda üstünlükləri var:
- Nəşricilərə və abunəçilərə bir-birlərinin varlığından xəbərdar olmağa ehtiyac yoxdur;
- Bir abunəçi müxtəlif nəşrlərdən məlumat ala bilər, bir nəşri isə çoxsaylı abunəçilərə məlumat göndərə bilər (‘çoxdan-çoxa’ prinsipi);
- Nəşrçi və abunəçi məlumat mübadiləsi üçün eyni anda fəal olmağa ehtiyac duymurlar, çünki broker (növbə sistemi kimi fəaliyyət göstərən) müştərilər üçün cari anda şəbəkəyə qoşulmayan mesajları saxlayacaq.
Ancaq 'sorğu-cavab' modelinin də öz üstünlükləri var. Server tərəfində bir neçə müştərinin sorğularını emal etmə imkanları problem olmadıqda, artıq sınaqdandırılmış etibarlı həlləri istifadə etmək məntiqlidir.
Eyni zamanda, hər iki modeli dəstəkləyən protokollar da vardır. Məsələn, 'server push' seçeneğini dəstəkləyən XMPP və HTTP 2.0. IETF həmçinin CoAP-ı ortaya çıxarıb. Mesajlaşma problemi həll etmək üçün WebSockets protokolu və ya HTTP-ni QUIC (Quick UDP İnternet Bağlantıları) protokolu vasitəsilə istifadə edən bir neçə digər həll yaradılmışdır.
WebSockets ilə bağlı, bu, serverdən veb-klienta real vaxtda məlumat ötürmək üçün istifadə olunur və eyni anda iki tərəfli əlaqəni təmin edir, lakin sərhədli hesablama resurslarına malik cihazlar üçün nəzərdə tutulmayıb. QUIC də diqqəti cəlb edir, çünki yeni nəqliyyat protokolu çoxsaylı yeni imkanlar təqdim edir. Lakin QUIC hələ standartlaşdırılmadığından, onun IoT sahəsində mümkün tətbiqi və təsiri haqqında proqnoz vermək vaxtlıdır. Beləliklə, WebSockets və QUIC-i gələcək nəzərə alaraq saxlayırıq, lakin indiki vaxtda daha ətraflı tədqiq etməyəcəyik.
Dünyada kim daha sevimlidir: protokolları müqayisə edirik
İndi protokolların güclü və zəif tərəfləri haqqında danışaq. Qısaca desək, bir aydın lider yoxdur. Hər protokolun öz üstünlük/ləyaqət və çatışmazlıqları var.
Cavab müddəti
Əlaqə protokollarının, xüsusən də şeylərin interneti ilə bağlı, ən vacib xüsusiyyətlərindən biri gecikmə müddətidir. Ancaq mövcud protokollar arasında fərqli şəraitlərdə işləyərkən minimum gecikmə dərəcəsini nümayiş etdirən təmamilə bir qalib yoxdur. Lakin protokolların imkanlarını müqayisə edən çoxsaylı tədqiqatlar var.
Məsələn, IoT ilə çalışarkən HTTP və MQTT-nin effektivliyinin müqayisəsi göstərdi ki, MQTT üçün sorğuların cavab müddəti HTTP-dən qısadır. Və MQTT və CoAP üçün qəbul-ötürü mühitinin müddəti (RTT) öyrənilərkən, CoAP üçün ortalama RTT-nin MQTT-dən 20% daha az olduğu məlum oldu.
Başqa MQTT və CoAP protokollarının RTTsi lokal şəbəkə və IoT şəbəkəsi ssenarilərində aparıldı. Ortaya çıxdı ki, IoT şəbəkəsində ortalama RTT 2-3 dəfə daha yüksəkdir. QoS0 olan MQTT-nin CoAP ilə müqayisədə daha aşağı nəticə göstərdiyi, QoS1 olan MQTT-nin isə tətbiq və nəqliyyat səviyyələrindəki ACK-lar səbəbindən daha yüksək RTT təqdim etdiyi aydın oldu. QoS-nin müxtəlif səviyyələri üçün, şəbəkədə yüklənmə olmadığı zaman MQTT-nin gecikmələri millisaniyələr, CoAP-nın isə yüzlərlə mikrosaniyə oldu. Ancaq daha az etibarlı şəbəkələrdə işlədikdə, TCP üstündə çalışan MQTT tamamilə fərqli bir nəticə göstərəcək.
AMQP və MQTT protokollarının zəhmət yükünü artıraraq gecikmə müddətinin müqayisəsi göstərdi ki, aşağı yük altında gecikmə səviyyəsi demək olar ki, eynidir. Lakin böyük məlumat həcmləri ötürülərkən MQTT daha az gecikmə göstərir. Bir daha CoAP HTTP ilə əlaqə deyilən ssenarisi altında qeyri-ciddi qurğularla, qaz sensorları, hava sensorları, yer (GPS) və mobil şəbəkə interfeysi (GPRS) ilə təchiz olunmuş vasitələrdə müqayisə edildi. Mobil şəbəkə üzərindən CoAP mesajının ötürülməsi üçün tələb olunan vaxt, HTTP mesajlarının istifadə edilməsi üçün tələb olunan vaxtdan demək olar ki, üç dəfə qısa idi.
Araşdırmalar aparıldı ki, burada iki deyil, üç protokol müqayisə edildi. Məsələn, IoT protokolları MQTT, DDS və CoAP arasında tibbi tətbiq ssenarisində şəbəkə emulyatoru istifadə edərək performans müqayisəsi. DDS, müxtəlif pis şəbəkə şəraitində telemetriya gecikməsi baxımından MQTT-dən üstün çıxdı. UDP əsaslı CoAP, sürətli cavab tələb edən tətbiqlər üçün yaxşı təsir göstərdi, lakin UDP əsaslı olması səbəbindən əhəmiyyətli dərəcədə gözlənilməz paket itkiləri baş verdi.
Keçiricilik
MQTT və CoAP-nın bant genişliyinin effektivliyini qiymətləndirmək üçün bir mesaj vasitəsilə ötürülən ümumi məlumatların sayı hesablandı. CoAP, kiçik mesajların ötürülməsi zamanı MQTT-dən daha aşağı bant genişliyinə malik idi. Ancaq protokolların effektivliyinin müsbət məlumat baytlarının ümumi ötürülən baytlara nisbəti ilə müqayisəsində CoAP daha effektiv oldu.
İstifadə MQTT, DDS (nəqliyyat protokolu olaraq TCP ilə) və CoAP-nın bant genişliyinin istifadəsi, adətən CoAP-nın müqayisə olunan daha aşağı bant genişliyi istehlakı göstərdiyini ortaya çıxardı ki, bu da şəbəkə paket itkiləri və ya şəbəkə gecikməsi artdıqca yüksəlməmişdir; bu, MQTT və DDS-də, qeyd olunan ssenarilərdə bant genişliyi istehlakının artdığını müşahidə etmək mümkündür. Başqa bir ssenaridə, eyni anda məlumat ötürən çox sayda cihazın iştirak etdiyi IoT mühitində tipik bir vəziyyətdir. Nəticələr göstərdi ki, daha yüksək yüklənmə üçün CoAP istifadə etmək daha yaxşıdır.
Kiçik yük ilə CoAP ən aşağı bant genişliyini istifadə edir, onu MQTT və REST HTTP izləyir. Lakin, əgər yük ölçüsü artarsa, ən yaxşı nəticələr REST HTTP-dədir.
Enerji istehlakı
Enerji istehlakı həmişə əhəmiyyətli bir məsələdir və IoT sistemlərində xüsusilə önəmlidir. Əgər MQTT və HTTP-də elektrik enerjisi istehlakını, HTTP daha çox enerji istehlak edir. CoAP, enerji idarəçiliyi sahəsində, MQTT-ə nisbətən daha və enerji idarəçiliyini asanlaşdırır. Bununla belə, sadə ssenarilərdə MQTT, enerji sərhədləri olmadıqda, IoT şəbəkələrində məlumat mübadiləsi üçün daha uyğun olur.
AMQP və MQTT-nin mobil və ya qeyri-sabit simsiz şəbəkədəki imkanlarını müqayisə edən bir təcrübə, AMQP-nin təhlükəsizlik sahəsində daha çox imkan təqdim etdiyini, MQTT-nin isə daha enerji səmərəliyini göstərdiyini göstərdi.
Təhlükəsizlik
Təhlükəsizlik, IoT və bulud/hazırda hesablama mövzusunu araşdırarkən ən vacib məsələlərdən biridir. Təhlükəsizlik mexanizmi adətən HTTP, MQTT, AMQP və XMPP-də TLS, CoAP-da DTLS-da, həmçinin Hər iki variantı dəstəkləyən DDS-də əsaslanır.
TLS və DTLS, müştəri və server arasında dəstəklənən şifrələmə dəstləri və açarların mübadiləsi üçün əlaqə qurma prosesi ilə başlayır. Hər iki tərəf, gələcək əlaqənin təhlükəsiz kanal içində baş verməsini təmin etmək üçün dəstləri razılaşdırır. Onlar arasındakı fərq, DTLS-nın UDP əsasında etibarsız əlaqə ilə işləməyə imkan tanıyan kiçik dəyişikliklərdən ibarətdir.
İstifadə Fərqli TLS və DTLS tətbiqləri arasında aparılan tədqiqatda, TLS-in vəzifəsini daha yaxşı yerinə yetirdiyi məlum olub. DTLS-ə edilən hücumlar, onun səhvlərə qarşı dözümlü olması səbəbindən daha müvəffəqiyyətli olub.
Ancaq bu protokolların ən böyük problemi, onların ilkin olaraq IoT-də istifadə üçün nəzərdə tutulmaması və buludda ya da duman mühitində işləməyi mərhələ kimi düşünməməsidir. Razılaşdırılmış mübadilə (handshaking) vasitəsilə, hər bir əlaqə qurularkən əlavə trafik əlavə edirlər ki, bu da hesablama resurslarını tükədir. Təhlükəsizlik səviyyəsi olmayan əlaqələrlə müqayisədə TLS üçün ortalama 6.5%, DTLS üçün isə 11% əlavə yük müşahidə edilir. Resursları bol olan mühitlərdə, adətən yerləşən səviyyəsində, bu problem olmayacaq, amma IoT ilə duman səviyyəsi arasında olan əlaqələrdə bu vacib bir məhduddur.
Nə seçmək lazımdır? Qəti cavab yoxdur. MQTT və HTTP, digər protokollarla müqayisədə IoT üçün nisbətən daha yetkin və daha stabillik göstərən protokollar kimi görünür.
Tək kommunikasiya protokoluna əsaslanan həllər
Tək protokol həllinin bir çox mənfi cəhəti var. Məsələn, məhdud mühitə uyğundur olan bir protokol, təhlükəsizlik tələbləri yüksək olan bir sahədə işləməyə bilər. Bunu nəzərə alaraq, IoT-nin Fog-to-Cloud ekosistemində tək protokola əsaslanan mümkün həllərin əksəriyyətini, yalnız MQTT və REST HTTP-ni qaldırmalıyıq.
REST HTTP tək protokol həlli olaraq
IoT-to-Fog sahəsində REST HTTP sorğu/cavab qarşılıqlı əlaqəsinin yaxşı bir nümunəsi var: . Heyvanlar, geyilə bilən sensörlərlə (IoT müştəri, C) təmin edilir və bulud hesablama ilə ağıllı təsərrüfat sistemi (Fog-server, S) vasitəsilə idarə olunur.
POST metodunun başlığında dəyişdiriləcək resurs (\/farm\/animals), eləcə də HTTP versiyası və məzmun növü, bu halda sistemin idarə etməli olduğu bir kənd təsərrüfatı obyektini ifadə edən JSON obyektidir (Dulcineya\/inək). Serverdən gələn cavab, sorğunun uğurlu olduğunu bildirir və HTTPS 201 (resurs yaradıldı) status kodunu göndərir. GET metodu yalnız URI-də istənilən resursu göstərməlidir (məsələn, \/farm\/animals\/1), həmin identifikatorla heyvanın JSON təqdimatını serverdən qaytarır.
PUT metodu, resursun bəzi xüsusi qeydlərini yeniləmək lazım olduqda istifadə olunur. Bu halda, dəyişdirilməsi planlaşdırılan parametrin URI’sı və cari dəyəri göstərilir (məsələn, inəyin hal-hazırda gəzən olduğunu göstərən, \/farm\/animals\/1?state=gezinmə). Nəhayət, DELETE metodu bərabər dərəcədə GET metodu üçün istifadə olunur, lakin əməliyyat nəticəsində resursu silir.
MQTT tək protokol həlli olaraq
Eynən o eyni ağıllı ferma modelini götürək, amma REST HTTP əvəzinə MQTT protokolundan istifadə edək. Mosquitto kitabxanası quraşdırılmış yerli server broker rolunu oynayır. Bu nümunədə Raspberry Pi adlı sadə bir kompüter (fermanın serveri kimi işarələnir) Mosquitto brokeri ilə tam uyğun olan MQTT Paho kitabxanasının quraşdırılması vasitəsilə MQTT müştərisi kimi fəaliyyət göstərir.
Bu müştəri IoT-nin aşkar etmə və hesablama imkanları olan cihazı təmsil edən abstraksiya səviyyəsinə uyğundur. Digər tərəfdən, vasitəçi daha yüksək bir abstraksiya səviyyəsinə uyğundur və daha böyük məlumat emalı və saxlama gücü ilə xarakterizə olunan duman hesablama düyününü təmsil edir.
Təklif olunan «ağıllı ferma» ssenarisində Raspberry Pi, akselerometr, GPS və temperatur sensorları ilə bağlantı qurur və bu sensorlardan məlumatları duman düyünündə dərc edir. Yəqin ki, bilirsiniz ki, MQTT mövzuları bir iyerarxiya kimi nəzərdən keçirir. Bir MQTT nəşriyyatı müəyyən bir mövzular dəstəsinə mesajlar dərc edə bilər. Bizim halda onlar üçdür. Heyvan sahəsində temperaturu ölçən sensor üçün müştəri mövzunu (animalfarm/shed/temperature) seçir. GPS mövqeyini ölçən və heyvanların akselerometr vasitəsilə hərəkətini izləyən sensorlara dair müştəri, yeniləmələri (animalfarm/animal/GPS) və (animalfarm/animal/movement) dərc edir.
Bu məlumat brokerə göndəriləcək, broker isə daha sonra başqa maraqlanan abunəçiyə ehtiyac yaranarsa, onu yerli verilənlər bazasında müvəqqəti saxlayacaq.
Yerilər serverin MQTT brokeri rolunu oynadığı yerdə, Raspberry Pi müştəriləri sensorlardan məlumatları göndərir. Bulud səviyyəsində də bir MQTT brokeri ola bilər. Bu halda, yerli brokera göndərilən məlumat yerli verilənlər bazasında müvəqqəti saxlanıla bilər və / və ya buluda göndərilə bilər. Bu vəziyyətdə duman MQTT brokeri bütün məlumatları bulud MQTT brokeri ilə bağlamaq üçün istifadə olunur. Belə bir memarlıqda mobil tətbiq istifadəçisi hər iki brokerə abunə ola bilər.
Bir broker (məsələn, bulud) ilə əlaqə kəsildikdə, son istifadəçi digərindən (dumanlı) məlumat alacaq. Bu, duman və bulud hesablama sistemlərinin birləşdirildiyi sistemlərin özünəməxsus xüsusiyyətidir. Şəraitdə, mobil tətbiq adətən duman MQTT brokerinə ilk qoşulma ilə təyin olunur, uğursuzluq halında isə buluddakı MQTT brokerinə qoşulmağa çalışır. Bu həll IoT-F2C sistemlərində bir çoxlarından biridir.
Çoxprotokollu həllər
Bir protokol ilə işləyən həllər onların daha asan tətbiqi səbəbindən populyardır. Lakin IoT-F2C sistemlərində müxtəlif protokolların birləşdirilməsi əhəmiyyətlidir. Fərqli səviyyələrdə fərqli protokolların işləməsi anlayışını ortaya qoyur. Məsələn, IoT, duman və bulud hesablama səviyyələrini nəzərdən keçirək. IoT səviyyəsindəki cihazlar adətən məhdud hesab olunur. Bu nəzərdən, IoT səviyyələrini ən məhdud, bulud səviyyələrini isə ən az məhdud hesab etməyə baxaq, duman hesablama isə bu iki arasında bir yer tutar. Deməli, IoT və duman abstraksiyaları arasında olan cari protokol həlləri MQTT, CoAP və XMPP-i əhatə edir. Duman və bulud arasında isə AMQP, REST HTTP ilə birlikdə ən çox istifadə edilən protokollardan biridir; REST-in çevikliyi sayəsində, həmçinin IoT ilə duman səviyyələri arasında da istifadə olunur.
Burada əsas problem protokolların funksional uyğunluğu və mesajların bir protokoldan digərinə çevrilməsinin asanlığıdır. İdeal olaraq, gələcəkdə bulud və duman resursları olan internet şeyləri sisteminin istifadə olunan əlaqə protokollarından asılı olmaması və fərqli protokollar arasında yaxşı inteqrasiya təmin etməsi əhəmiyyətlidir.
Hal-hazırda bu belə olmadığı üçün əhəmiyyətli fərqləri olmayan protokolları birləşdirmək mənalıdır. Bu məqsədlə, potensial bir həll, eyni arxitektura stilini paylaşan iki protokolun birləşməsinə əsaslanır: REST HTTP və CoAP. Başqa bir təklif olunan həll, "nəşr-abunə" modelini təqdim edən iki protokolun birləşməsinə əsaslanır: MQTT və AMQP. Yaxın anlayışların istifadəsi (həm MQTT, həm də AMQP brokerləri istifadə edir, CoAP və HTTP isə REST-i istifadə edir) bu birləşmələrin həyata keçirilməsini asanlaşdırır və inteqrasiya üçün daha az səylə tələb edir.
Şəkil (a) HTTP və CoAP-a əsaslanan iki sorğu-cavab modelini göstərir və bunların IoT-F2C həllində mümkün yerləşdirilməsini təqdim edir. HTTP müasir şəbəkələrdə ən tanınmış və tətbiq olunan protokollardan biri olduğu üçün onun tamamilə digər mesaj paylaşım protokolları ilə əvəz olunması ehtimalı azdır. Bulud və duman arasında yer alan güclü cihazları təmsil edən düyünlər arasında REST HTTP məqbul bir həll olaraq qəbul edilir.
Digər tərəfdən, duman və IoT səviyyələri arasında əlaqə quran məhdud hesablama resurslarına malik cihazlar üçün CoAP-dan istifadə etmək daha effektivdir. CoAP-ın ən böyük üstünlüklərindən biri əslində HTTP ilə uyğunluğudur, çünki hər iki protokol REST prinsiplərinə əsaslanır.
Şəkil (b) "nəşr-abunə" qarşılıqlı əlaqəsinin iki modelini bir ssenaridə, MQTT və AMQP-ni əhatə edir. Hətta hər iki protokolun abstraksiya səviyyəsinin hər birində düyünlər arasında əlaqə üçün istifadə oluna biləcəyi nəzəri olaraq düzgün olsa da, onların mövqeyi performansa əsaslanaraq müəyyən edilməlidir. MQTT məhdud hesablama resurslarına sahib cihazlar üçün sadələşdirilmiş bir protokol olaraq yaradılmışdır, buna görə də onu IoT ilə duman arasında əlaqəyə istifadə etmək olar. AMQP daha güclü cihazlar üçün daha uyğundur, bu da onu duman və bulud xətləri arasında ideal yerləşdirir. IoT-də MQTT əvəzinə XMPP protokolundan istifadə etmək olar, çünki bu, yüngül hesab olunur. Lakin bu, bu cür ssenarilərdə geniş istifadə edilmir.
Sonuçlar
Müzakirə olunan protokollardan birinin sistemdəki bütün əlaqələri əhatə etməsi, məhdud hesablama resurslarına sahib cihazlardan bulud serverlərinə qədər, ehtimal ki, mümkün deyil. Araşdırma, inkişaf etdiricilər tərəfindən daha çox istifadə olunan ən perspektivli iki seçimi MQTT və RESTful HTTP olduğunu göstərdi. Bu iki protokol yalnız ən yetkin və sabit olanlar deyil, eyni zamanda yaxşı sənədləşdirilmiş və uğurlu tətbiqlər və onlayn resurslarla doludur.
Stabilliyi və sadə konfiqurasiyası sayəsində MQTT, zaman keçdikcə məhdud cihazlar səviyyəsində IoT istifadə edilən üstündür. Sistem hissələrində, burada məhdud əlaqə və batareya istehlakı problem olmursa, məsələn, bəzi duman sahələrində və əksər bulud hesablamalarında RESTful HTTP sadə seçimdir. CoAP da nəzərə alınmalıdır, çünki bu da IoT mesajlaşma standartı kimi sürətlə inkişaf edir və yaxın gələcəkdə MQTT və HTTP-yə bənzər stabil və yetkin bir səviyyəyə çatması mümkündür. Lakin standart indi inkişaf etməkdədir, bu da qısa müddətli uyğunluq problemləri ilə bağlıdır.
Bloqda oxumaq üçün daha nə faydalı məlumat var
→
→
→
→
→
Bizim -kanalımıza abunə olun, növbəti məqaləni qaçırmayın! Həftədə yalnız iki dəfə yazırıq və yalnız lazımlı məlumatları təqdim edirik.
Mənbə: habr.com
