2. Constrained Application Protocol (Eingeschränktes Anwendungsprotokoll)
Das Interaktionsmodell von CoAP ähnelt dem Client/Server-Modell von HTTP. Bei Machine-to-Machine-Interaktionen führt eine CoAP-Implementierung jedoch typischerweise sowohl Client- als auch Server-Rollen aus. Eine CoAP-Anfrage ist äquivalent zu der von HTTP und wird von einem Client gesendet, um eine Aktion (unter Verwendung eines Method Code) auf einer Ressource (identifiziert durch einen URI) auf einem Server anzufordern. Der Server sendet dann eine Antwort mit einem Response Code; diese Antwort kann eine Ressourcendarstellung enthalten.
Im Gegensatz zu HTTP behandelt CoAP diese Austausche asynchron über einen datagrammorientierten Transport wie UDP. Dies wird logisch unter Verwendung einer Nachrichtenschicht durchgeführt, die optionale Zuverlässigkeit (mit exponentiellem Backoff) unterstützt. CoAP definiert vier Nachrichtentypen: Confirmable, Non-confirmable, Acknowledgement, Reset. Method Codes und Response Codes, die in einigen dieser Nachrichten enthalten sind, ermöglichen es ihnen, Anfragen oder Antworten zu tragen. Die grundlegenden Austausche der vier Nachrichtentypen sind etwas orthogonal zu den Anfrage/Antwort-Interaktionen; Anfragen können in Confirmable- und Non-confirmable-Nachrichten getragen werden, und Antworten können in diesen sowie huckepack in Acknowledgement-Nachrichten getragen werden.
Man könnte CoAP logisch als einen zweischichtigen Ansatz betrachten, eine CoAP-Nachrichtenschicht, die verwendet wird, um mit UDP und der asynchronen Natur der Interaktionen umzugehen, und die Anfrage/Antwort-Interaktionen unter Verwendung von Method und Response Codes (siehe Abbildung 1). CoAP ist jedoch ein einzelnes Protokoll, wobei Nachrichtenübermittlung und Anfrage/Antwort nur Merkmale des CoAP-Headers sind.
+----------------------+
| Application |
+----------------------+
+----------------------+ \
| Requests/Responses | |
|----------------------| | CoAP
| Messages | |
+----------------------+ /
+----------------------+
| UDP |
+----------------------+
Abbildung 1: Abstrakte Schichtung von CoAP
2.1. Messaging Model (Nachrichtenmodell)
Das CoAP-Nachrichtenmodell basiert auf dem Austausch von Nachrichten über UDP zwischen Endpunkten.
CoAP verwendet einen kurzen binären Header fester Länge (4 Bytes), dem kompakte binäre Optionen und eine Nutzlast folgen können. Dieses Nachrichtenformat wird von Anfragen und Antworten gemeinsam genutzt. Das CoAP-Nachrichtenformat ist in Abschnitt 3 spezifiziert. Jede Nachricht enthält eine Message ID, die zur Duplikaterkennung und für optionale Zuverlässigkeit verwendet wird. (Die Message ID ist kompakt; ihre 16-Bit-Größe ermöglicht mit den Standard-Protokollparametern bis zu etwa 250 Nachrichten pro Sekunde von einem Endpunkt zu einem anderen.)
Zuverlässigkeit wird bereitgestellt, indem eine Nachricht als Confirmable (CON) markiert wird. Eine Confirmable-Nachricht wird unter Verwendung eines Standard-Timeouts und eines exponentiellen Backoffs zwischen Wiederholungen erneut übertragen, bis der Empfänger eine Acknowledgement-Nachricht (ACK) mit derselben Message ID (in diesem Beispiel 0x7d34) vom entsprechenden Endpunkt sendet; siehe Abbildung 2. Wenn ein Empfänger überhaupt nicht in der Lage ist, eine Confirmable-Nachricht zu verarbeiten (d.h. nicht einmal eine geeignete Fehlerantwort bereitstellen kann), antwortet er mit einer Reset-Nachricht (RST) anstelle eines Acknowledgement (ACK).
Client Server
| |
| CON [0x7d34] |
+----------------->|
| |
| ACK [0x7d34] |
|<-----------------+
| |
Abbildung 2: Zuverlässige Nachrichtenübertragung
Eine Nachricht, die keine zuverlässige Übertragung erfordert (z.B. jede einzelne Messung aus einem Strom von Sensordaten), kann als Non-confirmable-Nachricht (NON) gesendet werden. Diese werden nicht bestätigt, haben aber dennoch eine Message ID zur Duplikaterkennung (in diesem Beispiel 0x01a0); siehe Abbildung 3. Wenn ein Empfänger eine Non-confirmable-Nachricht nicht verarbeiten kann, kann er mit einer Reset-Nachricht (RST) antworten.
Client Server
| |
| NON [0x01a0] |
+----------------->|
| |
Abbildung 3: Unzuverlässige Nachrichtenübertragung
Siehe Abschnitt 4 für Details zu CoAP-Nachrichten.
Da CoAP über UDP läuft, unterstützt es auch die Verwendung von Multicast-IP-Zieladressen, was Multicast-CoAP-Anfragen ermöglicht. Abschnitt 8 diskutiert die ordnungsgemäße Verwendung von CoAP-Nachrichten mit Multicast-Adressen und Vorsichtsmaßnahmen zur Vermeidung von Antwortstaus.
Mehrere Sicherheitsmodi werden für CoAP in Abschnitt 9 definiert, die von keiner Sicherheit bis zu zertifikatsbasierter Sicherheit reichen. Dieses Dokument spezifiziert eine Bindung an DTLS zur Sicherung des Protokolls; die Verwendung von IPsec mit CoAP wird in [IPsec-CoAP] diskutiert.
2.2. Request/Response Model (Anfrage/Antwort-Modell)
CoAP-Anfrage- und Antwort-Semantik werden in CoAP-Nachrichten getragen, die entweder einen Method Code oder Response Code enthalten. Optionale (oder Standard-) Anfrage- und Antwortinformationen, wie der URI und der Nutzlast-Medientyp, werden als CoAP-Optionen getragen. Ein Token wird verwendet, um Antworten unabhängig von den zugrunde liegenden Nachrichten mit Anfragen abzugleichen (Abschnitt 5.3). (Beachten Sie, dass der Token ein von der Message ID getrenntes Konzept ist.)
Eine Anfrage wird in einer Confirmable (CON) oder Non-confirmable (NON) Nachricht getragen, und wenn sofort verfügbar, wird die Antwort auf eine in einer Confirmable-Nachricht getragene Anfrage in der resultierenden Acknowledgement (ACK) Nachricht getragen. Dies wird als Huckepack-Antwort bezeichnet und in Abschnitt 5.2.1 detailliert beschrieben. (Es ist nicht erforderlich, eine Huckepack-Antwort separat zu bestätigen, da der Client die Anfrage erneut übertragen wird, wenn die Acknowledgement-Nachricht, die die Huckepack-Antwort trägt, verloren geht.) Zwei Beispiele für eine grundlegende GET-Anfrage mit Huckepack-Antwort werden in Abbildung 4 gezeigt, eine erfolgreich, eine mit einer 4.04 (Not Found) Antwort.
Client Server Client Server
| | | |
| CON [0xbc90] | | CON [0xbc91] |
| GET /temperature | | GET /temperature |
| (Token 0x71) | | (Token 0x72) |
+----------------->| +----------------->|
| | | |
| ACK [0xbc90] | | ACK [0xbc91] |
| 2.05 Content | | 4.04 Not Found |
| (Token 0x71) | | (Token 0x72) |
| "22.5 C" | | "Not found" |
|<-----------------+ |<-----------------+
| | | |
Abbildung 4: Zwei GET-Anfragen mit Huckepack-Antworten
Wenn der Server nicht in der Lage ist, sofort auf eine in einer Confirmable-Nachricht getragene Anfrage zu antworten, antwortet er einfach mit einer leeren Acknowledgement-Nachricht, damit der Client die Wiederübertragung der Anfrage stoppen kann. Wenn die Antwort bereit ist, sendet der Server sie in einer neuen Confirmable-Nachricht (die dann wiederum vom Client bestätigt werden muss). Dies wird als "separate Antwort" bezeichnet, wie in Abbildung 5 dargestellt und in Abschnitt 5.2.2 ausführlicher beschrieben.
Client Server
| |
| CON [0x7a10] |
| GET /temperature |
| (Token 0x73) |
+----------------->|
| |
| ACK [0x7a10] |
|<-----------------+
| |
... Zeit vergeht ...
| |
| CON [0x23bb] |
| 2.05 Content |
| (Token 0x73) |
| "22.5 C" |
|<-----------------+
| |
| ACK [0x23bb] |
+----------------->|
| |
Abbildung 5: Eine GET-Anfrage mit separater Antwort
Wenn eine Anfrage in einer Non-confirmable-Nachricht gesendet wird, wird die Antwort mit einer neuen Non-confirmable-Nachricht gesendet, obwohl der Server stattdessen eine Confirmable-Nachricht senden kann. Diese Art von Austausch ist in Abbildung 6 dargestellt.
Client Server
| |
| NON [0x7a11] |
| GET /temperature |
| (Token 0x74) |
+----------------->|
| |
| NON [0x23bc] |
| 2.05 Content |
| (Token 0x74) |
| "22.5 C" |
|<-----------------+
| |
Abbildung 6: Eine Anfrage und eine Antwort in Non-confirmable-Nachrichten
CoAP verwendet GET-, PUT-, POST- und DELETE-Methoden auf ähnliche Weise wie HTTP, mit der in Abschnitt 5.8 spezifizierten Semantik. (Beachten Sie, dass die detaillierte Semantik der CoAP-Methoden "fast, aber nicht ganz unähnlich" [HHGTTG] der von HTTP-Methoden ist: Die aus HTTP-Erfahrung gewonnene Intuition gilt im Allgemeinen gut, aber es gibt genügend Unterschiede, die es lohnenswert machen, die vorliegende Spezifikation tatsächlich zu lesen.)
Methoden über die grundlegenden vier hinaus können in separaten Spezifikationen zu CoAP hinzugefügt werden. Neue Methoden müssen nicht notwendigerweise Anfragen und Antworten paarweise verwenden. Selbst für bestehende Methoden kann eine einzelne Anfrage mehrere Antworten liefern, z.B. für eine Multicast-Anfrage (Abschnitt 8) oder mit der Observe-Option [OBSERVE].
Die URI-Unterstützung in einem Server ist vereinfacht, da der Client den URI bereits analysiert und in Host-, Port-, Pfad- und Query-Komponenten aufteilt, wobei er Standardwerte für Effizienz verwendet. Response Codes beziehen sich auf eine kleine Teilmenge von HTTP-Statuscodes mit einigen CoAP-spezifischen Codes, wie in Abschnitt 5.9 definiert.
2.3. Intermediaries and Caching (Vermittler und Caching)
Das Protokoll unterstützt das Caching von Antworten, um Anfragen effizient zu erfüllen. Einfaches Caching wird unter Verwendung von Frische- und Gültigkeitsinformationen ermöglicht, die mit CoAP-Antworten übertragen werden. Ein Cache könnte sich in einem Endpunkt oder einem Vermittler befinden. Die Caching-Funktionalität ist in Abschnitt 5.6 spezifiziert.
Proxying ist in eingeschränkten Netzwerken aus mehreren Gründen nützlich, einschließlich zur Begrenzung des Netzwerkverkehrs, zur Verbesserung der Leistung, zum Zugriff auf Ressourcen von schlafenden Geräten und aus Sicherheitsgründen. Das Proxying von Anfragen im Namen eines anderen CoAP-Endpunkts wird im Protokoll unterstützt. Bei Verwendung eines Proxys wird der URI der anzufordernden Ressource in die Anfrage aufgenommen, während die Ziel-IP-Adresse auf die Adresse des Proxys gesetzt wird. Siehe Abschnitt 5.7 für weitere Informationen zur Proxy-Funktionalität.
Da CoAP gemäß der REST-Architektur [REST] entworfen wurde und daher eine ähnliche Funktionalität wie das HTTP-Protokoll aufweist, ist es ziemlich einfach, von CoAP nach HTTP und von HTTP nach CoAP zu mappen. Ein solches Mapping kann verwendet werden, um eine HTTP-REST-Schnittstelle unter Verwendung von CoAP zu realisieren oder zwischen HTTP und CoAP zu konvertieren. Diese Konvertierung kann durch einen Kreuzprotokoll-Proxy ("Cross-Proxy") durchgeführt werden, der den Method oder Response Code, Medientyp und Optionen in die entsprechende HTTP-Funktion konvertiert und umgekehrt. Abschnitt 10 bietet weitere Details zum HTTP-Mapping.
2.4. Resource Discovery (Ressourcenentdeckung)
Ressourcenentdeckung ist wichtig für Machine-to-Machine-Interaktionen und wird unter Verwendung des CoRE Link Format [RFC6690] unterstützt, das in Abschnitt 7 diskutiert wird.