1. Einführung
Die Verwendung von Webdiensten (Web-APIs) im Internet ist in den meisten Anwendungen allgegenwärtig geworden und hängt von der grundlegenden Representational State Transfer [REST]-Architektur des Webs ab.
Die Arbeit an Constrained RESTful Environments (CoRE) zielt darauf ab, die REST-Architektur in einer geeigneten Form für die am stärksten eingeschränkten Knoten (z. B. 8-Bit-Mikrocontroller mit begrenztem RAM und ROM) und Netzwerke (z. B. 6LoWPAN, [RFC4944]) zu realisieren. Eingeschränkte Netzwerke wie 6LoWPAN unterstützen die Fragmentierung von IPv6-Paketen in kleine Sicherungsschicht-Frames; dies führt jedoch zu einer erheblichen Verringerung der Paketzustellwahrscheinlichkeit. Ein Entwurfsziel von CoAP war es, den Nachrichten-Overhead gering zu halten und so die Notwendigkeit einer Fragmentierung zu begrenzen.
Eines der Hauptziele von CoAP ist es, ein generisches Webprotokoll für die speziellen Anforderungen dieser eingeschränkten Umgebung zu entwerfen, insbesondere unter Berücksichtigung von Energie, Gebäudeautomation und anderen Machine-to-Machine (M2M)-Anwendungen. Das Ziel von CoAP ist es nicht, HTTP [RFC2616] blind zu komprimieren, sondern vielmehr eine Teilmenge von REST zu realisieren, die mit HTTP gemeinsam ist, aber für M2M-Anwendungen optimiert ist. Obwohl CoAP verwendet werden könnte, um einfache HTTP-Schnittstellen in ein kompakteres Protokoll umzuwandeln, bietet es vor allem Funktionen für M2M wie integrierte Erkennung, Multicast-Unterstützung und asynchronen Nachrichtenaustausch.
Dieses Dokument spezifiziert das Constrained Application Protocol (CoAP), das sich leicht in HTTP übersetzen lässt, um es in das bestehende Web zu integrieren, während es spezielle Anforderungen wie Multicast-Unterstützung, sehr geringen Overhead und Einfachheit für eingeschränkte Umgebungen und M2M-Anwendungen erfüllt.
1.1. Funktionen
CoAP hat die folgenden Hauptfunktionen:
o Webprotokoll, das M2M-Anforderungen in eingeschränkten Umgebungen erfüllt
o UDP [RFC0768]-Bindung mit optionaler Zuverlässigkeit, die Unicast- und Multicast-Anfragen unterstützt.
o Asynchroner Nachrichtenaustausch.
o Geringer Header-Overhead und Parsing-Komplexität.
o URI- und Content-Type-Unterstützung.
o Einfache Proxy- und Caching-Funktionen.
o Ein zustandsloses HTTP-Mapping, das es ermöglicht, Proxys zu erstellen, die den Zugriff auf CoAP-Ressourcen über HTTP auf einheitliche Weise ermöglichen, oder einfache HTTP-Schnittstellen alternativ über CoAP zu realisieren.
o Sicherheitsbindung an Datagram Transport Layer Security (DTLS) [RFC6347].
1.2. Terminologie
Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind so zu interpretieren, wie in [RFC2119] beschrieben, wenn sie in GROSSBUCHSTABEN erscheinen. Diese Wörter können in diesem Dokument auch in Kleinbuchstaben erscheinen, ohne ihre normative Bedeutung.
Diese Spezifikation setzt voraus, dass die Leser mit allen Begriffen und Konzepten vertraut sind, die in [RFC2616] behandelt werden, einschließlich "Ressource", "Repräsentation", "Cache" und "frisch". (Da diese Spezifikation abgeschlossen wurde, bevor der aktualisierte Satz von HTTP-RFCs, RFC 7230 bis RFC 7235, verfügbar wurde, verweist sie spezifisch auf die Vorgängerversion -- RFC 2616.) Darüber hinaus definiert diese Spezifikation die folgende Terminologie:
Endpoint (Endpunkt) Eine Entität, die am CoAP-Protokoll teilnimmt. Umgangssprachlich lebt ein Endpunkt auf einem "Knoten", obwohl "Host" eher dem Sprachgebrauch von Internetstandards entsprechen würde, und wird weiter durch Transport-Layer-Multiplexing-Informationen identifiziert, die eine UDP-Portnummer und eine Sicherheitsassoziation (Abschnitt 4.1) umfassen können.
Sender (Absender) Der Ursprungs-Endpunkt einer Nachricht. Wenn der Aspekt der Identifizierung des spezifischen Absenders im Fokus steht, auch "Quell-Endpunkt".
Recipient (Empfänger) Der Ziel-Endpunkt einer Nachricht. Wenn der Aspekt der Identifizierung des spezifischen Empfängers im Fokus steht, auch "Ziel-Endpunkt".
Client Der Ursprungs-Endpunkt einer Anfrage; der Ziel-Endpunkt einer Antwort.
Server Der Ziel-Endpunkt einer Anfrage; der Ursprungs-Endpunkt einer Antwort.
Origin Server (Ursprungsserver) Der Server, auf dem sich eine bestimmte Ressource befindet oder erstellt werden soll.
Intermediary (Vermittler) Ein CoAP-Endpunkt, der sowohl als Server als auch als Client gegenüber einem Ursprungsserver (möglicherweise über weitere Vermittler) fungiert. Eine häufige Form eines Vermittlers ist ein Proxy; mehrere Klassen solcher Proxys werden in dieser Spezifikation diskutiert.
Proxy Ein Vermittler, der sich hauptsächlich mit der Weiterleitung von Anfragen und dem Zurückleiten von Antworten befasst und dabei möglicherweise Caching, Namensraumübersetzung oder Protokollübersetzung durchführt. Im Gegensatz zu Vermittlern im allgemeinen Sinne implementieren Proxys im Allgemeinen keine spezifische Anwendungssemantik. Basierend auf der Position in der Gesamtstruktur der Anfrageweiterleitung gibt es zwei häufige Formen von Proxys: Forward-Proxy und Reverse-Proxy. In einigen Fällen kann ein einzelner Endpunkt als Ursprungsserver, Forward-Proxy oder Reverse-Proxy fungieren und das Verhalten basierend auf der Art jeder Anfrage wechseln.
Forward-Proxy Ein von einem Client ausgewählter Endpunkt, normalerweise über lokale Konfigurationsregeln, um Anfragen im Namen des Clients durchzuführen und alle notwendigen Übersetzungen vorzunehmen. Einige Übersetzungen sind minimal, wie z. B. bei Proxy-Anfragen für "coap"-URIs, während andere Anfragen eine Übersetzung in und aus völlig anderen Anwendungsschichtprotokollen erfordern können.
Reverse-Proxy Ein Endpunkt, der für einen oder mehrere andere Server einspringt und Anfragen in deren Namen erfüllt, wobei alle notwendigen Übersetzungen vorgenommen werden. Im Gegensatz zu einem Forward-Proxy ist sich der Client möglicherweise nicht bewusst, dass er mit einem Reverse-Proxy kommuniziert; ein Reverse-Proxy empfängt Anfragen so, als wäre er der Ursprungsserver für die Zielressource.
CoAP-to-CoAP Proxy Ein Proxy, der eine CoAP-Anfrage auf eine CoAP-Anfrage abbildet, d. h. das CoAP-Protokoll sowohl auf der Server- als auch auf der Client-Seite verwendet. Im Gegensatz zum Cross-Proxy.
Cross-Proxy Ein protokollübergreifender Proxy, kurz "Cross-Proxy", ist ein Proxy, der zwischen verschiedenen Protokollen übersetzt, wie z. B. ein CoAP-zu-HTTP-Proxy oder ein HTTP-zu-CoAP-Proxy. Während diese Spezifikation sehr spezifische Anforderungen an CoAP-zu-CoAP-Proxys stellt, sind bei Cross-Proxys mehr Variationen möglich.
Confirmable Message (Bestätigungsbedürftige Nachricht) Einige Nachrichten erfordern eine Bestätigung. Diese Nachrichten werden "Confirmable" genannt. Wenn keine Pakete verloren gehen, löst jede Confirmable-Nachricht genau eine Rücknachricht vom Typ Acknowledgement (Bestätigung) oder vom Typ Reset (Zurücksetzen) aus.
Non-confirmable Message (Nicht bestätigungsbedürftige Nachricht) Einige andere Nachrichten erfordern keine Bestätigung. Dies gilt insbesondere für Nachrichten, die aufgrund von Anwendungsanforderungen regelmäßig wiederholt werden, wie z. B. wiederholte Messwerte von einem Sensor.
Acknowledgement Message (Bestätigungsnachricht) Eine Bestätigungsnachricht bestätigt, dass eine spezifische Confirmable-Nachricht angekommen ist. Für sich genommen zeigt eine Bestätigungsnachricht nicht den Erfolg oder Misserfolg einer in der Confirmable-Nachricht gekapselten Anfrage an, aber die Bestätigungsnachricht kann auch eine Piggybacked Response (siehe unten) tragen.
Reset Message (Zurücksetzungsnachricht) Eine Reset-Nachricht zeigt an, dass eine spezifische Nachricht (Confirmable oder Non-confirmable) empfangen wurde, aber ein gewisser Kontext fehlt, um sie ordnungsgemäß zu verarbeiten. Dieser Zustand wird normalerweise verursacht, wenn der empfangende Knoten neu gestartet hat und einen Zustand vergessen hat, der zur Interpretation der Nachricht erforderlich wäre. Das Provozieren einer Reset-Nachricht (z. B. durch Senden einer leeren Confirmable-Nachricht) ist auch als kostengünstige Überprüfung der Lebendigkeit eines Endpunkts ("CoAP-Ping") nützlich.
Piggybacked Response (Huckepack-Antwort) Eine Piggybacked Response ist direkt in einer CoAP-Bestätigungsnachricht (ACK) enthalten, die gesendet wird, um den Empfang der Anfrage für diese Antwort zu bestätigen (Abschnitt 5.2.1).
Separate Response (Separate Antwort) Wenn eine Confirmable-Nachricht, die eine Anfrage trägt, mit einer leeren Nachricht bestätigt wird (z. B. weil der Server die Antwort nicht sofort hat), wird eine Separate Response in einem separaten Nachrichtenaustausch gesendet (Abschnitt 5.2.2).
Empty Message (Leere Nachricht) Eine Nachricht mit einem Code von 0.00; weder eine Anfrage noch eine Antwort. Eine leere Nachricht enthält nur den 4-Byte-Header.
Critical Option (Kritische Option) Eine Option, die von dem Endpunkt, der die Nachricht letztendlich empfängt, verstanden werden müsste, um die Nachricht ordnungsgemäß zu verarbeiten (Abschnitt 5.4.1). Beachten Sie, dass die Implementierung kritischer Optionen, wie der Name "Option" impliziert, im Allgemeinen optional ist: Nicht unterstützte kritische Optionen führen zu einer Fehlerantwort oder einer summarischen Ablehnung der Nachricht.
Elective Option (Wahloption) Eine Option, die von einem Endpunkt ignoriert werden soll, der sie nicht versteht. Die Verarbeitung der Nachricht auch ohne Verständnis der Option ist akzeptabel (Abschnitt 5.4.1).
Unsafe Option (Unsichere Option) Eine Option, die von einem Proxy, der die Nachricht empfängt, verstanden werden müsste, um die Nachricht sicher weiterzuleiten (Abschnitt 5.4.2). Nicht jede kritische Option ist eine unsichere Option.
Safe-to-Forward Option (Sicher weiterzuleitende Option) Eine Option, die für die Weiterleitung durch einen Proxy, der sie nicht versteht, sicher sein soll. Die Weiterleitung der Nachricht auch ohne Verständnis der Option ist akzeptabel (Abschnitt 5.4.2).
Resource Discovery (Ressourcenerkennung) Der Prozess, bei dem ein CoAP-Client einen Server nach seiner Liste gehosteter Ressourcen (d. h. Links wie in Abschnitt 7 definiert) abfragt.
Content-Format (Inhaltsformat) Die Kombination aus einem Internet-Medientyp, möglicherweise mit spezifischen angegebenen Parametern, und einer Inhaltscodierung (die oft die Identitäts-Inhaltscodierung ist), identifiziert durch einen numerischen Bezeichner, der durch das "CoAP Content-Formats"-Register definiert ist. Wenn der Fokus weniger auf dem numerischen Bezeichner als auf der Kombination dieser Eigenschaften einer Ressourcenrepräsentation liegt, wird dies auch als "Repräsentationsformat" bezeichnet.
Zusätzliche Terminologie für eingeschränkte Knoten und Netzwerke mit eingeschränkten Knoten findet sich in [RFC7228].
In dieser Spezifikation wird der Begriff "Byte" in seinem mittlerweile üblichen Sinne als Synonym für "Oktett" verwendet.
Alle Mehrbyte-Ganzzahlen in diesem Protokoll werden in Netzwerk-Byte-Reihenfolge interpretiert.
Wo Arithmetik verwendet wird, verwendet diese Spezifikation die aus der Programmiersprache C bekannte Notation, außer dass der Operator "**" für Potenzierung steht.