Internet Of Things (IOT) – cz. 4: protokół CoAP

Dzisiaj chcemy dla Was kontynuować tematy związane z IOT, czyli Internetem rzeczy. Porozmawiamy sobie między innymi o innych protokołach, które występują w warstwie aplikacji i są związane z systemami IOT. Jeśli jesteście zainteresowani to zapraszamy do lektury!

Alternatywy do MQTT – protokół CoAP

Na rok 2023 najbardziej popularnym protokołem do urządzeń IOT jest MQTT, o którym pisaliśmy w ostatnim wpisie na blogu. Istnieją jednak alternatywy, które wykorzystywane są w specyficznych scenariuszach, gdzie MQTT nie może być zastosowane. 

Constrained Application Protocol to  protokół stworzony do działania na hardware, które z definicji jest ograniczone np. ze względu na małe zasoby pamięciowe czy obliczeniowe. Zaleca się go do urządzeń, które działają na bateriach ze względu właśnie na duże możliwości działania także na ograniczonych zasobach energii. Sam standard (RFC 7252) powstał w 2014 roku, więc jest stosunkowo nowym rozwiązaniem w porównaniu choćby do MQTT (1999). CoAP nadaje się do projektów IoT o większej skali oraz urządzeń bardziej ograniczonych pod względem zasilania. Posiada wiele cech charakterystycznych jeśli chodzi o techniczne aspekty, między innymi:

• Podobieństwo do HTTP/REST – CoAP posiada tak zwane Verbs (GET, POST etc.), które są takie same jak w przypadku protokołu HTTP.  Protokół HTTP nie za bardzo nadaje się jednak do urządzeń, gdzie trzeba informować klienta o zmianie pewnego stanu na serwerze (dlatego mówi się o HTTP, że jest bezstanowy). Jeśli dany protokół tego nie gwarantuje jak np. HTTP, wtedy klient zmuszony jest pytać o stan serwer np. co minutę lub co sekundę, co jest rozwiązaniem nieoptymalnym a czasem nieakceptowalnym. W tym Celu COAP wprowadza pewne unowocześnienia jeśli chodzi choćby o GET z flagą Observe:
  

• GET + Observe – Pozwala klientowi na ustanowienie kanału komunikacyjnego w czasie rzeczywistym, który umożliwia obserwowanie zmian w określonym zasobie na serwerze. Mechanizm ten jest podobny do subskrybowania aktualizacji lub zmian w zasobie i jest szczególnie przydatny w scenariuszach, w których chcesz monitorować dane z czujników lub inne dynamiczne informacje w sposób efektywny pod względem zasobów. Sesja klienta identyfikowana jest przez token.
  
  

Rysunek 1: datagram CoAP w programie Wireshark, widoczna flaga Observe, źródło: journals.sagepub.com

• Mechanizm discovery – CoAP oferuje mechanizm discovery pozwalający na odkrywanie dostępnych zasobów z którymi dane urządzenie może się skontaktować. Klient CoAP może wysłać multicastowe zapytanie (zwykle typu GET) na specjalny adres grupowy w celu znalezienia dostępnych zasobów w sieci. Urządzenia, które obsługują zasoby, odpowiadają na zapytanie, umożliwiając klientowi odkrywanie dostępnych RESTowych endpointów danego urządzenia. Takie odkrywanie endpointów nazywamy CORE Resource Discovery. Jest to część protokołu CoAP, która umożliwia klientowi odkrywanie zasobów w ramach jednego serwera CoAP, bez konieczności przeszukiwania całej sieci. Odkrywanie zasobów w ramach CORE polega na korzystaniu z specjalnych zasobów zwanych .well-known/core, które zawierają informacje o dostępnych zasobach na danym serwerze. Za pomocą zapytań GET do zasobu .well-known/core, klient może uzyskać listę dostępnych zasobów na tym serwerze w postaci adresu URI. Następnie po uzyskaniu takiej listy aplikacja może zacząć odpytywać endpointy.
  

