CoAP
CoAP ist «HTTP für winzige Geräte»: RESTful über UDP mit 4-Byte-Header.
Der Aufbau: links ein CoAP-Client (eine App oder ein Gateway), rechts ein winziger Sensorknoten als Server mit den Ressourcen /sensor/temp und /led. Dazwischen läuft alles über UDP.
In 30 Sekunden
CoAP (Constrained Application Protocol) überträgt das aus dem Web bekannte Prinzip auf sehr kleine Geräte: Man spricht Ressourcen über eine Adresse (URI) an und liest oder ändert sie mit den vier Befehlen GET, PUT, POST und DELETE – genau wie ein Webbrowser eine Seite abruft. Anders als HTTP läuft CoAP aber über das schlanke UDP statt über TCP und hat einen winzigen 4-Byte-Kopf. Dadurch ist es sparsam genug für batteriebetriebene Sensoren und funktioniert auch in langsamen, verlustbehafteten Funknetzen. Weil das Modell dem Web so ähnlich ist, lässt sich CoAP unkompliziert zu HTTP übersetzen und in bestehende Web-Infrastruktur einbinden.
Stell dir HTTP wie einen ausführlichen Brief mit Umschlag, Anrede und Grussformel vor – zuverlässig, aber schwer. CoAP ist die Postkarte davon: dieselbe Sprache und dieselben Höflichkeitsformen (GET, PUT, POST, DELETE), nur radikal eingedampft, damit sie auch ein winziges Gerät mit fast leerer Batterie noch verschicken kann. Man kann sogar «bitte Empfang bestätigen» ankreuzen – oder es einfach weglassen, wenn es nicht so wichtig ist.
Wo trifft man CoAP an?
Batteriebetriebene Sensoren
Kleine Messfühler, die jahrelang mit einer Knopfzelle laufen sollen, sparen mit dem winzigen CoAP-Header Funkzeit und damit Strom. Beispiel: Ein Temperaturfühler in einem Lagerraum meldet über CoAP alle paar Minuten seinen Wert und schläft dazwischen.
Funknetze mit wenig Bandbreite (6LoWPAN)
CoAP wurde für IPv6-Funknetze über 802.15.4 (6LoWPAN) entworfen, in denen Pakete klein und Verluste normal sind. Beispiel: Ein Mesh-Netz aus Sensorknoten in einem Gebäude, in dem jedes Gerät nur wenige Kilobit pro Sekunde schafft.
Gebäude- und Smart-Home-Automation
Leuchten, Thermostate und Schalter stellen ihren Zustand als abfragbare Ressource bereit. Beispiel: Eine Steuerung liest per GET den aktuellen Sollwert eines Thermostats und setzt ihn per PUT auf einen neuen Wert.
Zustandsüberwachung mit Push (OBSERVE)
Statt ständig nachzufragen, abonniert ein Client eine Ressource und bekommt Änderungen automatisch geschickt. Beispiel: Ein Gateway abonniert einen Türkontakt und erhält nur dann eine Nachricht, wenn sich «offen/geschlossen» wirklich ändert.
Anbindung an Web und Cloud über Proxy
Ein CoAP-HTTP-Proxy übersetzt zwischen der Geräte-Welt und normalen Webdiensten. Beispiel: Ein Cloud-Backend spricht über HTTPS mit einem Proxy, der die Anfragen als CoAP an die Sensoren im Feld weiterreicht.
Industrielle Ferndiagnose (LwM2M)
Das Geräteverwaltungs-Protokoll LwM2M (Lightweight M2M) setzt auf CoAP auf, um Firmware, Konfiguration und Zustand vieler Geräte zu verwalten. Beispiel: Ein Netzbetreiber liest über LwM2M/CoAP den Batteriestand und die Firmware-Version tausender Zähler aus.
Gut geeignet für
- Für stark eingeschränkte Geräte mit wenig RAM, Rechenleistung und Batterie, weil der 4-Byte-Header und UDP kaum Ressourcen verbrauchen.
- Für verlustbehaftete Funknetze mit kleiner Bandbreite (z. B. 6LoWPAN), weil CoAP von Grund auf für kleine Pakete und gelegentliche Paketverluste ausgelegt ist.
- Für Web-nahe Architekturen, weil das RESTful-Modell (GET/PUT/POST/DELETE auf URIs) direkt zu HTTP passt und sich per Proxy einfach überbrücken lässt.
- Für ereignisgetriebene Überwachung, weil die OBSERVE-Erweiterung Änderungen aktiv pusht, statt das Gerät ständig abfragen zu lassen – das spart Strom und Funkzeit.
- Für Massen-Geräteverwaltung, weil etablierte Standards wie LwM2M auf CoAP aufsetzen und Firmware-Updates und Konfiguration standardisiert abbilden.
Weniger geeignet für
- Für die zuverlässige Übertragung grosser Datenmengen (Bilder, Logs, Streams), weil UDP dafür nicht gemacht ist; besser passt hier HTTP über TCP oder MQTT.
- Für stark entkoppelte Ereignis-Verteilung an viele Abnehmer, weil CoAP im Kern Request/Response ist und keinen zentralen Broker hat; besser passt hier MQTT mit Publish/Subscribe.
- Für harte Maschinen-Echtzeit im Millisekunden-Takt, weil CoAP darauf nicht ausgelegt ist; besser passen hier PROFINET oder EtherCAT.
- Für Umgebungen, in denen UDP durch Firewalls oder NAT blockiert wird, weil CoAP dann schlecht durchkommt; besser passt hier ein TCP-basiertes Protokoll oder CoAP über TCP/WebSocket (RFC 8323).
Fakten
- Constrained Application Protocol
- IETF RFC 7252 (2014); OBSERVE: RFC 7641; Block-Wise: RFC 7959
- UDP (optional TCP/TLS/WebSocket per RFC 8323)
- 5683 (CoAP), 5684 (CoAPs, mit DTLS)
- 4 Byte fester Basis-Header (sehr kompakt, binär)
- GET, POST, PUT, DELETE (RESTful, auf Ressourcen-URIs)
- Confirmable (CON, mit ACK), Non-Confirmable (NON), Acknowledgement (ACK), Reset (RST)
- DTLS (CoAPs); objektbasiert per OSCORE (RFC 8613)
Im Detail
REST wie im Web – nur winzig
CoAP überträgt das Grundprinzip des Webs auf Kleinstgeräte: Jede Information ist eine Ressource mit einer Adresse (URI, z. B. coap://gerät/sensor/temperatur), und man greift mit denselben vier Verben darauf zu wie ein Browser: GET zum Lesen, PUT und POST zum Ändern oder Anlegen, DELETE zum Löschen. Auch die Antwort-Codes lehnen sich an HTTP an. Wer HTTP kennt, findet sich sofort zurecht – nur ist alles kompakt binär codiert statt als langer Text.
Warum UDP statt TCP
HTTP nutzt TCP, das vor jeder Übertragung eine Verbindung aufbaut und Datenströme zuverlässig sortiert – das kostet Speicher, Rechenzeit und Funkzeit. CoAP setzt stattdessen auf das verbindungslose UDP, bei dem jedes Paket einzeln und ohne Vorgeplänkel verschickt wird. Das ist deutlich leichtgewichtiger und passt zu Geräten, die nur kurz aufwachen, etwas senden und wieder schlafen.
Zuverlässigkeit nach Bedarf: CON und NON
Weil UDP von sich aus keine Zustellung garantiert, baut CoAP eine leichte Absicherung selbst ein. Eine Confirmable-Nachricht (CON) muss vom Empfänger mit einem ACK bestätigt werden; bleibt die Bestätigung aus, wird erneut gesendet. Eine Non-Confirmable-Nachricht (NON) wird dagegen «abgefeuert und vergessen» – ideal für häufige Messwerte, bei denen ein einzelner Ausfall egal ist. So kann jede Anwendung selbst wählen, wie viel Zuverlässigkeit sie braucht.
OBSERVE: Der Server meldet sich von selbst
Normalerweise fragt der Client eine Ressource ab (Polling). Mit der OBSERVE-Erweiterung (RFC 7641) abonniert er sie stattdessen einmalig, und der Server schickt bei jeder Änderung von sich aus eine neue Antwort. Das spart Funkverkehr und Strom, weil überflüssige Abfragen entfallen – besonders wertvoll, wenn sich ein Wert selten ändert, die Änderung aber schnell ankommen soll.
Grosse Daten in Blöcken
UDP-Pakete sollen klein bleiben, damit sie in engen Funknetzen nicht fragmentiert werden. Reicht eine Nutzlast dafür nicht aus, zerlegt der Block-Wise Transfer (RFC 7959) sie in nummerierte Häppchen, die nacheinander übertragen und beim Empfänger wieder zusammengesetzt werden. So lassen sich auch grössere Inhalte wie ein Firmware-Update über CoAP schicken, ohne die kleinen Paketgrenzen zu sprengen.
Sicherheit: DTLS und OSCORE
Verschlüsselt läuft CoAP als «CoAPs» über DTLS, die UDP-Variante von TLS, auf Port 5684 (unverschlüsselt: 5683). Wo Nachrichten über Proxies laufen und Ende-zu-Ende geschützt bleiben sollen, gibt es zusätzlich OSCORE (RFC 8613), das nicht den Kanal, sondern die einzelne Nachricht absichert – so kann ein Proxy weiterleiten, ohne den Inhalt lesen zu können.
Abgrenzung zu MQTT
CoAP und MQTT sind beide beliebte IoT-Protokolle, verfolgen aber verschiedene Muster. CoAP ist Request/Response wie das Web: Ein Client fragt gezielt eine Ressource ab oder ändert sie, dazu kommt mit OBSERVE ein Abo-Mechanismus. MQTT arbeitet dagegen über einen zentralen Broker nach dem Publish/Subscribe-Prinzip und entkoppelt Sender und Empfänger stärker. Grob: CoAP passt gut, wenn man Geräte direkt und web-artig ansprechen will; MQTT passt gut, wenn viele Abnehmer lose an Datenströme angebunden werden sollen.