Applikationsprotokolle für das Internet der Dinge

Das Internet der Dinge wächst rasant. Millionen wenn nicht gar Milliarden neue Geräte werden in den kommenden Jahren weltweit vernetzt. Das stellt das Internet vor neue Herausforderungen. Das World Wide Web ist aufgrund seiner Architektur und Technologien gut für Wachstum und Skalierung gerüstet. Aber wie sieht es beim Internet der Dinge aus?

Das World Wide Web bewegt unzähligen Arten von Daten und Informationen: Webseiten, Bilder, Filme, Audio- und Videostreams, Applikationen und vieles mehr. Wir stehen dabei auf der Nachfrageseite, in dem wir Browser, Smartphones oder Musikgeräte bedienen, die Inhalte von Anbietern im Netz nachladen. Dabei kommen eine Vielzahl von spezialisierten Applikationsprotokollen zum Einsatz. Das vermutlich bekannteste darunter ist HTTP, das Hypertext Transfer Protocol. In einer langjährigen Entwicklungsevolution wurde es auf die Bedürfnisse angepasst, und es erfährt auch weiterhin Anpassungen und Optimierungen, etwa in Form von HTTP/2.

Im Internet der Dinge werden ebenfalls Unmengen an Daten und Informationen bewegt, allerdings unterscheidet sich die Charakteristik der Daten hierbei deutlich. Deshalb ist es naheliegend, dass für intelligente Klein- und Kleinstgeräte andere Technologien zum Einsatz kommen.

Datencharakteristik im Internet der Dinge ist komplexer

Ein Einsatzgebiet könnten beispielsweise Temperatur- und Luftfeuchtigkeitsmessungen im eigenen Zuhause sein. Im einfachen Fall können kleine Sensoren Werte messen und über die lokale Internetanbindung (WLAN) an einen Backend-Service in die Cloud senden. Dabei müssen die Sensoren keine komplexen Datenobjekte erstellen, im Prinzip reichen die Rohdaten (Temperatur in Grad Celsius und Luftfeuchtigkeit in Prozent), die sich ggf. noch mit Strukturen oder Metadaten (z.B. Zeitpunkt) anreichern lassen – sofern das Geräte diese Informationen besitzt. Das ist ein Beispiel für eine reine Einweg-Kommunikation: Gerät Richtung Cloud. Der Nutzer hat dann die Möglichkeit, sich über eine Webseite beim Anbieter seine Messdaten anzusehen und auszuwerten.

Ein komplexerer Fall ergibt sich, wenn vom Backend-Service in der Cloud Kommandos Richtung Gerät abgegeben werden sollen, beispielsweise um bei zu hoher Temperatur einen Lüfter anzustellen.

Komplexität in anderer Richtung ergibt sich, wenn smarte Geräte untereinander kommunizieren wollen. So kann der Lüfter im Prinzip die Temperatur auch direkt beim Sensor anfragen, oder beide hängen an einem gemeinsamen Nachrichtenbus. Wie können sie Daten austauschen, vor allem wenn sie zukünftig vielleicht gar nicht mehr vom gleichen Hersteller stammen?

Neben Fragen zu technischen Grundlagen (Erreichbarkeit, Adressierung, Vertrauensstellungen zwischen Geräten, IPv4/IPv6, Netzwerkrouter und Firewalls) ergeben sich auch Herausforderungen auf Ebene der Protokoll- und Applikationsschichten: Wie erkennt ein Gerät gültige Anfragen, wie blockiert es ungültige? Wie oft hört ein Gerät auf Anfragen und wie synchronisieren sich Gerät und Cloud in Bezug auf Anfragehäufigkeit und Zeitpunkte? Wieviel Ressourcen hält ein Gerät zur Beantwortung von Anfragen vor?