• UDP z utrzymaniem binding pomiędzy urządzeniami – UDP jest protokołem bezpołączeniowym i nie zapewnia wbudowanych funkcji niezawodności, takich jak TCP (Transmission Control Protocol), ale CoAP radzi sobie z tym ograniczeniem za pomocą mechanizmów wbudowanych w sam protokół CoAP. Występuje co prawda także wersja protokołu korzystająca z TCP, ale natywnie mamy tylko UDP i mechanizm niezawodności zapewniony w warstwie aplikacji zamiast w warstwie transportowej. Wiadomość, która musi zostać dostarczona do danej storny jest oznaczana jako CON (Confirmable) i jest retransmitowana co pewien czas jeśli nie otrzyma potwierdzenia ACK (Acknowledgement). Inne typy wiadomości to NON (Non-confirmable) czy RST (Reset). Flagi podobne są nieco do tych występujących w TCP, ale zauważmy jednak, że w COAP niezawodność komunikacji zapewniona jest po stronie warstwy aplikacji, ponieważ korzysta on z UDP.
  

Rysunek 2: przykład potwierdzenia komunikacji od klienta do serwera w COAP, źródło: RFC7252

• Możliwość łatwego mapowania ze względu na podobieństwo do HTTP – ze względu na to, że oba protokoły opierają się na architekturze REST oraz korzystają z takich konceptów jak adresy URI do identyfikacji zasobu, czy operacji GET, POST, PUT etc. łatwo przechodzić z jednego typu komunikacji na drugi. Jest to znane jako proxying. CoAP-HTTP proxy  pozwala na konwersję żądań i odpowiedzi między CoAP a HTTP, co umożliwia integrację urządzeń i aplikacji działających w różnych środowiskach i technologiach.

Rysunek 3 – przejście pomiędzy HTTP i COAP za pomocą proxy, źródło: e2e.ti.com

• Działa dobrze na ograniczonych zasobach – CoAP jest protokołem lekkim, który wykorzystuje nawet pojedyncze bity do przesyłu informacji. Dzięki temu dobrze komponuje się w stosie sieciowym zarówno z użyciem klasycznego UDP/IP jak i UDP/6LowPan
  
  

Rysunek 4 – możliwy stos sieciowy urządzenia IOT korzystającego z CoAP, źródło: ARM Youtube

6LoWPAN to protokół będący poniżej warstwy transportowej i pozwalający na używanie IPv6 w niskonapięciowych sieciach bezprzewodowych. W połączeniu z CoAP (warstwa aplikacji) umożliwia on efektywną komunikację urządzeń IoT. Działa to poprzez dostosowanie pakietów IPv6 do ograniczeń takich sieci, używając adresów IPv6, kompresji nagłówków, fragmentacji, i umożliwiając tworzenie sieci mesh. CoAP, jako lekki protokół, idealnie wpasowuje się w 6LoWPAN, umożliwiając dostęp i zarządzanie zasobami urządzeń w środowiskach o ograniczonych zasobach. 

Rysunek 5 – schemat komunikacji pomiędzy urządzeniami z użyciem COAP oraz 6LoWPAN, źródło: lobaro.com

• Bezpieczeństwo – jeśli chodzi o bezpieczeństwo w CoAP to w przypadku klasycznego CoAP używającego UDP używa się DTLS (Datagram TLS), będącego TLS dla protokołu bezpołączeniowego UDP. Dzięki mechanizmom uwierzytelniania, serwery i klienci CoAP potrafią potwierdzać swoją tożsamość (np. poprzez certyfikaty), a mechanizmy autoryzacji pozwalają kontrolować dostęp do konkretnych zasobów. Jest to istotny aspekt w kontekście ochrony danych i zapewnienia bezpieczeństwa danych w aplikacjach CoAP.
  
  

CoAP posiada wiele więcej funkcjonalności, których nie zdołamy tutaj omówić. Mamy nadzieję jednak, że ten krótki artykuł pozwoli Wam na lepsze zrozumienie całości tematu jakim jest IOT.

Podsumowanie

Dzisiaj przedstawiliśmy wam alternatywę dla MQTT – protokół CoAP podobny do HTTP, efektywny na ograniczonych zasobach, bezpieczny z DTLS. Zachęcamy także do zapoznania się ze źródłami. Do usłyszenia za tydzień już w nowym temacie!

Źródła:

• https://www.lobaro.com/en/portfolio/coap-over-6lowpan-solutions/
• https://www.youtube.com/watch?v=4bSr5x5gKvA&t=1217s 
• https://journals.sagepub.com/doi/full/10.1177/1550147718772793
•  https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/495960/getting-started-with-coap-development