Constrained Application Protocol
Das Constrained Application Protocol (CoAP) ist ein von der Internet Engineering Task Force (IETF) entwickeltes Web-Transfer-Protokoll für das Internet of Things (IoT). Es ist ein speziell für eingebettete Geräte entwickeltes Protokoll, welches die Grundzüge von REST übernimmt. Das Protokoll ist im RFC 7252[1] spezifiziert.
Die Anwendung vom CoAP-Protokoll umfasst Umgebungsüberwachungen, intelligente Gebäude- und Lichtsteuerungen, Smart Energy und noch vieles mehr aus dieser Sparte. Es wurde als Standardprotokoll entwickelt, das die Interaktion zwischen IoT-Geräten/Systemen ermöglicht und somit IoT-Anwendungen unterstützt. Wichtig dabei ist, dass das CoAP-Protokoll die Länge des Datagramms so gering wie möglich hält und gleichzeitig das REST-Protokoll integriert, um den „Uniform Resource Identifier“ (URI) zu unterstützen.
Funktionen:
- Begrenztes Web-Protokoll, das alle Anforderungen an M2M-Kommunikation (Machine to Machine) erfüllt
- Gewährleistung der Sicherheit durch DTLS
- Asynchroner Nachrichtenaustausch
- Geringer Overhead
- Geringe Komplexität bei der syntaktischen Analyse (Parsing)
- URI- und Content-Type Unterstützung
- Einfache Caching- und Proxy-Fähigkeiten
- UDP-Übertragung mit der Möglichkeit von Unicast und Multicast
CoAP ist ein netzwerkorientiertes Protokoll, das dem HTTP-Protokoll sehr ähnelt. Es nutzt dabei Features von HTTP, erlaubt aber einen geringeren Overhead und auch einen Multicast. Das HTTP-Protokoll ermöglicht die notwendige Interoperabilität für IoT-Geräte. HTTP nutzt TCP für Point-to-Point Verbindungen, ist aber für abgegrenzte Netzwerke zu komplex. CoAP hingegen benutzt primär UDP ohne komplexe Staukontrolle. Die Kombination von REST-Methoden und UDP ermöglichen es CoAP, die Begrenzungen von HTTP zu erweitern und so die Kommunikation für IoT-Geräte zu erleichtern und sicherzustellen.
| HTTP | CoAP |
|---|---|
| HTTP-Protokoll | Anfrage/Antwort |
| Nachrichten | |
| TCP | UDP |
| IP | 6LoWPAN |
Bei der Einführung von CoAP wurde davon ausgegangen, dass UDP [RFC 768[2]] und das Datagram Transport Layer Security Protokoll (DTLS) [RFC 6347[3]] über UDP uneingeschränkt genutzt werden kann. Da UDP aber bei vielen Zugangsnetzen vollkommen blockiert und auch der UDP-Verkehr in einigen Netzwerken begrenzt wird, wurde CoAP über TCP [RFC 793[4]] und TLS [RFC 5246[5]] eingeführt. Hierbei kommen die besonderen Eigenschaften von CoAP über TCP bei einem NAT-Traversal zu tragen, da die Berechnung der Verfallszeiten basierend auf dem Transportschichtprotokoll berechnet werden, welche von den Anwendungsprotokollen verwendet werden. Der Mittelwert von TCP-NAT-Bindungszeitüberschreitungen liegt bei 386 Minuten, wohingegen der Mittelwert bei UDP bei 160 Sekunden liegt.[6] Kürzere Bindungszeitüberschreitungen fordern mehr Keepalive-Nachrichten und erhöhen somit den Traffic. Des Weiteren nutzt TCP auch zusätzliche Stau- und Flusskontrollmechanismen, welche bei größeren Übertragungslasten nützlich sind.
Trotz allem wird die Übertragung von CoAP über UDP immer noch präferiert, wenn es eine geringe Anzahl an Knoten gibt und die Übertragung blockweise ablaufen soll. Der Nachteil von CoAP über TCP ist, dass es zu größeren Paketen, erhöhtem Speicherverbrauch und einem umfangreicheren Code führt.
Sicherheitsaspekte
BearbeitenBei der UDP-Übertragung ist das DTLS-Protokoll ein wichtiger Bestandteil, da es die drei Aspekte von Sicherheit abdeckt und somit eine sichere End-to-End-Verbindung erlaubt:
Die IETF hat das DTLS-Protokoll weiterentwickelt und für die Nutzung mit TCP erweitert. Dadurch können die Probleme der Paketreihenfolge und -verluste behoben werden, indem Paketwiederholungen, Sequenznummern während eines TCP-Handshakes und Wiederholungserkennung implementiert wurden.
Format
BearbeitenDie standardmäßige Übertragung erfolgt über UDP und basiert auf dem Grundsatz zum Austausch von kompakten Nachrichten. Dabei wird ein Binärformat in einfacher Form verwendet.
| 0 | 1 | 2 | 3 |
|---|---|---|---|
| 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 | |||
| Ver | T | Code | Nachrichten ID |
| Token (variable Länge) | |||
| Optionen (Wenn vorhanden) | |||
| Payload (Nutzdaten) | |||
Eine Nachricht besteht aus:
- 4-Byte Header (fixe Größe)
- Token mit variabler Länge
- CoAP-Optionen
- Nutzdaten
Weblinks
Bearbeiten- Zach Shelby, Klaus Hartke, Carsten Bormann: RFC – The Constrained Application Protocol (CoAP). (englisch).
- C. Bormann, S. Lemay, H. Tschofenig, K. Hartke, B. Silverajan: RFC – CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets. Februar 2018 (englisch).
- Xi Chen: Constrained Application Protocol for Internet of Things. Abgerufen am 15. Mai 2022 (englisch).
Einzelnachweise
Bearbeiten- ↑ Zach Shelby, Klaus Hartke, Carsten Bormann: RFC – The Constrained Application Protocol (CoAP). (englisch).
- ↑ Jon Postel: RFC – User Datagram Protocol. August 1980 (englisch).
- ↑ RFC – Datagram Transport Layer Security Version 1.2. Januar 2012 (englisch).
- ↑ RFC – Transmission Control Protocol. September 1981 (englisch).
- ↑ RFC – The Transport Layer Security (TLS) Protocol Version 1.2. August 2008 (englisch).
- ↑ C. Bormann, S. Lemay, H. Tschofenig, K. Hartke, B. Silverajan: RFC – CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets. Februar 2018 (englisch).