2. Eingeschränktes Anwendungsprotokoll
Das Interaktionsmodell von CoAP ähnelt dem Client/Server-Modell von HTTP. Machine-to-Machine-Interaktionen führen jedoch typischerweise dazu, dass eine CoAP-Implementierung sowohl in Client- als auch in Serverrollen agiert. Eine CoAP-Anfrage entspricht der von HTTP und wird von einem Client gesendet, um eine Aktion (unter Verwendung eines Methodencodes) auf einer Ressource (identifiziert durch einen URI) auf einem Server anzufordern. Der Server sendet dann eine Antwort mit einem Antwortcode; diese Antwort kann eine Ressourcenrepräsentation enthalten.
Im Gegensatz zu HTTP behandelt CoAP diese Austauschvorgänge asynchron über einen datagrammorientierten Transport wie UDP. Dies geschieht logisch unter Verwendung einer Nachrichtenschicht, die optionale Zuverlässigkeit (mit exponentiellem Back-off) unterstützt. CoAP definiert vier Arten von Nachrichten: Confirmable (Bestätigungsbedürftig), Non-confirmable (Nicht bestätigungsbedürftig), Acknowledgement (Bestätigung), Reset (Zurücksetzen). Methodencodes und Antwortcodes, die in einigen dieser Nachrichten enthalten sind, lassen sie Anfragen oder Antworten tragen. Die grundlegenden Austauschvorgänge 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 sich CoAP logisch als Verwendung eines zweischichtigen Ansatzes vorstellen: eine CoAP-Nachrichtenschicht, die verwendet wird, um UDP und die asynchrone Natur der Interaktionen zu behandeln, und die Anfrage/Antwort-Interaktionen unter Verwendung von Methoden- und Antwortcodes (siehe Abbildung 1). CoAP ist jedoch ein einzelnes Protokoll, wobei Messaging und Anfrage/Antwort nur Merkmale des CoAP-Headers sind.
+----------------------+
| Anwendung |
+----------------------+
+----------------------+ \
| Anfragen/Antworten | |
|----------------------| | CoAP
| Nachrichten | |
+----------------------+ /
+----------------------+
| UDP |
+----------------------+
Abbildung 1: Abstrakte Schichtung von CoAP
2.1. Messaging-Modell
Das CoAP-Messaging-Modell basiert auf dem Austausch von Nachrichten über UDP zwischen Endpunkten.
CoAP verwendet einen kurzen binären Header fester Länge (4 Byte), dem kompakte binäre Optionen und eine Nutzlast folgen können. Dieses Nachrichtenformat wird von Anfragen und Antworten geteilt. Das CoAP-Nachrichtenformat ist in Abschnitt 3 spezifiziert. Jede Nachricht enthält eine Nachrichten-ID, die zur Erkennung von Duplikaten und für optionale Zuverlässigkeit verwendet wird. (Die Nachrichten-ID ist kompakt; ihre 16-Bit-Größe ermöglicht bis zu etwa 250 Nachrichten pro Sekunde von einem Endpunkt zu einem anderen mit Standardprotokollparametern.)
Zuverlässigkeit wird durch Markieren einer Nachricht als Confirmable (CON) bereitgestellt. Eine Confirmable-Nachricht wird unter Verwendung eines Standard-Timeouts und exponentiellen Back-offs zwischen Neuübertragungen erneut übertragen, bis der Empfänger eine Acknowledgement-Nachricht (ACK) mit derselben Nachrichten-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 in der Lage ist, eine geeignete Fehlerantwort bereitzustellen), antwortet er mit einer Reset-Nachricht (RST) anstelle einer Acknowledgement (ACK).
Client Server
| |
| CON [0x7d34] |
+----------------->|
| |
| ACK [0x7d34] |
|<-----------------+
| |
Abbildung 2: Zuverlässige Nachrichtenübertragung
Eine Nachricht, die keine zuverlässige Übertragung erfordert (zum Beispiel jeder einzelne Messwert aus einem Strom von Sensordaten), kann als Non-confirmable-Nachricht (NON) gesendet werden. Diese werden nicht bestätigt, haben aber dennoch eine Nachrichten-ID zur Duplikaterkennung (in diesem Beispiel 0x01a0); siehe Abbildung 3. Wenn ein Empfänger nicht in der Lage ist, eine Non-confirmable-Nachricht zu verarbeiten, 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 erörtert die ordnungsgemäße Verwendung von CoAP-Nachrichten mit Multicast-Adressen und Vorsichtsmaßnahmen zur Vermeidung von Antwortstaus.
In Abschnitt 9 werden für CoAP mehrere Sicherheitsmodi definiert, die von keiner Sicherheit bis hin 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] erörtert.
2.2. Anfrage/Antwort-Modell
CoAP-Anfrage- und Antwortsemantiken werden in CoAP-Nachrichten getragen, die entweder einen Methodencode bzw. einen Antwortcode enthalten. Optionale (oder Standard-) Anfrage- und Antwortinformationen, wie z. B. der URI und der Nutzlast-Medientyp, werden als CoAP-Optionen getragen. Ein Token wird verwendet, um Antworten Anfragen unabhängig von den zugrunde liegenden Nachrichten zuzuordnen (Abschnitt 5.3). (Beachten Sie, dass das Token ein von der Nachrichten-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 (Piggybacked Response) bezeichnet, detailliert in Abschnitt 5.2.1. (Es ist nicht erforderlich, eine Huckepack-Antwort separat zu bestätigen, da der Client die Anfrage erneut überträgt, wenn die Acknowledgement-Nachricht, die die Huckepack-Antwort trägt, verloren geht.) Zwei Beispiele für eine grundlegende GET-Anfrage mit Huckepack-Antwort sind in Abbildung 4 dargestellt, eine erfolgreiche, eine resultierend in 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 aufhören kann, die Anfrage erneut zu übertragen. 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 einer separaten Antwort
Wenn eine Anfrage in einer Non-confirmable-Nachricht gesendet wird, wird die Antwort unter Verwendung einer neuen Non-confirmable-Nachricht gesendet, obwohl der Server stattdessen eine Confirmable-Nachricht senden kann. Diese Art des Austauschs 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, getragen in
Non-confirmable-Nachrichten
CoAP verwendet die Methoden GET, PUT, POST und DELETE in ähnlicher Weise wie HTTP, mit den in Abschnitt 5.8 spezifizierten Semantiken. (Beachten Sie, dass die detaillierten Semantiken von CoAP-Methoden "fast, aber nicht ganz unähnlich" [HHGTTG] denen von HTTP-Methoden sind: Intuition aus der HTTP-Erfahrung trifft im Allgemeinen gut zu, aber es gibt genug Unterschiede, dass es sich lohnt, die vorliegende Spezifikation tatsächlich zu lesen.)
Methoden über die vier grundlegenden hinaus können in separaten Spezifikationen zu CoAP hinzugefügt werden. Neue Methoden müssen nicht unbedingt Anfragen und Antworten paarweise verwenden. Auch bei bestehenden Methoden kann eine einzelne Anfrage mehrere Antworten ergeben, z. B. bei einer Multicast-Anfrage (Abschnitt 8) oder mit der Observe-Option [OBSERVE].
Die URI-Unterstützung in einem Server wird vereinfacht, da der Client den URI bereits parst und in Host-, Port-, Pfad- und Abfragekomponenten aufteilt und dabei Standardwerte zur Effizienzsteigerung nutzt. Antwortcodes beziehen sich auf eine kleine Teilmenge von HTTP-Statuscodes mit einigen hinzugefügten CoAP-spezifischen Codes, wie in Abschnitt 5.9 definiert.
2.3. 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 getragen werden. Ein Cache könnte sich in einem Endpunkt oder einem Vermittler befinden. 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 schlafender Geräte und aus Sicherheitsgründen. Das Proxying von Anfragen im Namen eines anderen CoAP-Endpunkts wird im Protokoll unterstützt. Bei Verwendung eines Proxys ist der URI der anzufordernden Ressource in der Anfrage enthalten, 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 somit eine Funktionalität aufweist, die der des HTTP-Protokolls ähnelt, ist es recht einfach, von CoAP auf HTTP und von HTTP auf CoAP abzubilden. Eine solche Abbildung kann verwendet werden, um eine HTTP-REST-Schnittstelle unter Verwendung von CoAP zu realisieren oder um zwischen HTTP und CoAP zu konvertieren. Diese Konvertierung kann von einem protokollübergreifenden Proxy ("Cross-Proxy") durchgeführt werden, der den Methoden- oder Antwortcode, den Medientyp und die Optionen in das entsprechende HTTP-Merkmal konvertiert. Abschnitt 10 bietet weitere Details zur HTTP-Abbildung.
2.4. Ressourcenerkennung
Ressourcenerkennung ist wichtig für Machine-to-Machine-Interaktionen und wird unter Verwendung des CoRE Link Format [RFC6690] unterstützt, wie in Abschnitt 7 erörtert.