Smarte Geräte des Internets der Dinge werden auch gerne als „Constrained Devices“ bezeichnet. Das bedeutet, dass die Kleingeräte im Vergleich zu gewohnten Arbeitsmitteln wie Smartphone, Tablet oder Notebook nur sehr wenig Ressourcen besitzen, um ihre Arbeit zu verrichten. Während in den größeren Geräteklassen fast durchgängig 64-bit Mehrkernprozessoren im Gigahertz-Bereich ihren Dienst tun und mit mehreren Gigabyte an Speicher ausgestattet sind, geht es im Bereich der Smart Devices eher beschaulich zu.
Hier gilt eine Ausstattung mit einem 32-bit Einkernprozessor und 1-2 Megabyte Speicher bereits als ordentlich. Das hat seine Begründung wie etwa im Stromverbrauch und im Preis: Wenn ein smartes Heizungsventil einen Verkaufspreis von z.B. 20 € haben soll, dürfen sich die Kosten für den Prozessor nur im wirklich kleinstelligen Euro-Bereich bewegen. Und die Batterie soll das Gerät möglichst lange am Leben erhalten. Idealerweise erzeugen Geräte durch Energy-Harvesting ihren Strom auch noch selber. Der Prozessor und die Anwendung, die er ausführt, sollen in allen Belangen möglichst sparsam sein, und dazu zählt auch die Kommunikation in Netzwerken.

Webprotokolle im Internet der Dinge

Nun lässt sich ein Web-Protokoll wie HTTP auch auf Kleingeräten einsetzen. So gibt es z.B. im Bereich der Arduino-Boards viele Beispiele für smarte Sensoren, die ihren eigenen „Webserver“ mitbringen. Der Benutzer kann seinen Browser auf die IP-Adresse des Geräts richten und Daten direkt in Form einer Webseite empfangen. Warum werden nicht alle Kleingeräte automatisch „Webservices“?

Dazu lohnt es sich, die Arbeitsweise von HTTP etwas näher zu beleuchten. Das Protokoll dient dazu, mit Webressourcen (z.B. Webseiten oder Formularen) auf einem Server zu interagieren. Dazu stehen mehrere Methoden zur Verfügung. Die meisten Anfragen sind dazu da, Daten abzufragen („GET“), mit anderen Anfragen lassen sich Daten übertragen, etwa wenn im Online-Shop ein Bestellformular auszufüllen ist (Methode „POST“). Diese Methoden sind im Prinzip auch für Interaktion mit Geräten brauchbar: Entweder möchte man Daten vom Geräte haben („GET /temperatur“), oder man möchte Dinge steuern („POST /luefter/steuerung“). Allerdings gibt es mehrere Gründe, warum sich HTTP nicht gut für die Interaktion mit Constrained Devices eignet.

HTTP: Nicht unbedingt für Kleinstgeräte geeignet

Zum ersten ist HTTP ein aus Sicht der Ressourceneinschränkung eher geschwätziges Protokoll. So werden z.B. Meta-Informationen wie die akzeptierten Formate oder die gewünschte Sprache in Klartext-Form an Server übermittelt. Der Header einer HTTP-Anfrage kann schon groß sein, und der Header einer HTTP-Antwort kann problemlos viele hundert Bytes Umfang besitzen. Für die Abfrage einer Webseite mit mehreren Megabytes an Größe ist das nicht schlimm, aber für die Abfrage eines Temperaturwertes im Umfang von ca. 5 Bytes ist es erheblich, ob das Übertragungsprotokoll schlank oder eher ausladend ist.

Weiterhin wird im Webbereich im Kern nicht davon ausgegangen, dass eine Ressource (z.B. eine Webseite) in kurzen Abschnitten nicht ausgeliefert werden kann. HTTP sieht dafür zwar Kennzeichungsfelder vor, aber Anbieter bemühen sich, auf Serverseite soviel Leistung aufzustellen, wie von den Kunden im Netz benötigt wird: Ein ganzer Branchenbereich kümmert sich die schnelle und dezentrale Auslieferung von Webinhalten aus Caching-Farmen.

