Das World Wide Web bewegt unz\u00e4hligen 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\u00e4te 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\u00e4hrigen Entwicklungsevolution wurde es auf die Bed\u00fcrfnisse angepasst, und es erf\u00e4hrt auch weiterhin Anpassungen und Optimierungen, etwa in Form von HTTP\/2.<\/p>\n
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\u00fcr intelligente Klein- und Kleinstger\u00e4te andere Technologien zum Einsatz kommen.<\/p>\n
Ein Einsatzgebiet k\u00f6nnten beispielsweise Temperatur- und Luftfeuchtigkeitsmessungen im eigenen Zuhause sein. Im einfachen Fall k\u00f6nnen kleine Sensoren Werte messen und \u00fcber die lokale Internetanbindung (WLAN) an einen Backend-Service in die Cloud senden. Dabei m\u00fcssen 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 \u2013 sofern das Ger\u00e4te diese Informationen besitzt. Das ist ein Beispiel f\u00fcr eine reine Einweg-Kommunikation: Ger\u00e4t Richtung Cloud. Der Nutzer hat dann die M\u00f6glichkeit, sich \u00fcber eine Webseite beim Anbieter seine Messdaten anzusehen und auszuwerten.<\/p>\n
Ein komplexerer Fall ergibt sich, wenn vom Backend-Service in der Cloud Kommandos Richtung Ger\u00e4t abgegeben werden sollen, beispielsweise um bei zu hoher Temperatur einen L\u00fcfter anzustellen.<\/p>\n
Komplexit\u00e4t in anderer Richtung ergibt sich, wenn smarte Ger\u00e4te untereinander kommunizieren wollen. So kann der L\u00fcfter im Prinzip die Temperatur auch direkt beim Sensor anfragen, oder beide h\u00e4ngen an einem gemeinsamen Nachrichtenbus. Wie k\u00f6nnen sie Daten austauschen, vor allem wenn sie zuk\u00fcnftig vielleicht gar nicht mehr vom gleichen Hersteller stammen?<\/p>\n
Neben Fragen zu technischen Grundlagen (Erreichbarkeit, Adressierung, Vertrauensstellungen zwischen Ger\u00e4ten, IPv4\/IPv6, Netzwerkrouter und Firewalls) ergeben sich auch Herausforderungen auf Ebene der Protokoll- und Applikationsschichten: Wie erkennt ein Ger\u00e4t g\u00fcltige Anfragen, wie blockiert es ung\u00fcltige? Wie oft h\u00f6rt ein Ger\u00e4t auf Anfragen und wie synchronisieren sich Ger\u00e4t und Cloud in Bezug auf Anfrageh\u00e4ufigkeit und Zeitpunkte? Wieviel Ressourcen h\u00e4lt ein Ger\u00e4t zur Beantwortung von Anfragen vor?<\/p>\n
Smarte Ger\u00e4te des Internets der Dinge werden auch gerne als \u201eConstrained Devices\u201c bezeichnet. Das bedeutet, dass die Kleinger\u00e4te im Vergleich zu gewohnten Arbeitsmitteln wie Smartphone, Tablet oder Notebook nur sehr wenig Ressourcen besitzen, um ihre Arbeit zu verrichten. W\u00e4hrend in den gr\u00f6\u00dferen Ger\u00e4teklassen fast durchg\u00e4ngig 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.
\nHier gilt eine Ausstattung mit einem 32-bit Einkernprozessor und 1-2 Megabyte Speicher bereits als ordentlich. Das hat seine Begr\u00fcndung wie etwa im Stromverbrauch und im Preis: Wenn ein smartes Heizungsventil einen Verkaufspreis von z.B. 20 \u20ac haben soll, d\u00fcrfen sich die Kosten f\u00fcr den Prozessor nur im wirklich kleinstelligen Euro-Bereich bewegen. Und die Batterie soll das Ger\u00e4t m\u00f6glichst lange am Leben erhalten. Idealerweise erzeugen Ger\u00e4te durch Energy-Harvesting ihren Strom auch noch selber. Der Prozessor und die Anwendung, die er ausf\u00fchrt, sollen in allen Belangen m\u00f6glichst sparsam sein, und dazu z\u00e4hlt auch die Kommunikation in Netzwerken.<\/p>\n
Nun l\u00e4sst sich ein Web-Protokoll wie HTTP auch auf Kleinger\u00e4ten einsetzen. So gibt es z.B. im Bereich der Arduino-Boards viele Beispiele f\u00fcr smarte Sensoren, die ihren eigenen \u201eWebserver\u201c mitbringen. Der Benutzer kann seinen Browser auf die IP-Adresse des Ger\u00e4ts richten und Daten direkt in Form einer Webseite empfangen. Warum werden nicht alle Kleinger\u00e4te automatisch \u201eWebservices\u201c?<\/p>\n
Dazu lohnt es sich, die Arbeitsweise von HTTP etwas n\u00e4her zu beleuchten. Das Protokoll dient dazu, mit Webressourcen (z.B. Webseiten oder Formularen) auf einem Server zu interagieren. Dazu stehen mehrere Methoden zur Verf\u00fcgung. Die meisten Anfragen sind dazu da, Daten abzufragen (\u201eGET\u201c), mit anderen Anfragen lassen sich Daten \u00fcbertragen, etwa wenn im Online-Shop ein Bestellformular auszuf\u00fcllen ist (Methode \u201ePOST\u201c). Diese Methoden sind im Prinzip auch f\u00fcr Interaktion mit Ger\u00e4ten brauchbar: Entweder m\u00f6chte man Daten vom Ger\u00e4te haben (\u201eGET \/temperatur\u201c), oder man m\u00f6chte Dinge steuern (\u201ePOST \/luefter\/steuerung\u201c).\u00a0Allerdings gibt es mehrere Gr\u00fcnde, warum sich HTTP nicht gut f\u00fcr die Interaktion mit Constrained Devices eignet.<\/p>\n
Zum ersten ist HTTP ein aus Sicht der Ressourceneinschr\u00e4nkung eher geschw\u00e4tziges Protokoll. So werden z.B. Meta-Informationen wie die akzeptierten Formate oder die gew\u00fcnschte Sprache in Klartext-Form an Server \u00fcbermittelt. Der Header einer HTTP-Anfrage kann schon gro\u00df sein, und der Header einer HTTP-Antwort kann problemlos viele hundert Bytes Umfang besitzen. F\u00fcr die Abfrage einer Webseite mit mehreren Megabytes an Gr\u00f6\u00dfe ist das nicht schlimm, aber f\u00fcr die Abfrage eines Temperaturwertes im Umfang von ca. 5 Bytes ist es erheblich, ob das \u00dcbertragungsprotokoll schlank oder eher ausladend ist.<\/p>\n
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\u00fcr zwar Kennzeichungsfelder vor, aber Anbieter bem\u00fchen sich, auf Serverseite soviel Leistung aufzustellen, wie von den Kunden im Netz ben\u00f6tigt wird: Ein ganzer Branchenbereich k\u00fcmmert sich die schnelle und dezentrale Auslieferung von Webinhalten aus Caching-Farmen.<\/p>\n
Kleinger\u00e4te m\u00fcssen neben der Ausf\u00fchrung 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\u00e4t einen Knopf dr\u00fcckt, sollte eine Antwort in bestimmten Zeitrahmen erkennbar sein, nicht erst nach 5 Sekunden, etwa weil das Ger\u00e4t mit einer Webabfrage \u201ebesch\u00e4ftigt\u201c war. Protokolle f\u00fcr Constrained Devices m\u00fcssen dies ber\u00fccksichtigen, auch dass ein Ger\u00e4t eine Antwort liefern kann, aber erst in ein paar Sekunden (nachdem wichtigere Dinge abgearbeitet wurden).<\/p>\n
Es gibt auch technische Einschr\u00e4nkungen im Netzwerkbereich. HTTP setzt auf TCP auf, das Datenstrom-basierte \u00dcbertragungsverfahren im TCP\/IP-Stack. TCP verlangt unter anderem, dass Datenpakete mit Z\u00e4hlern ausgestattet sind, um im Zweifelsfall die Reihenfolge von eintreffenden Paketen richtigstellen zu k\u00f6nnen. Dazu ben\u00f6tigen TCP-Ger\u00e4te Puffer, um Pakete zwischen zu speichern und zu verwalten.<\/p>\n
Viele Kleinger\u00e4te nutzen daher UDP, das Datagramme einzeln abliefert und keine Garantie \u00fcber eine Zustellung oder die tats\u00e4chliche 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.<\/p>\n
In diese Bresche springt \u201eCoAP\u201c, das Constrained Application Protocol. Es handelt sich hierbei um ein spezialisiertes Transferprotokoll f\u00fcr eingeschr\u00e4nkte Ger\u00e4te und auch eingeschr\u00e4nkte Netzwerke, etwa mit niedrigen \u00dcbertragungsraten. Es dient prim\u00e4r als Protokoll f\u00fcr 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.<\/p>\n
CoAP ist in Bezug auf mehrere Aspekte nah an HTTP angelegt. So ist es im Kern ein Request-\/Response-Protokoll, d.h. ein (Ger\u00e4te-)Client stellt eine Anfrage an einen (Ger\u00e4te-)Server, und erh\u00e4lt eine Antwort. Es integriert die aus der Webwelt bekannten URIs, um Ressourcen zu benennen. Weiterhin \u00fcbernimmt es einen Teil der Abfragemethoden (wie \u201eGET\u201c, \u201ePUT\u201c, \u201ePOST\u201c, u.a.) und definiert Antwortcodes, die denen von HTTP \u00e4hnlich sind (z.B. 4.04 \u201eNot found\u201c wenn eine Ressource nicht gefunden werden konnte). Webentwickler, die mit HTTP aufgewachsen sind, k\u00f6nnen sich so sehr schnell auch mit CoAP zurechtfinden.<\/p>\n
Unterschiede ergeben sich vor allem im verwendeten Datenumfang. Im Gegensatz zum Plain-Text Format von HTTP, insbesondere des Headers, werden bei CoAP Codew\u00f6rter in Bytes bzw. auch einzelnen Bits einer Bin\u00e4rdarstellung verpackt. Es gibt Nachrichten, die eine Antwort verlangen (\u201eConfirmable\u201c), und solche die keine Antwort ben\u00f6tigen (\u201eNon-Confirmable\u201c). D.h. die Information \u00fcber die Verl\u00e4sslichkeit einer \u00dcbertragung 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\u00dfe sich als Non-Confirmable abbilden. Wenn ein smartes T\u00fcrschloss die T\u00fcr abschlie\u00dfen soll, ist die Nachricht dahinter sicherlich als \u201eConfirmable\u201c einzustufen.<\/p>\n
Durch mehrere dieser Ma\u00dfnahmen erreicht CoAP eine Kompaktheit, die mit HTTP in der Form nicht bzw. kaum m\u00f6glich w\u00e4re. So l\u00e4sst sich die Datenkommunikation zwischen Ger\u00e4ten durch CoAP in sinnvolle Steuerungsnachrichten mit wenigen Bytes verpacken.<\/p>\n
Die Asynchronit\u00e4t des Nachrichtenaustausches \u00fcber UDP gibt CoAP einem Ger\u00e4t au\u00dferdem die M\u00f6glichkeit, eine Anfrage ressourcenschonend mit Zeitverzug zu beantworten, sowie eine Antwort in mehreren kleinen (teilweise \u201ekleinsten\u201c) Bl\u00f6cken zu \u00fcbertragen. Letzteres ist gerade f\u00fcr verlustbehaftete Netzwerke mit kleinen Paketgr\u00f6\u00dfen wie etwa aus dem Funkbereich sehr sinnvoll.<\/p>\n
Eine weitere interessante Eigenschaft von CoAP ist das eingebaute Entdecken von Ressourcen (\u201eResource Discovery\u201c). \u00dcber diesen Mechanismus kann ein Ger\u00e4t \u00fcber die Daten-Endpunkte Auskunft geben, die es verwaltet. Im Beispiel eines Smart-Home Wettersensors gibt ein solche Ressource Discovery-Anfrage dann zur\u00fcck, dass es die aktuelle Temperatur unter dem Endpunkt \u201e\/temp\u201c, die Luftfeuchtigkeit unter \u201e\/hum\u201c und die Windrichtung unter \u201e\/wdir\u201c. Das Datenformat dieser Discovery-Antwort ist in dem separatem RFC 6690 (\u201eCoRE Link Format\u201c) beschrieben.<\/p>\n
Wie l\u00e4sst sich dieses Protokoll nun ausprobieren? Meist ist zuerst einmal gar nicht genau bekannt, welche Ger\u00e4te CoAP als Protokoll nutzen. F\u00fcr die ersten Schritte im Entwicklungsbereich ist das nicht schlimm, da CoAP auch durch Cloud-Services genutzt werden kann. Und hierf\u00fcr existieren Testzug\u00e4nge.<\/p>\n
Eine einfache M\u00f6glichkeit besteht darin, ein Add-On in den Firefox-Browser zu installieren. Das Plugin \u201eCopper\u201c, kurz „Cu“<\/a>, ist eine Erweiterung, dass in der Adresszeile des Browsers auf die Protokollkennung coap:\/\/ reagiert und daraufhin ein Fenster \u00f6ffnet, mit dem sich CoAP-Nachrichten austauschen und somit auch das Protokoll ausprobieren lassen. Ein Testzugang ist \u00fcber die URL coap:\/\/coap.me\/<\/a> m\u00f6glich. Dar\u00fcber lassen sich eine Reihe von Demo-Ressourcen eines Services abfragen und \u00fcber Resource Discovery auch entdecken.<\/p>\n Wer genauer in die Tiefen des Protokolls abtauchen m\u00f6chte, kann dazu das Netzwerk- und Protokollanalyse-Werkzeug Wireshark<\/a> installieren. Wireshark ist in der Lage, auf den Netzwerkschnittstellen eines PCs Daten abzuh\u00f6ren und die Protokolldetails aufzuschl\u00fcsseln. Damit lassen sich (z.B. in Verbindung mit Copper) Protokolleinstellungen und Zugriffsmethoden einfach visualisieren.<\/p>\n