Rozwój technologii w obszarze oprogramowania i sprzętu oraz pojawienie się nowych protokołów komunikacyjnych przyczyniły się do rozszerzenia Internetu rzeczy (IoT). Liczba urządzeń rośnie z dnia na dzień, generując ogromne ilości danych. W związku z tym pojawia się potrzeba wygodnej architektury systemu, zdolnej do przetwarzania, przechowywania i przesyłania tych danych.
Obecnie do tych celów wykorzystywane są usługi chmurowe. Jednak coraz bardziej popularna paradigma obliczeń w chmurze Fog może uzupełniać rozwiązania chmurowe, skalując i optymalizując infrastrukturę IoT.
Chmury są w stanie zaspokoić większość zapotrzebowania IoT. Na przykład zapewniają monitoring usług, szybkie przetwarzanie wszelkich ilości danych generowanych przez urządzenia oraz ich wizualizację. Obliczenia w chmurze Fog są skuteczniejsze w rozwiązywaniu zadań w czasie rzeczywistym. Zapewniają szybki czas reakcji na zapytania oraz minimalne opóźnienia w przetwarzaniu danych. Oznacza to, że Fog uzupełnia chmury, rozszerzając ich możliwości.
Jednak główne pytanie brzmi: jak wszystko to ma współdziałać w kontekście IoT? Jakie protokoły komunikacyjne będą najskuteczniejsze w działającej zintegrowanej systemie IoT-Fog-Cloud?
Pomimo pozornego dominowania HTTP, w systemach IoT, Fog i Cloud używane jest wiele innych rozwiązań. Wyjaśnia to, że IoT musi łączyć funkcjonalności różnych czujników urządzeń z bezpieczeństwem, kompatybilnością oraz innymi wymaganiami stawianymi przez użytkowników.
Niemniej jednak, nie istnieje jednolite wyobrażenie o wzorcowej architekturze i standardzie komunikacji. Dlatego stworzenie nowego protokołu lub dostosowanie istniejącego do konkretnych zadań IoT jest jednym z najważniejszych zadań przed społecznością IT.
Jakie protokoły są obecnie używane i co mogą oferować? Zajmijmy się tym. Ale najpierw omówmy zasady ekosystemu, w którym współdziałają chmury, mgła i Internet rzeczy.
Architektura IoT Fog-to-Cloud (F2C)
Z pewnością zauważyliście, jak ogromne wysiłki są podejmowane w celu zbadania korzyści i zysków związanych z racjonalnym i skoordynowanym zarządzaniem IoT, chmurami i mgłą. Jeśli nie, oto trzy inicjatywy standaryzacyjne: , i .
Jeśli wcześniej rozważano tylko 2 poziomy, chmurę i urządzenia końcowe, to proponowana architektura wprowadza nowy poziom — obliczenia mgłowe. Poziom mgły może być podzielony na kilka podpoziomów, w zależności od specyfiki zasobów lub zestawu polityk określających użycie różnych urządzeń w tych podpoziomach.
Jak może wyglądać ta abstrakcja? Oto typowy ekosystem IoT-Mgła-Chmura. Urządzenia IoT przesyłają dane do bardziej wydajnych serwerów i urządzeń obliczeniowych, aby rozwiązywać zadania wymagające niskiego poziomu opóźnienia. W tym samym systemie chmury odpowiadają za zadania wymagające dużej mocy obliczeniowej lub miejsca na dane.
Smartfony, inteligentne zegarki i inne gadżety również mogą być częścią IoT. Jednak takie urządzenia zazwyczaj korzystają z zamkniętych protokołów komunikacyjnych od dużych producentów. Wygenerowane dane z Internetu rzeczy są przesyłane na poziom mgły za pomocą protokołu REST HTTP, który zapewnia elastyczność i funkcjonalną zgodność przy tworzeniu usług RESTful. Jest to istotne w świetle potrzeby zapewnienia zgodności wstecznej z istniejącą infrastrukturą obliczeniową działającą na lokalnych komputerach, serwerach lub w klastrze serwerów. Lokalne zasoby, nazywane "węzłami mgłowymi", filtrują otrzymane dane i przetwarzają je lokalnie lub przesyłają do chmury w celu dalszego przetwarzania.
Chmury obsługują różne protokoły komunikacyjne, z których najczęściej spotykane to AMQP i REST HTTP. Ponieważ HTTP jest powszechnie znane i zaprojektowane do pracy w Internecie, może pojawić się pytanie: „czy nie używać go do pracy z IoT i mgłą?”. Jednak ten protokół ma problemy z wydajnością. O tym później.
Ogólnie rzecz biorąc, istnieją 2 modele protokołów komunikacyjnych, które pasują do naszego systemu. Są to model żądanie-odpowiedź oraz model publikacja-subskrypcja. Pierwszy model jest szerzej znany, szczególnie w architekturze klient-serwer. Klient żąda informacji z serwera, a ten otrzymuje zapytanie, przetwarza je i zwraca wiadomość odpowiedzi. Protokoły REST HTTP i CoAP działają według tego modelu.
Druga model powstała w odpowiedzi na potrzebę zapewnienia asynchronicznego, rozproszonego, luźnego powiązania między źródłami generującymi dane a ich odbiorcami.
Model zakłada trzech uczestników: wydawcę (źródło danych), brokera (dispatcher) oraz subskrybenta (odbiorcę). Klient, pełniący rolę subskrybenta, nie musi pobierać informacji z serwera. Zamiast wysyłać zapytania, subskrybuje określone zdarzenia w systemie poprzez brokera, odpowiedzialnego za filtrowanie wszystkich przychodzących wiadomości i ich routowanie między wydawcami a subskrybentami. W momencie wystąpienia zdarzenia związanego z określonym tematem, wydawca publikuje je brokerowi, który przesyła dane subskrybentowi dotyczące zamówionego tematu.
W istocie ta architektura jest oparta na zdarzeniach. Taki model interakcji jest interesujący dla aplikacji w IoT, chmurze, fog computing, ze względu na swoją zdolność do zapewniania skalowalności oraz upraszczania komunikacji między różnymi urządzeniami, wspierania dynamicznej komunikacji „wiele do wielu” oraz asynchronicznej komunikacji. Do najbardziej znanych znormalizowanych protokołów wymiany wiadomości wykorzystujących model „publikacja-subskrypcja” można zaliczyć MQTT, AMQP i DDS.
Oczywiście model „publikacja-subskrypcja” ma wiele zalet:
- Wydawcy i subskrybenci nie muszą wiedzieć o swoim istnieniu;
- Jeden subskrybent może otrzymywać informacje od wielu różnych wydawców, a jeden wydawca może wysyłać dane do wielu różnych subskrybentów (zasada „wiele do wielu”);
- Wydawca i subskrybent nie muszą być jednocześnie aktywni do wymiany danych, ponieważ broker (działający jako system kolejek) może przechowywać wiadomość dla klientów, którzy w danym momencie nie są podłączeni do sieci.
Jednak model „zapytanie-odpowiedź” ma również swoje mocne strony. W przypadkach, gdy możliwości strony serwerowej do obsługi zapytań wielu klientów nie stanowią problemu, sensowne jest korzystanie z już sprawdzonych, niezawodnych rozwiązań.
Istnieją również protokoły, które wspierają oba modele. Na przykład XMPP i HTTP 2.0, które obsługują opcję „server push”. IETF wydało także CoAP. W próbie rozwiązania problemu wymiany wiadomości stworzono kilka innych rozwiązań, takich jak protokół WebSockets lub korzystanie z protokołu HTTP przez QUIC (Quick UDP Internet Connections).
W przypadku WebSockets, mimo że jest używany do przesyłania danych w czasie rzeczywistym z serwera do klienta internetowego i zapewnia stałe połączenia z jednoczesną dwukierunkową komunikacją, nie jest przeznaczony dla urządzeń o ograniczonych zasobach obliczeniowych. QUIC również zasługuje na uwagę, ponieważ nowy protokół transportowy daje wiele nowych możliwości. Jednak ponieważ QUIC nie został jeszcze sstandaryzowany, przedwczesne jest prognozowanie jego możliwego zastosowania i wpływu na rozwiązania w obszarze IoT. Tak więc WebSockets i QUIC zostawiamy w pamięci z myślą o przyszłości, ale na razie nie będziemy ich dokładniej badać.
Kto jest najmilsi na świecie: porównujemy protokoły
Teraz porozmawiajmy o mocnych i słabych stronach protokołów. Z góry zaznaczamy, że nie ma jednego wyraźnego lidera. Każdy protokół ma swoje zalety i wady.
Czas reakcji
Jedną z najważniejszych cech protokołów komunikacyjnych, szczególnie w kontekście Internetu rzeczy, jest czas reakcji. Jednak wśród istniejących protokołów nie ma bezwarunkowego zwycięzcy, który demonstruje minimalny poziom opóźnienia w różnych warunkach. Jest za to mnóstwo badań i porównań możliwości protokołów.
Na przykład, Porównania efektywności HTTP i MQTT w kontekście IoT pokazały, że czas reakcji dla zapytań w MQTT jest krótszy niż w HTTP. A przy czasu przyjęcia i transmisji (RTT) MQTT i CoAP ustalono, że średni RTT CoAP jest o 20% mniejszy niż w przypadku MQTT.
Inny Pomiar RTT dla protokołów MQTT i CoAP wykonano w dwóch scenariuszach: w lokalnej sieci i w sieci IoT. Okazało się, że średni RTT jest 2-3 razy wyższy w sieci IoT. MQTT z QoS0 wykazał gorszy wynik w porównaniu do CoAP, a MQTT z QoS1 pokazał wyższy RTT z powodu ACK na poziomie aplikacji i transportu. Dla różnych poziomów QoS opóźnienia w sieci bez przeciążenia dla MQTT wyniosły milisekundy, a dla CoAP — setki mikrosekund. Jednak warto pamiętać, że w mniej niezawodnych sieciach MQTT, działający na TCP, pokaże zupełnie inne wyniki.
Analiza czasu odpowiedzi protokołów AMQP i MQTT poprzez zwiększenie obciążenia pokazała, że przy małym obciążeniu poziom opóźnień jest prawie taki sam. Jednak przy przesyłaniu dużych zbiorów danych MQTT wykazuje mniejsze czasy odpowiedzi. W innym CoAP porównano z HTTP w scenariuszu komunikacji między maszynami z urządzeniami zainstalowanymi na pojazdach i wyposażonymi w czujniki gazu, czujniki pogody, lokalizację (GPS) oraz interfejs sieci mobilnej (GPRS). Czas potrzebny na przesłanie wiadomości CoAP przez sieć komórkową był prawie trzykrotnie krótszy niż czas potrzebny do użycia wiadomości HTTP.
Prowadzono badania, w których porównywano nie dwa, a trzy protokoły. Na przykład, wydajności protokołów IoT MQTT, DDS i CoAP w scenariuszu zastosowań medycznych z użyciem emulatora sieci. DDS przewyższył MQTT pod względem doświadczonego opóźnienia telemetrii w różnych złych warunkach sieciowych. CoAP oparty na UDP dobrze działał dla aplikacji, które wymagały szybkiej reakcji, jednak ze względu na to, że oparty jest na UDP, wystąpiła znaczna nieprzewidywalna utrata pakietów.
Przepustowość
MQTT i CoAP z punktu widzenia efektywności wykorzystania pasma przeprowadzono jako obliczenie całkowitej liczby danych przesyłanych w jednej wiadomości. CoAP wykazał mniejszą przepustowość niż MQTT przy przesyłaniu małych wiadomości. Jednak w porównaniu z efektywnością protokołów z punktu widzenia stosunku liczby użytecznych bajtów informacji do całkowitej liczby przesyłanych bajtów, CoAP okazał się bardziej efektywny.
Przy użycia pasma MQTT, DDS (z TCP jako protokołem transportowym) i CoAP ustalono, że CoAP zazwyczaj wykazuje stosunkowo niższe zużycie pasma, które nie wzrasta przy zwiększonej utracie pakietów sieciowych lub wydłużonym czasie oczekiwania w sieci, w przeciwieństwie do MQTT i DDS, gdzie w wymienionych scenariuszach odnotowano wzrost wykorzystania pasma. W innym scenariuszu zaangażowano dużą liczbę urządzeń przesyłających dane jednocześnie, co jest typowym przypadkiem w środowiskach IoT. Wyniki pokazały, że przy wyższym obciążeniu lepiej używać CoAP.
W przypadku niewielkiego obciążenia protokół CoAP wykorzystał najmniejszą przepustowość, a zaraz za nim znalazły się MQTT i REST HTTP. Jednak gdy rozmiar ładunków wzrastał, najlepsze wyniki osiągnął REST HTTP.
Zużycie energii
Kwestią zużycia energii zawsze ma ogromne znaczenie, a w systemach IoT — szczególnie. Jeśli zużycie energii w MQTT i HTTP, to HTTP zużywa znacznie więcej. Z kolei CoAP jest bardziej w porównaniu do MQTT, co pozwala na zarządzanie zasilaniem. W prostych scenariuszach MQTT lepiej nadaje się do wymiany informacji w sieciach internetu rzeczy, szczególnie gdy nie ma ograniczeń dotyczących mocy.
Eksperyment, podczas którego porównano możliwości AMQP i MQTT na stanowisku testowym w mobilnej lub niestabilnej sieci bezprzewodowej, wykazał, że AMQP oferuje większe możliwości w zakresie bezpieczeństwa, podczas gdy MQTT jest bardziej efektywny energetycznie.
Bezpieczeństwo
Bezpieczeństwo to kolejna istotna kwestia omawiana przy badaniach nad tematem internetu rzeczy i obliczeniami w chmurze/na krawędzi. Mechanizm bezpieczeństwa zazwyczaj oparty jest na TLS w HTTP, MQTT, AMQP i XMPP, lub DTLS w CoAP, a także obsługującym obie opcje DDS.
TLS i DTLS rozpoczynają się od procesu nawiązywania połączenia pomiędzy stroną klienta a serwera w celu wymiany wspieranych zestawów szyfrów i kluczy. Obie strony uzgadniają zestawy, aby zapewnić, że dalsza komunikacja odbywa się w bezpiecznym kanale. Różnica pomiędzy nimi polega na niewielkich modyfikacjach, które pozwalają DTLS, opartemu na UDP, działać w niestabilnym połączeniu.
Przy na kilku różnych implementacjach TLS i DTLS wykazało, że TLS lepiej poradził sobie z zadaniem. Ataki na DTLS były bardziej udane z powodu jego odporności na błędy.
Jednak największym problemem tych protokołów jest to, że pierwotnie nie zostały zaprojektowane do użytku w IoT i nie przewidywały pracy w chmurze ani na krawędzi. Poprzez uzgodnioną wymianę (handshaking) wprowadzają dodatkowy ruch przy każdym nawiązywaniu połączenia, co wyczerpuje zasoby obliczeniowe. Średnie zwiększenie wynosi 6,5% dla TLS i 11% dla DTLS w obciążeniu pomocniczym w porównaniu do połączenia bez poziomu bezpieczeństwa. W bogatych w zasoby środowiskach, które zazwyczaj znajdują się na na poziomie, nie będzie to problemem, ale w związku między IoT a poziomem mgły staje się to istotnym ograniczeniem.
Co wybrać? Nie ma jednoznacznej odpowiedzi. MQTT i HTTP wydają się najbardziej perspektywicznymi protokołami, gdyż są relatywnie bardziej dojrzałymi i stabilnymi rozwiązaniami dla IoT w porównaniu z innymi protokołami.
Rozwiązania oparte na jednolitym protokole komunikacyjnym
Praktyka jednoprotocolowego rozwiązania ma wiele wad. Na przykład, protokół, który działa w ograniczonej przestrzeni, może nie funkcjonować w domenie, dla której obowiązują surowe wymagania bezpieczeństwa. Mając to na uwadze, musimy odrzucić prawie wszystkie możliwe rozwiązania oparte na jednym protokole w ekosystemie Fog-to-Cloud w IoT, z wyjątkiem MQTT i REST HTTP.
REST HTTP jako rozwiązanie jednoprotocolowe
Istnieje dobry przykład interakcji zapytań i odpowiedzi REST HTTP w obszarze IoT-to-Fog: . Zwierzęta są wyposażone w noszone czujniki (klient IoT, C) i są zarządzane przez obliczenia w chmurze systemu inteligentnego rolnictwa (serwer Fog, S).
W nagłówku metody POST określany jest zasób do zmiany (\/farm\/animals) oraz wersja HTTP i typ zawartości, który w tym przypadku jest obiektem JSON, reprezentującym farmę zwierzęcą, którą ma zarządzać system (Dulcynea\/krowa). Odpowiedź z serwera wskazuje, że żądanie zostało zrealizowane pomyślnie, wysyłając kod stanu HTTPS 201 (zasób utworzony). Metoda GET powinna wskazywać jedynie żądany zasób w URI (na przykład \/farm\/animals\/1), który zwraca reprezentację JSON zwierzęcia o tym identyfikatorze z serwera.
Metoda PUT jest używana, gdy trzeba zaktualizować konkretny wpis zasobu. W tym przypadku w zasobie określa się URI dla parametru, który ma zostać zmieniony, oraz jego bieżącą wartość (na przykład wskazując, że krowa w danym momencie spaceruje, \/farm\/animals\/1?state=chodzenie). W końcu metoda DELETE jest używana na równi z metodą GET, ale po prostu usuwa zasób w wyniku operacji.
MQTT jako rozwiązanie jednoprotocolowe
We will take the same smart farm, but instead of REST HTTP, we will use the MQTT protocol. A local server with the Mosquitto library installed acts as the broker. In this example, a simple computer (designated as the farm server) Raspberry Pi serves as the MQTT client, implemented through the installation of the MQTT Paho library, fully compatible with the Mosquitto broker.
This client corresponds to the IoT abstraction level representing a device with detection and computation capabilities. The broker, on the other hand, corresponds to a higher level of abstraction, representing a fog computing node characterized by greater processing and data storage capabilities.
In the proposed 'smart farm' scenario, Raspberry Pi connects to an accelerometer, GPS, and temperature sensors, publishing data from these sensors to a fog node. As you may know, MQTT treats topics as a hierarchy. One MQTT publisher can publish messages in a specific set of topics. In our case, there are three. For the sensor measuring temperature in the animal shed, the client selects the topic (animalfarm/shed/temperature). For the sensors measuring GPS location and animal movement through the accelerometer, the client publishes updates (animalfarm/animal/GPS) and (animalfarm/animal/movement).
This information will be transmitted to the broker, which can temporarily store it in a local database in case another interested subscriber appears later.
In addition to the local server acting as the MQTT broker in the fog, to which Raspberry Pi, acting as MQTT clients, send data from sensors, there could be another MQTT broker at the cloud level. In this case, the information sent to the local broker can be temporarily stored in a local database and/or sent to the cloud. The fog MQTT broker in this situation is used to connect all data with the cloud MQTT broker. With this architecture, a mobile app user can be subscribed to both brokers.
W przypadku awarii połączenia z jednym z brokerów (np. chmurowym), użytkownik końcowy otrzyma informacje od innego brokera (fog). Jest to charakterystyczna cecha kombinowanych systemów chmury i fog computing. Domyślnie aplikacja mobilna może być skonfigurowana do pierwszego połączenia z brokera MQTT fog, a w przypadku niepowodzenia — do połączenia z brokerem MQTT w chmurze. To rozwiązanie jest tylko jednym z wielu w systemach IoT-F2C.
Rozwiązania wieloprotokołowe
Rozwiązania z jednym protokołem są popularne ze względu na łatwość ich wdrożenia. Jednak oczywiste jest, że w systemach IoT-F2C warto łączyć różne protokoły. Chodzi o to, że na różnych poziomach mogą działać różne protokoły. Weźmy na przykład trzy abstrakcje: poziomy IoT, fog i chmury obliczeniowej. Urządzenia na poziomie IoT zwykle uważane są za ograniczone. Do tego przeglądu rozważmy poziomy IoT jako najbardziej ograniczone, chmurowe jako najmniej ograniczone, a obliczenia fog jako „gdzieś pośrodku”. Tak więc między IoT a abstrakcjami fog bieżące rozwiązania protokołowe obejmują MQTT, CoAP i XMPP. Z drugiej strony, między fog a chmurą, AMQP jest jednym z głównych używanych protokołów wraz z REST HTTP, który dzięki swojej elastyczności jest również używany między IoT a warstwami fog.
Podstawowym problemem jest tutaj funkcjonalna zgodność protokołów oraz prostota translacji wiadomości z jednego protokołu na inny. W idealnym przypadku, w przyszłości architektura systemu Internetu rzeczy z zasobami chmurowymi i fog będzie niezależna od używanego protokołu komunikacyjnego i zapewni dobrą interakcję różnych protokołów.
Ponieważ na chwilę obecną tak nie jest, ma sens łączenie protokołów, które nie mają znaczących różnic. W tym celu jedno z potencjalnych rozwiązań opiera się na kombinacji dwóch protokołów, które trzymają się tego samego stylu architektonicznego, REST HTTP i CoAP. Inne proponowane rozwiązanie opiera się na połączeniu dwóch protokołów, które oferują interakcję w modelu „publikacja-subskrypcja”, MQTT i AMQP. Użycie bliskich koncepcji (zarówno MQTT, jak i AMQP wykorzystują brokerów, CoAP i HTTP używają REST), upraszcza realizację tych kombinacji i wymaga mniejszego wysiłku w integracji.
Na rysunku (a) przedstawione są dwa modele oparte na wymianie zapytań-odpowiedzi, HTTP i CoAP, oraz ich potencjalne umiejscowienie w rozwiązaniu IoT-F2C. Ponieważ HTTP jest jednym z najbardziej znanych i przystosowanych protokołów w nowoczesnych sieciach, mało prawdopodobne jest, że zostanie całkowicie zastąpione innymi protokołami komunikacyjnymi. Wśród węzłów, reprezentujących potężne urządzenia znajdujące się pomiędzy chmurą a mgłą, REST HTTP stanowi rozsądne rozwiązanie.
Z drugiej strony, dla urządzeń z ograniczonymi zasobami obliczeniowymi, które łączą się pomiędzy poziomami mgły a IoT, bardziej efektywne jest użycie CoAP. Jedną z głównych zalet CoAP jest jego kompatybilność z HTTP, ponieważ oba protokoły opierają się na zasadach REST.
Na rysunku (b) przedstawiono dwa modele interakcji „publikacja-subskrypcja” w jednym scenariuszu, w tym MQTT i AMQP. Chociaż hipotetycznie oba protokoły mogą być używane do komunikacji między węzłami na każdym poziomie abstrakcji, ich umiejscowienie powinno być określone na podstawie wydajności. MQTT został opracowany jako uproszczony protokół dla urządzeń z ograniczonymi zasobami obliczeniowymi, dlatego można go wykorzystać do komunikacji między IoT a mgłą. AMQP jest bardziej odpowiedni dla potężniejszych urządzeń, które idealnie umiejscowiłyby go pomiędzy węzłami mgły a chmurą. Zamiast MQTT w IoT można użyć protokołu XMPP, ponieważ uważa się go za lekki. Nie jest jednak tak szeroko stosowany w podobnych scenariuszach.
Wnioski
Mało prawdopodobne jest, żeby jeden z omówionych protokołów wystarczył do pokrycia całej komunikacji w systemie, zaczynając od urządzeń z ograniczonymi zasobami obliczeniowymi, a kończąc na serwerach chmurowych. Badania wykazały, że dwie najbardziej obiecujące opcje, które najczęściej wykorzystują deweloperzy, to MQTT i RESTful HTTP. Te dwa protokoły są nie tylko najbardziej dojrzałe i stabilne, ale również zawierają wiele dobrze udokumentowanych i udanych wdrożeń oraz zasobów online.
Dzięki swojej stabilności i łatwej konfiguracji, MQTT jest protokołem, który w trakcie czasu udowodnił swoją doskonałą wydajność przy użyciu na poziomie IoT w urządzeniach o ograniczonych zasobach. W częściach systemu, gdzie ograniczona łączność i zużycie energii nie stanowią problemu, na przykład w niektórych obszarach chmurowych i w większości obliczeń w chmurze, RESTful HTTP jest prostym wyborem. Należy również wziąć pod uwagę CoAP, ponieważ szybko rozwija się jako standard wymiany wiadomości IoT, i jest bardzo prawdopodobne, że w najbliższej przyszłości osiągnie poziom stabilności i dojrzałości porównywalny z MQTT i HTTP. Jednak standard obecnie się rozwija, co wiąże się z krótkoterminowymi problemami z kompatybilnością.
Co jeszcze ciekawego można przeczytać na blogu
→
→
→
→
→
Subskrybuj nasz -kanał, aby nie przegapić kolejnego artykułu! Piszemy nie częściej niż dwa razy w tygodniu i tylko w ważnych sprawach.
Źródło: habr.com
