Die Wahl des Kommunikationsprotokolls entscheidet über den Energieverbrauch, den Durchsatz und die Kosten einer gesamten IoT-Implementierung. Das CoAP-Protokoll (Constrained Application Protocol) wurde genau für Geräte mit begrenzten Ressourcen entwickelt — Mikrocontroller mit einigen Dutzend Kilobyte RAM und Batteriebetrieb —, die in unzuverlässigen Netzwerken mit geringem Durchsatz arbeiten. In diesem Leitfaden erklären wir, wie das CoAP-Protokoll funktioniert, wie man es absichert und in welchen Szenarien es sich besser bewährt als MQTT.
Kurz gesagt: CoAP ist ein leichtgewichtiges, auf UDP basierendes Request/Response-Protokoll im REST-Modell (Methoden GET, POST, PUT, DELETE), das für ressourcenbeschränkte IoT-Geräte entwickelt wurde. Setzen Sie es dort ein, wo minimaler Energieverbrauch, ein geringer Header-Overhead (4 Byte) und die direkte Kommunikation mit dem Sensor zählen; MQTT wählen Sie für Telemetrie im Publish/Subscribe-Modell über unzuverlässige Verbindungen.
Was ist das CoAP-Protokoll?
CoAP ist ein Standard für die Anwendungskommunikation im Internet der Dinge, beschrieben im Dokument RFC 7252 und von der IETF entwickelt. CoAP bildet die aus dem WWW bekannte REST-Architektur ab, jedoch für Maschinen, die mit begrenzten Ressourcen arbeiten (engl. constrained devices). Jeder Sensor oder Aktor ist hier ein Server, der Ressourcen unter URI-Adressen bereitstellt, z. B. coap://sensor.local/temperatur.
Der entscheidende Unterschied gegenüber dem klassischen HTTP liegt im Transport. Statt TCP verwendet CoAP UDP, was den Overhead des Verbindungsaufbaus eliminiert und es ermöglicht, den gesamten Header in nur 4 Byte unterzubringen. Zum Vergleich: Ein HTTP/1.1-Header umfasst üblicherweise Hunderte von Byte — der Unterschied schlägt sich direkt in der Batterielaufzeit und den Übertragungskosten in Mobilfunknetzen nieder.
Wie funktioniert das CoAP-Protokoll?
CoAP arbeitet im Request/Response-Modell auf UDP-Basis und nutzt dieselben Methoden wie REST: GET, POST, PUT und DELETE. Da UDP die Zustellung nicht garantiert, sorgt die CoAP-Schicht selbst über zwei Nachrichtentypen für Zuverlässigkeit.
- Confirmable (CON) — eine Nachricht, die eine Bestätigung (ACK) erfordert; trifft das ACK nicht ein, überträgt der Sender die Nachricht mit exponentiellem Backoff erneut (standardmäßig ab ca. 2 Sekunden).
- Non-confirmable (NON) — eine Nachricht ohne Bestätigung, ideal für Ströme häufiger Messwerte, bei denen der Verlust einer einzelnen Probe keine Rolle spielt.
Eine wichtige Erweiterung ist der Observe-Mechanismus (RFC 7641): Der Client registriert eine Beobachtung einer Ressource, und der Server sendet bei jeder Wertänderung selbst Aktualisierungen. Dadurch erhalten wir ein Verhalten, das dem Publish/Subscribe ähnelt, ohne eine dauerhafte Verbindung aufrechtzuerhalten. CoAP unterstützt auch den blockweisen Transfer (Block-Wise), um größere Payloads in Portionen von 16–1024 Byte zu übertragen, trotz der Größenbeschränkung des UDP-Datagramms. Dieser Mechanismus wird mitunter bei OTA-Firmware-Updates auf Geräten mit minimalem Speicher genutzt.
CoAP oder MQTT — wann welches Protokoll einsetzen?
CoAP wählen Sie für die direkte, transaktionale Kommunikation mit einem einzelnen Gerät mit extrem begrenzten Ressourcen; MQTT — für skalierbare Telemetrie vieler Geräte im Publish/Subscribe-Modell über einen Broker. Beide Protokolle koexistieren häufig in einer Architektur.
In der Projektpraxis trifft man in der Edge-Computing-Architektur auf hybride Lösungen: Die Sensoren kommunizieren lokal über CoAP mit einem Gateway, das die Daten aggregiert und sie über MQTT in die Cloud sendet. Die wichtigsten Unterschiede:
- Transport: CoAP arbeitet auf UDP (Request/Response), MQTT auf TCP (Publish/Subscribe über einen Broker).
- Topologie: CoAP ist eine Peer-to-Peer-Kommunikation mit einer Ressource; MQTT erfordert einen zentralen Broker.
- Energieeffizienz: das zustandslose UDP und der 4-Byte-Header verschaffen CoAP einen Vorteil auf batteriebetriebenen Geräten und in NB-IoT-Netzwerken.
- Reife des Ökosystems: MQTT verfügt über eine breitere Cloud-Unterstützung; Details zu MQTT haben wir in einem separaten Leitfaden zum MQTT-Protokoll beschrieben.
Wie sichert man das CoAP-Protokoll ab?
Die Sicherheit von CoAP wird in erster Linie durch DTLS (Datagram TLS) gewährleistet, also das Äquivalent zu TLS für den UDP-Transport, beschrieben als Schema coaps://. DTLS schützt die Vertraulichkeit und Integrität der Nachrichten und ermöglicht die Authentifizierung von Geräten mit Zertifikaten oder gemeinsam genutzten Schlüsseln (PSK).
In Implementierungen mit erhöhten Anforderungen setzt man eine auf X.509-Zertifikaten basierende Authentifizierung ein, die ein Zero-Trust-Modell für eine Geräteflotte umsetzt. Eine Alternative auf der Anwendungsschicht ist OSCORE (RFC 8613) — es verschlüsselt selektiv Felder der Nachricht und bleibt selbst dann geschützt, wenn der Datenverkehr über vermittelnde Gateways (Proxys) läuft. Unabhängig von der Wahl sollten die Schlüsselverwaltung und deren Rotation vom Provisioning an Teil des Gerätelebenszyklus sein.
Wo bewährt sich das CoAP-Protokoll am besten?
CoAP bewährt sich am besten in dichten Sensornetzwerken mit geringem Energieverbrauch: Smart Metering, Umweltüberwachung, Gebäudeautomation sowie industrielles IIoT mit Tausenden von Messpunkten. Sein geringer Overhead ermöglicht es, die Kommunikation in die schmalen Bänder von LPWAN-Netzen einzupassen.
In Industrieprojekten ergänzt CoAP häufig ältere Bussysteme; dort, wo SPS-Steuerungen arbeiten, verbinden wir es auf Gateway-Ebene mit industriellen Protokollen wie Modbus und CAN. Im Hotelgewerbe und in der Premium-Automation ermöglicht das leichtgewichtige Protokoll, Dutzende von Geräten in einem Zimmer abzufragen, ohne das Netzwerk zu belasten. Bei FSS entwerfen wir solche Kommunikationsschichten ganzheitlich — von der Firmware auf dem Mikrocontroller bis zum Cloud-Backend.
Häufig gestellte Fragen (FAQ)
Kann das CoAP-Protokoll über das Internet arbeiten und nicht nur im lokalen Netzwerk?
Ja. CoAP nutzt UDP und URI-Adressen und kann daher über das Internet kommunizieren, auch aus NB-IoT- und LTE-M-Netzen. Für die Sicherheit setzt man dann DTLS ein (Schema coaps://). Häufig verwendet man auch einen CoAP-HTTP-Proxy, der Anfragen in klassische Web-APIs übersetzt.
Worin unterscheidet sich CoAP von MQTT hinsichtlich des Energieverbrauchs?
CoAP ist bei seltenen, transaktionalen Abfragen üblicherweise energiesparender: Das zustandslose UDP hält keine Verbindung aufrecht und hat einen 4-Byte-Header. MQTT kann bei einem konstanten Telemetriestrom effizienter sein, wenn sich die Kosten für die Aufrechterhaltung einer TCP-Sitzung auf viele Nachrichten verteilen.
Welche Mikrocontroller unterstützen das CoAP-Protokoll?
CoAP wurde für die meisten gängigen IoT-Plattformen implementiert, darunter ESP32 und STM32, sowie für RTOS-Systeme wie Zephyr, Contiki-NG und RIOT OS. Verfügbare Bibliotheken (z. B. libcoap, CoAPthon) benötigen einige Dutzend Kilobyte Speicher, sodass sie sich auch auf Geräten mit sehr geringen Ressourcen ausführen lassen.
Zusammenfassung: die wichtigsten Erkenntnisse
CoAP ist eine ausgereifte, standardisierte Wahl überall dort, wo minimaler Energieverbrauch, geringer Overhead und die direkte Kommunikation mit einem ressourcenbeschränkten Gerät zählen. In Kombination mit DTLS bietet es eine Sicherheit auf einem Niveau, das TLS nahekommt, und der Observe-Mechanismus sowie der blockweise Transfer machen es zu einem universellen Werkzeug von der Telemetrie bis zu Firmware-Updates. Die besten Ergebnisse liefert eine durchdachte hybride Architektur, die CoAP, MQTT und industrielle Protokolle verbindet.
Das FSS-Team entwirft seit Jahren komplette IoT-Lösungen — Hardware, Firmware und Cloud-Backend — und wählt die Protokolle passend zu den realen Beschränkungen der Geräte und Netzwerke. Möchten Sie den optimalen Kommunikationsstack für Ihr Produkt auswählen? Sehen Sie sich unser Angebot zur Entwicklung vernetzter Geräte an oder besprechen Sie die IoT-Integrationen mit unseren Ingenieuren.
{“@context”: “https://schema.org”, “@graph”: [{“@type”: “Article”, “headline”: “CoAP im IoT: Funktionsweise und Einsatzszenarien”, “description”: “Das CoAP-Protokoll im IoT: wie es funktioniert, worin es sich von MQTT unterscheidet und wann man es in ressourcenbeschränkten Geräten einsetzt. Ein praktischer Leitfaden von FSS.”, “author”: {“@type”: “Organization”, “name”: “FSS”}, “publisher”: {“@type”: “Organization”, “name”: “FSS”}, “inLanguage”: “de”, “articleSection”: “IoT”, “mainEntityOfPage”: “https://fss.cc/protokol-coap-w-iot/”}, {“@type”: “FAQPage”, “mainEntity”: [{“@type”: “Question”, “name”: “Kann das CoAP-Protokoll über das Internet arbeiten und nicht nur im lokalen Netzwerk?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “Ja. CoAP nutzt UDP und URI-Adressen und kann daher über das Internet kommunizieren, auch aus NB-IoT- und LTE-M-Netzen. Für die Sicherheit setzt man dann DTLS ein (Schema coaps://). Häufig verwendet man auch einen CoAP-HTTP-Proxy, der Anfragen in klassische Web-APIs übersetzt.”}}, {“@type”: “Question”, “name”: “Worin unterscheidet sich CoAP von MQTT hinsichtlich des Energieverbrauchs?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “CoAP ist bei seltenen, transaktionalen Abfragen üblicherweise energiesparender: Das zustandslose UDP hält keine Verbindung aufrecht und hat einen 4-Byte-Header. MQTT kann bei einem konstanten Telemetriestrom effizienter sein, wenn sich die Kosten für die Aufrechterhaltung einer TCP-Sitzung auf viele Nachrichten verteilen.”}}, {“@type”: “Question”, “name”: “Welche Mikrocontroller unterstützen das CoAP-Protokoll?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “CoAP wurde für die meisten gängigen IoT-Plattformen implementiert, darunter ESP32 und STM32, sowie für RTOS-Systeme wie Zephyr, Contiki-NG und RIOT OS. Verfügbare Bibliotheken (z. B. libcoap, CoAPthon) benötigen einige Dutzend Kilobyte Speicher.”}}]}]}