Kleingeräte müssen neben der Ausführung von Netzwerkprotokollen auch noch andere Dinge tun. So muss im Smart-Home-Beispiel die Temperatur von entsprechenden Bausteinen auch ausgelesen und umgerechnet werden. Und wenn der Nutzer am Gerät einen Knopf drückt, sollte eine Antwort in bestimmten Zeitrahmen erkennbar sein, nicht erst nach 5 Sekunden, etwa weil das Gerät mit einer Webabfrage „beschäftigt“ war. Protokolle für Constrained Devices müssen dies berücksichtigen, auch dass ein Gerät eine Antwort liefern kann, aber erst in ein paar Sekunden (nachdem wichtigere Dinge abgearbeitet wurden).

Es gibt auch technische Einschränkungen im Netzwerkbereich. HTTP setzt auf TCP auf, das Datenstrom-basierte Übertragungsverfahren im TCP/IP-Stack. TCP verlangt unter anderem, dass Datenpakete mit Zählern ausgestattet sind, um im Zweifelsfall die Reihenfolge von eintreffenden Paketen richtigstellen zu können. Dazu benötigen TCP-Geräte Puffer, um Pakete zwischen zu speichern und zu verwalten.

Viele Kleingeräte nutzen daher UDP, das Datagramme einzeln abliefert und keine Garantie über eine Zustellung oder die tatsächliche Reihenfolge macht. Dadurch wird die Implementierung schlanker und ressourcenschonender. Leider passt HTTP nicht auf UDP, neuere Protokolle wie QUIC setzen auf UDP auf, sind aber noch nicht so weit verbreitet.

Das Constrained Application Protocol (CoAP)

In diese Bresche springt „CoAP“, das Constrained Application Protocol. Es handelt sich hierbei um ein spezialisiertes Transferprotokoll für eingeschränkte Geräte und auch eingeschränkte Netzwerke, etwa mit niedrigen Übertragungsraten. Es dient primär als Protokoll für die Maschine-zu-Maschine-Kommunikation, und nicht zur Interaktion an einer Benutzerschnittstelle. CoAP ist durch die Internet Engineering Task Force (IETF) im RFC 7252 (und weiteren) spezifiziert.

CoAP vs HTTP: Wo liegen die Gemeinsamkeiten, wo die Unterschiede?

CoAP ist in Bezug auf mehrere Aspekte nah an HTTP angelegt. So ist es im Kern ein Request-/Response-Protokoll, d.h. ein (Geräte-)Client stellt eine Anfrage an einen (Geräte-)Server, und erhält eine Antwort. Es integriert die aus der Webwelt bekannten URIs, um Ressourcen zu benennen. Weiterhin übernimmt es einen Teil der Abfragemethoden (wie „GET“, „PUT“, „POST“, u.a.) und definiert Antwortcodes, die denen von HTTP ähnlich sind (z.B. 4.04 „Not found“ wenn eine Ressource nicht gefunden werden konnte). Webentwickler, die mit HTTP aufgewachsen sind, können sich so sehr schnell auch mit CoAP zurechtfinden.

Unterschiede ergeben sich vor allem im verwendeten Datenumfang. Im Gegensatz zum Plain-Text Format von HTTP, insbesondere des Headers, werden bei CoAP Codewörter in Bytes bzw. auch einzelnen Bits einer Binärdarstellung verpackt. Es gibt Nachrichten, die eine Antwort verlangen („Confirmable“), und solche die keine Antwort benötigen („Non-Confirmable“). D.h. die Information über die Verlässlichkeit einer Übertragung wird auf die Applikationslage gehoben, und kann durch die Anwendung im Einzelfall unterschieden werden. Wenn beispielsweise ein Temperatursensor 1x pro Minute die Temperatur sendet, kann ein Ausfall einer einzelnen Nachricht verschmerzt werden, sie ließe sich als Non-Confirmable abbilden. Wenn ein smartes Türschloss die Tür abschließen soll, ist die Nachricht dahinter sicherlich als „Confirmable“ einzustufen.

