Rozwój technologii w zakresie oprogramowania i sprzętu, pojawienie się nowych protokołów komunikacyjnych doprowadziły do ekspansji Internetu Rzeczy (IoT). Liczba urządzeń rośnie z dnia na dzień i generują one ogromne ilości danych. Dlatego istnieje zapotrzebowanie na wygodną architekturę systemu zdolną do przetwarzania, przechowywania i przesyłania tych danych.
Teraz do tych celów wykorzystywane są usługi w chmurze. Jednak coraz popularniejszy paradygmat mgły obliczeniowej (Fog) może uzupełniać rozwiązania chmurowe poprzez skalowanie i optymalizację infrastruktury IoT.
Chmury są w stanie obsłużyć większość żądań IoT. Na przykład w celu zapewnienia monitorowania usług, szybkiego przetwarzania dowolnej ilości danych generowanych przez urządzenia, a także ich wizualizacji. Obliczenia mgły są bardziej skuteczne przy rozwiązywaniu problemów w czasie rzeczywistym. Zapewniają szybką reakcję na żądania i minimalne opóźnienia w przetwarzaniu danych. Oznacza to, że mgła uzupełnia „chmury” i rozszerza swoje możliwości.
Jednak główne pytanie jest inne: jak to wszystko powinno współdziałać w kontekście IoT? Jakie protokoły komunikacyjne będą najskuteczniejsze podczas pracy w połączonym systemie IoT-Fog-Cloud?
Pomimo widocznej dominacji protokołu HTTP, istnieje duża liczba innych rozwiązań stosowanych w systemach IoT, Fog i Cloud. Dzieje się tak, ponieważ IoT musi łączyć funkcjonalność różnych czujników urządzeń z bezpieczeństwem, kompatybilnością i innymi wymaganiami użytkowników.
Ale po prostu nie ma jednego pomysłu na architekturę referencyjną i standard komunikacji. Dlatego stworzenie nowego protokołu lub modyfikacja istniejącego pod konkretne zadania IoT to jedno z najważniejszych zadań stojących przed społecznością IT.
Jakie protokoły są obecnie w użyciu i co mogą zaoferować? Rozwiążmy to. Ale najpierw omówmy zasady ekosystemu, w którym chmury, mgła i Internet rzeczy oddziałują na siebie.
Architektura IoT typu Fog-to-Cloud (F2C).
Prawdopodobnie zauważyłeś, ile wysiłku wkłada się w badanie zalet i korzyści związanych z inteligentnym i skoordynowanym zarządzaniem IoT, chmurą i mgłą. Jeśli nie, oto trzy inicjatywy normalizacyjne: , и .
Jeżeli wcześniej brano pod uwagę tylko 2 poziomy, chmury i urządzenia końcowe, to proponowana architektura wprowadza nowy poziom – obliczenia mgłowe. W tym przypadku poziom mgły można podzielić na kilka podpoziomów, w zależności od specyfiki zasobów lub zestawu zasad określających użycie różnych urządzeń na tych podpoziomach.
Jak może wyglądać ta abstrakcja? Oto typowy ekosystem IoT-Fog-Cloud. Urządzenia IoT wysyłają dane do szybszych serwerów i urządzeń komputerowych, aby rozwiązywać problemy wymagające małych opóźnień. W tym samym systemie chmury odpowiadają za rozwiązywanie problemów wymagających dużej ilości zasobów obliczeniowych lub miejsca na przechowywanie danych.
Smartfony, inteligentne zegarki i inne gadżety również mogą być częścią Internetu Rzeczy. Ale takie urządzenia z reguły korzystają z zastrzeżonych protokołów komunikacyjnych dużych programistów. Wygenerowane dane IoT przesyłane są do warstwy mgły za pośrednictwem protokołu HTTP REST, który zapewnia elastyczność i interoperacyjność podczas tworzenia usług RESTful. Jest to istotne w świetle konieczności zapewnienia kompatybilności wstecznej z istniejącą infrastrukturą obliczeniową działającą na lokalnych komputerach, serwerach czy klastrze serwerów. Lokalne zasoby, zwane „węzłami mgły”, filtrują otrzymane dane i przetwarzają je lokalnie lub wysyłają do chmury w celu dalszych obliczeń.
Chmury obsługują różne protokoły komunikacyjne, z których najpopularniejsze to AMQP i REST HTTP. Ponieważ protokół HTTP jest dobrze znany i dostosowany do potrzeb Internetu, może pojawić się pytanie: „czy nie powinniśmy go używać do pracy z IoT i mgłą?” Jednak ten protokół ma problemy z wydajnością. Więcej na ten temat później.
Ogólnie rzecz biorąc, istnieją 2 modele protokołów komunikacyjnych odpowiednich dla systemu, którego potrzebujemy. Są to żądanie-odpowiedź i publikacja-subskrypcja. Pierwszy model jest szerzej znany, szczególnie w architekturze serwer-klient. Klient żąda informacji od serwera, a serwer odbiera żądanie, przetwarza je i zwraca komunikat odpowiedzi. W tym modelu działają protokoły REST HTTP i CoAP.
Drugi model powstał z potrzeby zapewnienia asynchronicznego, rozproszonego, luźnego sprzężenia pomiędzy źródłami generującymi dane a odbiorcami tych danych.
Model zakłada trzech uczestników: wydawcę (źródło danych), brokera (dyspozytor) i abonenta (odbiorca). Tutaj klient występujący w roli abonenta nie musi żądać informacji od serwera. Zamiast wysyłać żądania, subskrybuje określone zdarzenia w systemie za pośrednictwem brokera, który odpowiada za filtrowanie wszystkich przychodzących wiadomości i kierowanie ich pomiędzy wydawcami i subskrybentami. Natomiast wydawca, gdy wystąpi jakieś zdarzenie dotyczące określonego tematu, publikuje je brokerowi, który przesyła dane na żądany temat do subskrybenta.
Zasadniczo ta architektura jest oparta na zdarzeniach. Ten model interakcji jest interesujący w zastosowaniach w IoT, chmurze i mgle ze względu na jego zdolność do zapewniania skalowalności i upraszczania wzajemnych połączeń między różnymi urządzeniami, wspierania dynamicznej komunikacji wiele do wielu i komunikacji asynchronicznej. Do najbardziej znanych standardowych protokołów przesyłania wiadomości korzystających z modelu publikowania i subskrybowania należą MQTT, AMQP i DDS.
Oczywiście model publikowania i subskrybowania ma wiele zalet:
- Wydawcy i subskrybenci nie muszą wiedzieć o swoim istnieniu;
- Jeden subskrybent może otrzymywać informacje z wielu różnych publikacji, a jeden wydawca może przesyłać dane do wielu różnych subskrybentów (zasada wiele do wielu);
- Wydawca i abonent nie muszą być jednocześnie aktywni, aby się komunikować, ponieważ broker (działający jako system kolejkowy) będzie mógł przechowywać wiadomość dla klientów, którzy nie są aktualnie podłączeni do sieci.
Jednak model żądanie-odpowiedź ma również swoje mocne strony. W przypadkach, gdy zdolność strony serwera do obsługi wielu żądań klientów nie stanowi problemu, warto skorzystać ze sprawdzonych, niezawodnych rozwiązań.
Istnieją również protokoły obsługujące oba modele. Na przykład XMPP i HTTP 2.0, które obsługują opcję „server push”. IETF również opublikował CoAP. Próbując rozwiązać problem przesyłania wiadomości, stworzono kilka innych rozwiązań, takich jak protokół WebSockets czy wykorzystanie protokołu HTTP przez QUIC (Quick UDP Internet Connections).
W przypadku WebSockets, choć służy do przesyłania danych w czasie rzeczywistym z serwera do klienta WWW i zapewnia trwałe połączenia z jednoczesną komunikacją dwukierunkową, nie jest przeznaczony dla urządzeń o ograniczonych zasobach obliczeniowych. Na uwagę zasługuje także QUIC, gdyż nowy protokół transportowy daje mnóstwo nowych możliwości. Ponieważ jednak QUIC nie został jeszcze ujednolicony, jest przedwczesne przewidywanie jego możliwego zastosowania i wpływu na rozwiązania IoT. Dlatego też pamiętamy o WebSockets i QUIC, patrząc w przyszłość, ale na razie nie będziemy się nimi zajmować bardziej szczegółowo.
Kto jest najsłodszy na świecie: porównanie protokołów
Porozmawiajmy teraz o mocnych i słabych stronach protokołów. Patrząc w przyszłość, od razu zastrzegajmy, że nie ma jednego wyraźnego lidera. Każdy protokół ma pewne zalety/wady.
Czas odpowiedzi
Jedną z najważniejszych cech protokołów komunikacyjnych, zwłaszcza w odniesieniu do Internetu rzeczy, jest czas odpowiedzi. Jednak wśród istniejących protokołów nie ma wyraźnego zwycięzcy, który wykazałby minimalny poziom opóźnienia podczas pracy w różnych warunkach. Ale istnieje cała masa badań i porównań możliwości protokołów.
Naprzykład porównania efektywności HTTP i MQTT w pracy z IoT wykazały, że czas odpowiedzi na żądania MQTT jest krótszy niż w przypadku HTTP. I kiedy Czas podróży w obie strony (RTT) MQTT i CoAP ujawnił, że średni RTT CoAP jest o 20% krótszy niż MQTT.
Inny z RTT dla protokołów MQTT i CoAP przeprowadzono w dwóch scenariuszach: sieci lokalnej oraz sieci IoT. Okazało się, że w sieci IoT średni RTT jest 2-3 razy wyższy. MQTT z QoS0 wykazało niższy wynik w porównaniu z CoAP, a MQTT z QoS1 wykazało wyższy RTT ze względu na ACK w warstwach aplikacji i transportu. Dla różnych poziomów QoS opóźnienie sieci bez przeciążenia wynosiło milisekundy dla MQTT i setki mikrosekund dla CoAP. Warto jednak pamiętać, że pracując w mniej niezawodnych sieciach, MQTT uruchomiony na TCP pokaże zupełnie inny wynik.
czas odpowiedzi dla protokołów AMQP i MQTT poprzez zwiększenie ładunku pokazał, że przy niewielkim obciążeniu poziom opóźnienia jest prawie taki sam. Jednak przy przesyłaniu dużych ilości danych MQTT wykazuje krótsze czasy odpowiedzi. w jeszcze jednym CoAP porównano z protokołem HTTP w scenariuszu komunikacji maszyna-maszyna z urządzeniami rozmieszczonymi na pojazdach wyposażonych w czujniki gazu, czujniki pogodowe, czujniki lokalizacji (GPS) i interfejs sieci komórkowej (GPRS). Czas potrzebny na przesłanie komunikatu CoAP przez sieć komórkową był prawie trzykrotnie krótszy niż czas potrzebny na wykorzystanie komunikatów HTTP.
Przeprowadzono badania, w których porównano nie dwa, ale trzy protokoły. Na przykład, wydajność protokołów IoT MQTT, DDS i CoAP w scenariuszu aplikacji medycznej z wykorzystaniem emulatora sieciowego. DDS osiągnął lepsze wyniki niż MQTT pod względem przetestowanego opóźnienia telemetrii w różnych złych warunkach sieciowych. CoAP oparty na UDP działał dobrze w aplikacjach wymagających szybkiego czasu reakcji, jednak ze względu na to, że był oparty na UDP, występowała znaczna, nieprzewidywalna utrata pakietów.
Przepustowość
MQTT i CoAP pod względem wydajności pasma przeprowadzono jako obliczenie całkowitej ilości danych przesyłanych w jednym komunikacie. CoAP wykazał niższą przepustowość niż MQTT podczas przesyłania małych wiadomości. Jednak porównując wydajność protokołów pod względem stosunku liczby użytecznych bajtów informacji do całkowitej liczby przesłanych bajtów, CoAP okazał się bardziej skuteczny.
w wykorzystując MQTT, DDS (z TCP jako protokołem transportowym) i przepustowość CoAP, stwierdzono, że CoAP ogólnie wykazywał stosunkowo mniejsze zużycie przepustowości, które nie wzrastało wraz ze zwiększoną utratą pakietów sieciowych lub zwiększonym opóźnieniem sieci, w przeciwieństwie do MQTT i DDS, gdzie występowało wzrost wykorzystania przepustowości w wymienionych scenariuszach. Inny scenariusz zakładał jednoczesne przesyłanie danych przez dużą liczbę urządzeń, co jest typowe w środowiskach IoT. Wyniki pokazały, że w celu uzyskania większego wykorzystania lepiej jest zastosować CoAP.
Przy niewielkim obciążeniu najmniejszą przepustowość wykorzystywał CoAP, a następnie MQTT i REST HTTP. Jednak gdy rozmiar ładunku wzrósł, najlepsze wyniki uzyskał protokół REST HTTP.
Pobór mocy
Kwestia zużycia energii zawsze ma ogromne znaczenie, a szczególnie w systemie IoT. Jeśli Podczas gdy protokoły MQTT i HTTP zużywają energię elektryczną, protokół HTTP zużywa znacznie więcej. A CoAP to coś więcej w porównaniu do MQTT, umożliwiając zarządzanie energią. Jednak w prostych scenariuszach protokół MQTT jest bardziej odpowiedni do wymiany informacji w sieciach Internetu rzeczy, zwłaszcza jeśli nie ma ograniczeń mocy.
Eksperyment porównujący możliwości AMQP i MQTT na stanowisku testowym mobilnej lub niestabilnej sieci bezprzewodowej wykazał, że AMQP oferuje większe możliwości bezpieczeństwa, podczas gdy MQTT jest bardziej energooszczędny.
bezpieczeństwo
Bezpieczeństwo to kolejna kluczowa kwestia poruszana podczas studiowania tematu Internetu rzeczy i przetwarzania w chmurze/mgły. Mechanizm bezpieczeństwa opiera się zazwyczaj na TLS w HTTP, MQTT, AMQP i XMPP lub DTLS w CoAP i obsługuje oba warianty DDS.
TLS i DTLS rozpoczynają się od procesu nawiązania komunikacji pomiędzy klientem a serwerem w celu wymiany obsługiwanych zestawów szyfrów i kluczy. Obie strony negocjują zestawy, aby dalsza komunikacja odbywała się w bezpiecznym kanale. Różnica między nimi polega na niewielkich modyfikacjach, które pozwalają DTLS opartemu na UDP pracować na zawodnym połączeniu.
w Kilka różnych implementacji TLS i DTLS wykazało, że TLS wykonał lepszą robotę. Ataki na DTLS były skuteczniejsze ze względu na jego tolerancję na błędy.
Jednak największym problemem związanym z tymi protokołami jest to, że nie zostały pierwotnie zaprojektowane do użytku w IoT i nie były przeznaczone do pracy we mgle lub chmurze. Uzgadnianie powoduje zwiększenie ruchu przy każdym nawiązaniu połączenia, co wyczerpuje zasoby obliczeniowe. Średnio wzrost narzutu w przypadku protokołu TLS wynosi 6,5% i 11% w przypadku protokołu DTLS w porównaniu z komunikacją bez warstwy zabezpieczeń. W środowiskach bogatych w zasoby, które zazwyczaj znajdują się na poziomie, nie będzie to stanowić problemu, ale w połączeniu pomiędzy IoT a poziomem mgły staje się to istotnym ograniczeniem.
Co wybrać? Nie ma jasnej odpowiedzi. Najbardziej obiecującymi protokołami wydają się MQTT i HTTP, ponieważ uważa się je za stosunkowo bardziej dojrzałe i stabilniejsze rozwiązania IoT w porównaniu z innymi protokołami.
Rozwiązania oparte na ujednoliconym protokole komunikacyjnym
Praktyka stosowania rozwiązania opartego na jednym protokole ma wiele wad. Na przykład protokół odpowiedni w ograniczonym środowisku może nie działać w domenie o rygorystycznych wymaganiach dotyczących bezpieczeństwa. Mając to na uwadze, pozostaje nam odrzucić prawie wszystkie możliwe rozwiązania jednoprotokołowe w ekosystemie Fog-to-Cloud w IoT, z wyjątkiem MQTT i REST HTTP.
REST HTTP jako rozwiązanie jednoprotokołowe
Istnieje dobry przykład interakcji żądań i odpowiedzi HTTP REST w przestrzeni IoT-to-Fog: . Zwierzęta są wyposażone w czujniki do noszenia (klient IoT, C) i kontrolowane za pomocą przetwarzania w chmurze przez inteligentny system hodowlany (serwer Fog, S).
Nagłówek metody POST określa zasób do modyfikacji (/farm/animals) oraz wersję HTTP i typ zawartości, którym w tym przypadku jest obiekt JSON reprezentujący hodowlę zwierząt, którą system ma zarządzać (Dulcynea/krowa) . Odpowiedź z serwera wskazuje, że żądanie powiodło się, wysyłając kod stanu HTTPS 201 (utworzono zasób). Metoda GET musi określać tylko żądany zasób w identyfikatorze URI (na przykład /farm/animals/1), co zwraca z serwera reprezentację JSON zwierzęcia o tym identyfikatorze.
Metodę PUT stosuje się, gdy trzeba zaktualizować jakiś konkretny rekord zasobu. W tym przypadku zasób określa URI parametru, który ma zostać zmieniony, oraz aktualną wartość (np. wskazując, że krowa aktualnie idzie, /farm/animals/1? stan=chodzi). Na koniec metoda DELETE jest używana na równi z metodą GET, ale po prostu usuwa zasób w wyniku operacji.
MQTT jako rozwiązanie jednoprotokołowe
Weźmy tę samą inteligentną farmę, ale zamiast REST HTTP używamy protokołu MQTT. Lokalny serwer z zainstalowaną biblioteką Mosquitto pełni rolę brokera. W tym przykładzie prosty komputer (zwany serwerem farmy) Raspberry Pi pełni rolę klienta MQTT, realizowanego poprzez instalację biblioteki Paho MQTT, która jest w pełni kompatybilna z brokerem Mosquitto.
Ten klient odpowiada warstwie abstrakcji IoT reprezentującej urządzenie z możliwościami wykrywania i przetwarzania. Mediator natomiast odpowiada wyższemu poziomowi abstrakcji, reprezentując węzeł obliczeniowy mgły charakteryzujący się większą pojemnością przetwarzania i przechowywania.
W proponowanym scenariuszu inteligentnej farmy Raspberry Pi łączy się z akcelerometrem, GPS i czujnikami temperatury oraz publikuje dane z tych czujników do węzła mgły. Jak zapewne wiesz, MQTT traktuje tematy jako hierarchię. Pojedynczy wydawca MQTT może publikować wiadomości dotyczące określonego zestawu tematów. W naszym przypadku jest ich trzech. W przypadku czujnika mierzącego temperaturę w oborze klient wybiera temat (farma zwierząt/obora/temperatura). W przypadku czujników mierzących lokalizację GPS i ruch zwierząt za pomocą akcelerometru klient opublikuje aktualizacje (farma zwierząt/zwierzę/GPS) i (farma zwierząt/zwierzę/ruch).
Informacje te zostaną przekazane brokerowi, który może je tymczasowo zapisać w lokalnej bazie danych na wypadek późniejszego pojawienia się kolejnego zainteresowanego abonenta.
Oprócz lokalnego serwera, który we mgle pełni rolę brokera MQTT i do którego Raspberry Pis, pełniąc rolę klientów MQTT, przesyła dane z czujników, na poziomie chmury może działać jeszcze jeden broker MQTT. W takim przypadku informacje przekazywane lokalnemu brokerowi mogą zostać tymczasowo zapisane w lokalnej bazie danych i/lub przesłane do chmury. Broker mgły MQTT w tej sytuacji służy do powiązania wszystkich danych z brokerem MQTT w chmurze. Dzięki tej architekturze użytkownik aplikacji mobilnej może subskrybować oba brokery.
Jeżeli połączenie z jednym z brokerów (np. chmurą) nie powiedzie się, użytkownik końcowy otrzyma informację od drugiego (mgła). Jest to cecha charakterystyczna połączonych systemów mgłowych i chmur obliczeniowych. Domyślnie aplikację mobilną można skonfigurować tak, aby najpierw łączyła się z brokerem mgły MQTT, a jeśli to się nie powiedzie, łączyła się z brokerem MQTT w chmurze. To rozwiązanie jest tylko jednym z wielu w systemach IoT-F2C.
Rozwiązania wieloprotokołowe
Rozwiązania jednoprotokołowe cieszą się popularnością ze względu na łatwiejszą implementację. Ale jasne jest, że w systemach IoT-F2C sensowne jest łączenie różnych protokołów. Pomysł jest taki, że różne protokoły mogą działać na różnych poziomach. Weźmy na przykład trzy abstrakcje: warstwy IoT, mgłę i przetwarzanie w chmurze. Urządzenia na poziomie IoT są ogólnie uważane za ograniczone. Na potrzeby tego przeglądu rozważmy warstwy IoT jako najbardziej ograniczone, chmurę najmniej, a mgłę obliczeniową jako „gdzieś pośrodku”. Okazuje się wtedy, że pomiędzy IoT a abstrakcją mgły, obecne rozwiązania protokołów obejmują MQTT, CoAP i XMPP. Z drugiej strony, pomiędzy mgłą a chmurą, AMQP jest jednym z głównych używanych protokołów, wraz z REST HTTP, który ze względu na swoją elastyczność jest również używany między warstwami IoT i mgły.
Głównym problemem jest tutaj interoperacyjność protokołów i łatwość przesyłania komunikatów z jednego protokołu na drugi. Idealnie byłoby, gdyby w przyszłości architektura systemu Internetu rzeczy z zasobami chmury i mgły była niezależna od stosowanego protokołu komunikacyjnego i zapewniała dobrą interoperacyjność pomiędzy różnymi protokołami.
Ponieważ obecnie tak nie jest, sensowne jest łączenie protokołów, które nie różnią się znacząco. W tym celu jedno potencjalne rozwiązanie opiera się na kombinacji dwóch protokołów zgodnych z tym samym stylem architektonicznym, REST HTTP i CoAP. Kolejne proponowane rozwiązanie opiera się na połączeniu dwóch protokołów oferujących komunikację typu publikacja-subskrypcja, MQTT i AMQP. Stosowanie podobnych koncepcji (zarówno MQTT, jak i AMQP korzystają z brokerów, CoAP i HTTP korzystają z REST) sprawia, że te kombinacje są łatwiejsze do wdrożenia i wymagają mniejszego wysiłku integracyjnego.
Rysunek (a) przedstawia dwa modele oparte na żądaniu i odpowiedzi, HTTP i CoAP, oraz ich możliwe umieszczenie w rozwiązaniu IoT-F2C. Ponieważ HTTP jest jednym z najbardziej znanych i przyjętych protokołów we współczesnych sieciach, jest mało prawdopodobne, że zostanie całkowicie zastąpiony przez inne protokoły przesyłania wiadomości. Wśród węzłów reprezentujących potężne urządzenia znajdujące się pomiędzy chmurą a mgłą, REST HTTP jest inteligentnym rozwiązaniem.
Z kolei w przypadku urządzeń o ograniczonych zasobach obliczeniowych, które komunikują się pomiędzy warstwami Fog i IoT, bardziej efektywne jest wykorzystanie CoAP. Jedną z największych zalet CoAP jest w rzeczywistości jego kompatybilność z HTTP, ponieważ oba protokoły opierają się na zasadach REST.
Rysunek (b) przedstawia dwa modele komunikacji typu publikacja-subskrypcja w tym samym scenariuszu, w tym MQTT i AMQP. Chociaż oba protokoły mogłyby hipotetycznie być używane do komunikacji między węzłami w każdej warstwie abstrakcji, ich położenie powinno być określane na podstawie wydajności. MQTT został zaprojektowany jako lekki protokół dla urządzeń o ograniczonych zasobach obliczeniowych, dzięki czemu może być używany do komunikacji IoT-Fog. AMQP jest bardziej odpowiedni dla mocniejszych urządzeń, co idealnie umieściłoby go pomiędzy węzłami mgły i chmur. Zamiast MQTT w IoT można stosować protokół XMPP, ponieważ uważa się go za lekki. Ale nie jest tak powszechnie stosowany w takich scenariuszach.
odkrycia
Jest mało prawdopodobne, aby któryś z omawianych protokołów wystarczył do obsługi całej komunikacji w systemie, od urządzeń o ograniczonych zasobach obliczeniowych po serwery w chmurze. Badanie wykazało, że dwie najbardziej obiecujące opcje, z których najczęściej korzystają programiści, to MQTT i RESTful HTTP. Te dwa protokoły są nie tylko najbardziej dojrzałe i stabilne, ale obejmują także wiele dobrze udokumentowanych i udanych wdrożeń oraz zasobów online.
Ze względu na swoją stabilność i prostą konfigurację, MQTT jest protokołem, który z biegiem czasu udowodnił swoją doskonałą wydajność, gdy jest używany na poziomie IoT z ograniczoną liczbą urządzeń. W częściach systemu, w których ograniczona komunikacja i zużycie baterii nie stanowią problemu, takich jak niektóre domeny mgły i większość przetwarzania w chmurze, RESTful HTTP jest łatwym wyborem. Należy również wziąć pod uwagę CoAP, ponieważ szybko ewoluuje on również jako standard przesyłania wiadomości IoT i prawdopodobne jest, że w najbliższej przyszłości osiągnie poziom stabilności i dojrzałości podobny do MQTT i HTTP. Jednak standard obecnie ewoluuje, co wiąże się z krótkotrwałymi problemami ze zgodnością.
Co jeszcze można przeczytać na blogu?
→
→
→
→
→
Zapisz się do naszego -channel, żeby nie przegapić kolejnego artykułu! Piszemy nie częściej niż dwa razy w tygodniu i tylko w sprawach służbowych.
Źródło: www.habr.com