Yazılım ve donanım alanında teknolojilerin gelişmesi, yeni iletişim protokollerinin ortaya çıkması Nesnelerin İnterneti'nin (IoT) yaygınlaşmasına yol açmıştır. Cihazların sayısı her geçen gün artıyor ve büyük miktarda veri üretiyorlar. Bu nedenle bu verileri işleyebilen, depolayabilen ve iletebilen kullanışlı bir sistem mimarisine ihtiyaç vardır.
Artık bulut hizmetleri bu amaçlar için kullanılıyor. Ancak giderek daha popüler hale gelen sis bilişim paradigması (Fog), IoT altyapısını ölçeklendirip optimize ederek bulut çözümlerini tamamlayabilir.
Bulutlar çoğu IoT isteğini karşılayabilir. Örneğin hizmetlerin izlenmesini, cihazlar tarafından oluşturulan her türlü verinin hızlı işlenmesini ve görselleştirilmesini sağlamak. Sis bilişimi gerçek zamanlı problemleri çözerken daha etkilidir. İsteklere hızlı yanıt verirler ve veri işlemede minimum gecikme sağlarlar. Yani Fog, “bulutları” tamamlıyor ve yeteneklerini genişletiyor.
Ancak asıl soru farklı: Tüm bunlar Nesnelerin İnterneti bağlamında nasıl etkileşime girmeli? Kombine bir IoT-Fog-Cloud sisteminde çalışırken hangi iletişim protokolleri en etkili olacak?
HTTP'nin belirgin hakimiyetine rağmen IoT, Sis ve Bulut sistemlerinde kullanılan çok sayıda başka çözüm vardır. Bunun nedeni IoT'nin çeşitli cihaz sensörlerinin işlevselliğini kullanıcıların güvenlik, uyumluluk ve diğer gereksinimleriyle birleştirmesi gerektiğidir.
Ancak referans mimarisi ve iletişim standardı hakkında tek bir fikir yok. Bu nedenle, belirli IoT görevleri için yeni bir protokol oluşturmak veya mevcut olanı değiştirmek, BT topluluğunun karşı karşıya olduğu en önemli görevlerden biridir.
Şu anda hangi protokoller kullanılıyor ve neler sunabilirler? Hadi çözelim. Ama önce bulutların, sisin ve nesnelerin internetinin etkileşim içinde olduğu ekosistemin ilkelerini tartışalım.
IoT Sisten Buluta (F2C) Mimari
IoT, bulut ve sisin akıllı ve koordineli yönetimiyle ilgili avantaj ve faydaları keşfetmek için ne kadar çaba sarf edildiğini muhtemelen fark etmişsinizdir. Değilse, işte üç standardizasyon girişimi: , и .
Daha önce sadece 2 seviye (bulutlar ve uç cihazlar) dikkate alınıyorsa, önerilen mimari yeni bir seviye olan sis bilişimini tanıtıyor. Bu durumda sis seviyesi, kaynakların özelliklerine veya bu alt seviyelerde farklı cihazların kullanımını belirleyen bir dizi politikaya bağlı olarak birkaç alt seviyeye bölünebilir.
Bu soyutlama neye benzeyebilir? İşte tipik bir IoT-Sis-Bulut ekosistemi. IoT cihazları, düşük gecikme gerektiren sorunları çözmek için verileri daha hızlı sunuculara ve bilgi işlem cihazlarına gönderir. Aynı sistemde bulutlar, büyük miktarda bilgi işlem kaynağı veya veri depolama alanı gerektiren sorunların çözümünden sorumludur.
Akıllı telefonlar, akıllı saatler ve diğer cihazlar da IoT'nin bir parçası olabilir. Ancak bu tür cihazlar, kural olarak, büyük geliştiricilerin özel iletişim protokollerini kullanır. Oluşturulan IoT verileri, RESTful servisleri oluşturulurken esneklik ve birlikte çalışabilirlik sağlayan REST HTTP protokolü aracılığıyla sis katmanına aktarılır. Bu, yerel bilgisayarlar, sunucular veya bir sunucu kümesi üzerinde çalışan mevcut bilgi işlem altyapısıyla geriye dönük uyumluluk sağlama ihtiyacının ışığında önemlidir. "Sis düğümleri" olarak adlandırılan yerel kaynaklar, alınan verileri filtreler ve yerel olarak işler veya daha fazla hesaplama için buluta gönderir.
Bulutlar farklı iletişim protokollerini destekler; en yaygın olanları AMQP ve REST HTTP'dir. HTTP iyi bilindiği ve İnternet için uyarlandığı için şu soru ortaya çıkabilir: "Bunu IoT ve sis ile çalışmak için kullanmamalı mıyız?" Ancak bu protokolün performans sorunları vardır. Bu konuda daha sonra daha fazla bilgi vereceğiz.
Genel olarak ihtiyacımız olan sisteme uygun 2 model haberleşme protokolü bulunmaktadır. Bunlar istek-cevap ve yayınla-abone ol. İlk model, özellikle sunucu-istemci mimarisinde daha yaygın olarak bilinmektedir. İstemci sunucudan bilgi ister ve sunucu bu isteği alır, işler ve bir yanıt mesajı döndürür. REST HTTP ve CoAP protokolleri bu model üzerinde çalışır.
İkinci model, veri üreten kaynaklar ile bu verinin alıcıları arasında asenkron, dağıtılmış, gevşek bağlantı sağlama ihtiyacından doğmuştur.
Model üç katılımcıyı varsayar: bir yayıncı (veri kaynağı), bir komisyoncu (gönderici) ve bir abone (alıcı). Burada abone olarak görev yapan istemcinin sunucudan bilgi talep etmesine gerek yoktur. İstek göndermek yerine, gelen tüm mesajları filtrelemekten ve bunları yayıncılar ile aboneler arasında yönlendirmekten sorumlu olan bir aracı aracılığıyla sistemdeki belirli olaylara abone olur. Ve yayıncı, belirli bir konuyla ilgili bir olay meydana geldiğinde, bunu komisyoncuya yayınlar ve komisyoncu, talep edilen konuyla ilgili verileri aboneye gönderir.
Esas itibariyle bu mimari olaya dayalıdır. Ve bu etkileşim modeli, ölçeklenebilirlik sağlama ve farklı cihazlar arasındaki ara bağlantıyı basitleştirme, dinamik çoktan çoğa iletişimi ve asenkron iletişimi destekleme yeteneği nedeniyle IoT, bulut, sis uygulamaları için ilgi çekicidir. Yayınla-abone ol modelini kullanan en iyi bilinen standartlaştırılmış mesajlaşma protokollerinden bazıları MQTT, AMQP ve DDS'yi içerir.
Açıkçası, yayınlama-abone olma modelinin birçok avantajı vardır:
- Yayıncıların ve abonelerin birbirlerinin varlığından haberdar olmaları gerekmez;
- Bir abone birçok farklı yayından bilgi alabilir ve bir yayıncı birçok farklı aboneye veri gönderebilir (çoktan çoğa prensibi);
- Yayıncı ve abonenin iletişim kurmak için aynı anda aktif olması gerekmez, çünkü komisyoncu (kuyruk sistemi olarak çalışan), o anda ağa bağlı olmayan istemciler için mesajı saklayabilecektir.
Ancak istek-yanıt modelinin de güçlü yanları vardır. Sunucu tarafının birden fazla istemci isteğini karşılama yeteneğinin sorun olmadığı durumlarda kanıtlanmış, güvenilir çözümlerin kullanılması mantıklıdır.
Her iki modeli de destekleyen protokoller de vardır. Örneğin, "sunucu gönderimi" seçeneğini destekleyen XMPP ve HTTP 2.0. IETF ayrıca bir CoAP yayınladı. Mesajlaşma sorununu çözmek amacıyla WebSockets protokolü veya QUIC (Hızlı UDP İnternet Bağlantıları) üzerinden HTTP protokolünün kullanılması gibi başka çözümler de oluşturuldu.
WebSockets durumunda, verileri gerçek zamanlı olarak bir sunucudan web istemcisine aktarmak için kullanılmasına ve eşzamanlı çift yönlü iletişimle kalıcı bağlantılar sağlamasına rağmen, sınırlı bilgi işlem kaynaklarına sahip cihazlar için tasarlanmamıştır. Yeni taşıma protokolü birçok yeni fırsat sağladığından QUIC ayrıca ilgiyi hak ediyor. Ancak QUIC henüz standartlaştırılmadığından olası uygulamasını ve IoT çözümleri üzerindeki etkisini tahmin etmek için henüz erken. Bu nedenle, geleceğe yönelik bir bakış açısıyla WebSockets ve QUIC'i aklımızda tutuyoruz, ancak şimdilik bu konuyu daha ayrıntılı olarak incelemeyeceğiz.
Dünyanın en tatlısı kim: protokolleri karşılaştırmak
Şimdi protokollerin güçlü ve zayıf yanlarından bahsedelim. İleriye baktığımızda net bir liderin olmadığına hemen rezervasyon yaptıralım. Her protokolün bazı avantajları/dezavantajları vardır.
Tepki süresi
Özellikle Nesnelerin İnterneti ile ilgili olarak iletişim protokollerinin en önemli özelliklerinden biri yanıt süresidir. Ancak mevcut protokoller arasında, farklı koşullar altında çalışırken minimum gecikme düzeyini gösteren net bir kazanan yoktur. Ancak protokol yeteneklerine ilişkin bir sürü araştırma ve karşılaştırma var.
Örneğin, IoT ile çalışırken HTTP ve MQTT'nin etkinliğinin karşılaştırılması, MQTT isteklerine yanıt süresinin HTTP'den daha az olduğunu gösterdi. Ve ne zaman MQTT ve CoAP'ın gidiş-dönüş süresi (RTT), CoAP'ın ortalama RTT'sinin MQTT'den %20 daha az olduğunu ortaya çıkardı.
Diğer MQTT ve CoAP protokolleri için RTT ile yapılan testler yerel ağ ve IoT ağı olmak üzere iki senaryoda gerçekleştirildi. Bir IoT ağında ortalama RTT'nin 2-3 kat daha yüksek olduğu ortaya çıktı. QoS0'lı MQTT, CoAP'a kıyasla daha düşük bir sonuç gösterdi ve QoS1'li MQTT, uygulama ve taşıma katmanlarındaki ACK'ler nedeniyle daha yüksek bir RTT gösterdi. Farklı QoS seviyeleri için, tıkanıklık olmadan ağ gecikmesi MQTT için milisaniye ve CoAP için yüzlerce mikrosaniyeydi. Ancak daha az güvenilir ağlar üzerinde çalışırken TCP üzerinde çalışan MQTT'nin tamamen farklı bir sonuç göstereceğini hatırlamakta fayda var.
AMQP ve MQTT protokollerinin veri yükünü artırarak yanıt süresi, hafif yükte gecikme seviyesinin neredeyse aynı olduğunu gösterdi. Ancak büyük miktarlarda veri aktarılırken MQTT daha kısa yanıt süreleri gösterir. bir tane daha CoAP, gaz sensörleri, hava durumu sensörleri, konum sensörleri (GPS) ve mobil ağ arayüzü (GPRS) ile donatılmış araçların üzerine yerleştirilen cihazların kullanıldığı bir makineden makineye iletişim senaryosunda HTTP ile karşılaştırıldı. Bir CoAP mesajını mobil ağ üzerinden iletmek için gereken süre, HTTP mesajlarını kullanmak için gereken süreden neredeyse üç kat daha kısaydı.
İki değil üç protokolü karşılaştıran çalışmalar yapıldı. Örneğin, Bir ağ emülatörü kullanılarak tıbbi uygulama senaryosunda MQTT, DDS ve CoAP IoT protokollerinin performansı. DDS, çeşitli kötü ağ koşulları altında test edilen telemetri gecikmesi açısından MQTT'den daha iyi performans gösterdi. UDP tabanlı CoAP, hızlı yanıt süreleri gerektiren uygulamalarda iyi çalıştı ancak UDP tabanlı olması nedeniyle öngörülemeyen önemli paket kaybı yaşandı.
kapasite
Bant genişliği verimliliği açısından MQTT ve CoAP, mesaj başına aktarılan toplam veri miktarının hesaplanmasıyla gerçekleştirildi. CoAP, küçük mesajları iletirken MQTT'den daha düşük verim gösterdi. Ancak protokollerin verimliliğini, faydalı bilgi baytlarının sayısının aktarılan toplam bayt sayısına oranı açısından karşılaştırırken CoAP'ın daha etkili olduğu ortaya çıktı.
at MQTT, DDS (aktarım protokolü olarak TCP ile) ve CoAP bant genişliği kullanıldığında, CoAP'ın genel olarak nispeten daha düşük bant genişliği tüketimi gösterdiği ve MQTT ve DDS'nin aksine artan ağ paket kaybı veya artan ağ gecikmesi ile artmadığı bulunmuştur. bahsedilen senaryolarda bant genişliği kullanımında bir artış. Başka bir senaryo, IoT ortamlarında tipik olan, aynı anda veri ileten çok sayıda cihazı içeriyordu. Sonuçlar, daha yüksek kullanım için CoAP kullanmanın daha iyi olduğunu gösterdi.
Hafif yük altında CoAP en az bant genişliğini kullandı, ardından MQTT ve REST HTTP geldi. Ancak yüklerin boyutu arttığında REST HTTP en iyi sonuçları verdi.
Güç tüketimi
Enerji tüketimi konusu her zaman büyük önem taşıyor, özellikle de IoT sisteminde. Eğer MQTT ve HTTP elektrik tüketirken, HTTP çok daha fazlasını tüketir. Ve CoAP daha fazlasıdır MQTT ile karşılaştırıldığında güç yönetimine olanak tanır. Ancak basit senaryolarda MQTT, özellikle güç kısıtlaması yoksa Nesnelerin İnterneti ağlarında bilgi alışverişi için daha uygundur.
AMQP ve MQTT'nin yeteneklerini mobil veya kararsız bir kablosuz ağ test ortamında karşılaştıran bir deney, AMQP'nin daha fazla güvenlik özelliği sunduğu, MQTT'nin ise enerji açısından daha verimli olduğunu ortaya çıkardı.
güvenlik
Güvenlik, Nesnelerin İnterneti ve sis/bulut bilişimi konusunu incelerken gündeme getirilen bir diğer kritik konudur. Güvenlik mekanizması tipik olarak HTTP, MQTT, AMQP ve XMPP'de TLS'yi veya CoAP'ta DTLS'yi temel alır ve her iki DDS varyantını da destekler.
TLS ve DTLS, desteklenen şifre paketlerinin ve anahtarların değişimi için istemci ve sunucu tarafları arasında iletişim kurulması süreciyle başlar. Her iki taraf da daha fazla iletişimin güvenli bir kanalda gerçekleşmesini sağlamak için setler üzerinde pazarlık yapar. İkisi arasındaki fark, UDP tabanlı DTLS'nin güvenilmez bir bağlantı üzerinden çalışmasına izin veren küçük değişikliklerde yatmaktadır.
at TLS ve DTLS'nin birkaç farklı uygulaması, TLS'nin daha iyi bir iş çıkardığını buldu. Hata toleransı nedeniyle DTLS'ye yapılan saldırılar daha başarılıydı.
Ancak bu protokollerle ilgili en büyük sorun, orijinal olarak IoT'de kullanılmak üzere tasarlanmamaları ve sis veya bulutta çalışacak şekilde tasarlanmamalarıdır. El sıkışma yoluyla, her bağlantı kurulumunda ek trafik ekleyerek bilgi işlem kaynaklarını tüketirler. Güvenlik katmanı olmayan iletişimlerle karşılaştırıldığında ortalama olarak TLS'de %6,5, DTLS'de ise %11'lik bir artış söz konusudur. Kaynak açısından zengin ortamlarda, genellikle seviyede bu bir sorun olmayacak ancak IoT ile sis seviyesi arasındaki bağlantıda bu önemli bir sınırlama haline geliyor.
Ne seçeceksin? Net bir cevap yok. MQTT ve HTTP, diğer protokollerle karşılaştırıldığında nispeten daha olgun ve daha kararlı IoT çözümleri olarak kabul edildikleri için en umut verici protokoller gibi görünüyor.
Birleşik iletişim protokolüne dayalı çözümler
Tek protokollü çözüm uygulamasının birçok dezavantajı vardır. Örneğin, kısıtlı bir ortama uygun olan bir protokol, sıkı güvenlik gereksinimleri olan bir alanda çalışmayabilir. Bunu aklımızda tutarak, MQTT ve REST HTTP hariç, IoT'deki Sisten Buluta ekosistemindeki neredeyse tüm olası tek protokollü çözümleri bir kenara atmak zorunda kaldık.
Tek protokollü bir çözüm olarak REST HTTP
REST HTTP isteklerinin ve yanıtlarının IoT-to-Fog alanında nasıl etkileşime girdiğine dair iyi bir örnek var: . Hayvanlar giyilebilir sensörlerle (IoT istemcisi, C) donatılıyor ve akıllı bir tarım sistemi (Fog sunucusu, S) tarafından bulut bilişim aracılığıyla kontrol ediliyor.
POST yönteminin başlığı, değiştirilecek kaynağın (/farm/animals) yanı sıra HTTP sürümü ve içerik türünü de belirtir; bu durumda bu, sistemin yöneteceği hayvan çiftliğini temsil eden bir JSON nesnesidir (Dulcinea/inek) . Sunucudan gelen yanıt, HTTPS durum kodu 201 (kaynak oluşturuldu) gönderilerek isteğin başarılı olduğunu gösterir. GET yöntemi, sunucudan bu kimliğe sahip hayvanın JSON temsilini döndüren URI'de yalnızca istenen kaynağı (örneğin, /farm/animals/1) belirtmelidir.
PUT yöntemi, bazı belirli kaynak kayıtlarının güncellenmesi gerektiğinde kullanılır. Bu durumda kaynak, değiştirilecek parametrenin URI'sini ve mevcut değeri belirtir (örneğin, ineğin o anda yürüdüğünü belirtir, /farm/animals/1? state=walking). Son olarak DELETE yöntemi de GET yöntemiyle aynı şekilde kullanılır ancak işlem sonucunda kaynağı basitçe siler.
Tek protokollü bir çözüm olarak MQTT
Aynı akıllı çiftliği ele alalım ancak REST HTTP yerine MQTT protokolünü kullanıyoruz. Mosquitto kütüphanesinin kurulu olduğu yerel bir sunucu, aracı görevi görür. Bu örnekte, basit bir bilgisayar (çiftlik sunucusu olarak anılır) Raspberry Pi, Mosquitto komisyoncusu ile tamamen uyumlu olan Paho MQTT kütüphanesinin kurulumu yoluyla uygulanan bir MQTT istemcisi olarak hizmet vermektedir.
Bu istemci, algılama ve hesaplama yeteneklerine sahip bir cihazı temsil eden bir IoT soyutlama katmanına karşılık gelir. Öte yandan aracı, daha yüksek işleme ve depolama kapasitesi ile karakterize edilen bir sis hesaplama düğümünü temsil eden daha yüksek düzeyde bir soyutlamaya karşılık gelir.
Önerilen akıllı çiftlik senaryosunda Raspberry Pi, ivmeölçer, GPS ve sıcaklık sensörlerine bağlanır ve bu sensörlerden gelen verileri bir sis düğümüne yayınlar. Muhtemelen bildiğiniz gibi MQTT konuları bir hiyerarşi olarak ele alır. Tek bir MQTT yayıncısı belirli bir konu grubuna yönelik mesajlar yayınlayabilir. Bizim durumumuzda bunlardan üç tane var. Bir hayvan ahırındaki sıcaklığı ölçen bir sensör için müşteri bir tema seçer (hayvan çiftliği/baraka/sıcaklık). İvme ölçer aracılığıyla GPS konumunu ve hayvan hareketini ölçen sensörler için müşteri (hayvan çiftliği/hayvan/GPS) ve (hayvan çiftliği/hayvan/hareket) güncellemelerini yayınlayacaktır.
Bu bilgiler, daha sonra ilgilenen başka bir abonenin gelmesi durumunda bu bilgileri yerel bir veritabanında geçici olarak saklayabilecek komisyoncuya iletilecektir.
Sisin içinde MQTT komisyoncusu görevi gören ve MQTT istemcisi görevi gören Raspberry Pis'in sensör verilerini gönderdiği yerel sunucuya ek olarak bulut düzeyinde başka bir MQTT komisyoncusu da olabilir. Bu durumda yerel aracıya iletilen bilgiler geçici olarak yerel bir veritabanında saklanabilir ve/veya buluta gönderilebilir. Bu durumda sis MQTT aracısı, tüm verileri bulut MQTT aracısıyla ilişkilendirmek için kullanılır. Bu mimari ile bir mobil uygulama kullanıcısı her iki brokera da abone olabiliyor.
Aracılardan birine (örneğin bulut) bağlantı başarısız olursa, son kullanıcı diğerinden (sis) bilgi alacaktır. Bu, birleşik sis ve bulut bilişim sistemlerinin karakteristik bir özelliğidir. Varsayılan olarak, mobil uygulama önce sis MQTT aracısına bağlanacak ve bu başarısız olursa bulut MQTT aracısına bağlanacak şekilde yapılandırılabilir. Bu çözüm, IoT-F2C sistemlerindeki birçok çözümden yalnızca biridir.
Çoklu protokol çözümleri
Tek protokollü çözümler, uygulanmasının daha kolay olması nedeniyle popülerdir. Ancak IoT-F2C sistemlerinde farklı protokolleri birleştirmenin mantıklı olduğu açıktır. Buradaki fikir, farklı protokollerin farklı seviyelerde çalışabilmesidir. Örneğin üç soyutlamayı ele alalım: Nesnelerin İnterneti katmanları, sis ve bulut bilişim. IoT düzeyindeki cihazlar genellikle sınırlı kabul edilir. Bu genel bakış için IoT katmanlarını en kısıtlı, bulutu en az kısıtlı ve sis bilişimi "ortada bir yerde" olarak ele alalım. O zaman IoT ve sis soyutlamaları arasında mevcut protokol çözümlerinin MQTT, CoAP ve XMPP'yi içerdiği ortaya çıktı. Sis ve bulut arasında ise AMQP, esnekliği nedeniyle IoT ve sis katmanları arasında da kullanılan REST HTTP ile birlikte kullanılan ana protokollerden biridir.
Buradaki temel sorun, protokollerin birlikte çalışabilirliği ve mesajların bir protokolden diğerine aktarılmasının kolaylığıdır. İdeal olarak gelecekte, bulut ve sis kaynaklarına sahip bir Nesnelerin İnterneti sisteminin mimarisi, kullanılan iletişim protokolünden bağımsız olacak ve farklı protokoller arasında iyi bir birlikte çalışabilirlik sağlayacaktır.
Şu anda durum böyle olmadığından, önemli farkları olmayan protokolleri birleştirmek mantıklıdır. Bu amaçla, potansiyel bir çözüm, aynı mimari stili izleyen iki protokolün (REST HTTP ve CoAP) birleşimine dayanmaktadır. Önerilen başka bir çözüm, yayınlama-abone olma iletişimi sunan iki protokolün (MQTT ve AMQP) birleşimine dayanmaktadır. Benzer kavramların kullanılması (hem MQTT hem de AMQP aracıları kullanır, CoAP ve HTTP REST'i kullanır) bu kombinasyonların uygulanmasını kolaylaştırır ve daha az entegrasyon çabası gerektirir.
Şekil (a) iki istek-yanıt tabanlı modeli, HTTP ve CoAP'yi ve bunların bir IoT-F2C çözümüne olası yerleşimini göstermektedir. HTTP, modern ağlarda en iyi bilinen ve benimsenen protokollerden biri olduğundan, yerini tamamen diğer mesajlaşma protokollerinin alması pek olası değildir. Bulut ile sis arasında yer alan güçlü cihazları temsil eden düğümler arasında REST HTTP akıllı bir çözümdür.
Öte yandan Fog ve IoT katmanları arasında iletişim kuran sınırlı bilgi işlem kaynaklarına sahip cihazlar için CoAP kullanmak daha verimlidir. CoAP'ın en büyük avantajlarından biri aslında HTTP ile uyumluluğudur, çünkü her iki protokol de REST ilkelerine dayanmaktadır.
Şekil (b), MQTT ve AMQP dahil olmak üzere aynı senaryodaki iki yayınlama-abone olma iletişim modelini göstermektedir. Her ne kadar her iki protokol de varsayımsal olarak her soyutlama katmanındaki düğümler arasındaki iletişim için kullanılabilse de, konumları performansa göre belirlenmelidir. MQTT, sınırlı bilgi işlem kaynaklarına sahip cihazlar için hafif bir protokol olarak tasarlandığından IoT-Fog iletişimi için kullanılabilir. AMQP, onu ideal olarak sis ve bulut düğümleri arasında konumlandıracak daha güçlü cihazlar için daha uygundur. IoT'de hafif sayıldığı için MQTT yerine XMPP protokolü kullanılabilir. Ancak bu tür senaryolarda çok yaygın olarak kullanılmaz.
Bulgular
Tartışılan protokollerden birinin, sınırlı bilgi işlem kaynaklarına sahip cihazlardan bulut sunucularına kadar bir sistemdeki tüm iletişimi kapsamaya yeterli olması pek olası değildir. Çalışma, geliştiricilerin en çok kullandığı en umut verici iki seçeneğin MQTT ve RESTful HTTP olduğunu buldu. Bu iki protokol yalnızca en olgun ve istikrarlı olanlar değil, aynı zamanda birçok iyi belgelenmiş ve başarılı uygulamayı ve çevrimiçi kaynağı da içerir.
Kararlılığı ve basit konfigürasyonu nedeniyle MQTT, sınırlı cihazlarla IoT düzeyinde kullanıldığında üstün performansını zaman içinde kanıtlamış bir protokoldür. Bazı sis etki alanları ve çoğu bulut bilişim gibi sistemin sınırlı iletişim ve pil tüketiminin sorun olmadığı kısımlarında RESTful HTTP kolay bir seçimdir. CoAP'ın da bir IoT mesajlaşma standardı olarak hızla gelişmesi ve yakın gelecekte MQTT ve HTTP'ye benzer bir istikrar ve olgunluk düzeyine ulaşması muhtemel olması nedeniyle dikkate alınması gerekir. Ancak standart şu anda gelişiyor ve bu da kısa vadeli uyumluluk sorunlarını beraberinde getiriyor.
Blogda başka neler okuyabilirsiniz?
→
→
→
→
→
Abone olun -kanal böylece bir sonraki makaleyi kaçırmazsınız! Haftada en fazla iki kez ve yalnızca iş hakkında yazıyoruz.
Kaynak: habr.com