Durch mehrere dieser Maßnahmen erreicht CoAP eine Kompaktheit, die mit HTTP in der Form nicht bzw. kaum möglich wäre. So lässt sich die Datenkommunikation zwischen Geräten durch CoAP in sinnvolle Steuerungsnachrichten mit wenigen Bytes verpacken.

Die Asynchronität des Nachrichtenaustausches über UDP gibt CoAP einem Gerät außerdem die Möglichkeit, eine Anfrage ressourcenschonend mit Zeitverzug zu beantworten, sowie eine Antwort in mehreren kleinen (teilweise „kleinsten“) Blöcken zu übertragen. Letzteres ist gerade für verlustbehaftete Netzwerke mit kleinen Paketgrößen wie etwa aus dem Funkbereich sehr sinnvoll.

Eine weitere interessante Eigenschaft von CoAP ist das eingebaute Entdecken von Ressourcen („Resource Discovery“). Über diesen Mechanismus kann ein Gerät über die Daten-Endpunkte Auskunft geben, die es verwaltet. Im Beispiel eines Smart-Home Wettersensors gibt ein solche Ressource Discovery-Anfrage dann zurück, dass es die aktuelle Temperatur unter dem Endpunkt „/temp“, die Luftfeuchtigkeit unter „/hum“ und die Windrichtung unter „/wdir“. Das Datenformat dieser Discovery-Antwort ist in dem separatem RFC 6690 („CoRE Link Format“) beschrieben.

CoAP ausprobieren

Wie lässt sich dieses Protokoll nun ausprobieren? Meist ist zuerst einmal gar nicht genau bekannt, welche Geräte CoAP als Protokoll nutzen. Für die ersten Schritte im Entwicklungsbereich ist das nicht schlimm, da CoAP auch durch Cloud-Services genutzt werden kann. Und hierfür existieren Testzugänge.

Eine einfache Möglichkeit besteht darin, ein Add-On in den Firefox-Browser zu installieren. Das Plugin „Copper“, kurz „Cu“, ist eine Erweiterung, dass in der Adresszeile des Browsers auf die Protokollkennung coap:// reagiert und daraufhin ein Fenster öffnet, mit dem sich CoAP-Nachrichten austauschen und somit auch das Protokoll ausprobieren lassen. Ein Testzugang ist über die URL coap://coap.me/ möglich. Darüber lassen sich eine Reihe von Demo-Ressourcen eines Services abfragen und über Resource Discovery auch entdecken.

Wer genauer in die Tiefen des Protokolls abtauchen möchte, kann dazu das Netzwerk- und Protokollanalyse-Werkzeug Wireshark installieren. Wireshark ist in der Lage, auf den Netzwerkschnittstellen eines PCs Daten abzuhören und die Protokolldetails aufzuschlüsseln. Damit lassen sich (z.B. in Verbindung mit Copper) Protokolleinstellungen und Zugriffsmethoden einfach visualisieren.

Um Applikationen zu entwickeln, die miteinander CoAP sprechen, lohnt sich ein Blick auf die Webseite. Sie stellt die Implementierungsleistungen rund um CoAP ansprechend zusammen. So sind über 30 Implementierungen für verschiedene Sprachen und Laufzeitumgebungen aufgelistet, sodass Entwickler hier für die eigenen Experimente etwas Passendes finden können.

Fazit

Damit der Internet der Dinge im Rahmen von eingeschränkten Geräten und eingeschränkten Netzwerken wachsen kann, müssen die Applikationen auf Geräten sparsam mit den Ressourcen umgehen. Schlanke Kommunikationslösungen sind gefragt, und neben MQTT als nachrichtenbasiertem Protokoll steht Entwicklern CoAP mit seinem ans Web bzw. HTTP angelehnten Request/Response-Protokoll in den Startlöchern. Beide haben spezifische Einsatzzwecke und Stärken, und wir sind gespannt, wie diese Protokolle in der Zukunft der IoT eingesetzt werden.