COAP协议
COAP协议
1.1. Features
CoAP has the following main features:
o Web protocol fulfilling M2M requirements in constrained
environments
o UDP [RFC0768] binding with optional reliability supporting unicast
and multicast requests.
o Asynchronous message exchanges.
o Low header overhead and parsing complexity.
o URI and Content-type support.
o Simple proxy and caching capabilities.
Shelby, et al. Standards Track [Page 5]
RFC 7252 The Constrained Application Protocol (CoAP) June 2014
o A stateless HTTP mapping, allowing proxies to be built providing
access to CoAP resources via HTTP in a uniform way or for HTTP
simple interfaces to be realized alternatively over CoAP.
o Security binding to Datagram Transport Layer Security (DTLS)
[RFC6347].
RFC 7252: The Constrained Application Protocol (CoAP) https://www.rfc-editor.org/rfc/rfc7252
2. Constrained Application Protocol
The interaction model of CoAP is similar to the client/server model
of HTTP. However, machine-to-machine interactions typically result
in a CoAP implementation acting in both client and server roles. A
CoAP request is equivalent to that of HTTP and is sent by a client to
request an action (using a Method Code) on a resource (identified by
a URI) on a server. The server then sends a response with a Response
Code; this response may include a resource representation.
Unlike HTTP, CoAP deals with these interchanges asynchronously over a
datagram-oriented transport such as UDP. This is done logically
using a layer of messages that supports optional reliability (with
exponential back-off). CoAP defines four types of messages:
Confirmable, Non-confirmable, Acknowledgement, Reset. Method Codes
and Response Codes included in some of these messages make them carry
requests or responses. The basic exchanges of the four types of
messages are somewhat orthogonal to the request/response
interactions; requests can be carried in Confirmable and Non-
confirmable messages, and responses can be carried in these as well
as piggybacked in Acknowledgement messages.
One could think of CoAP logically as using a two-layer approach, a
CoAP messaging layer used to deal with UDP and the asynchronous
nature of the interactions, and the request/response interactions
using Method and Response Codes (see Figure 1). CoAP is however a
single protocol, with messaging and request/response as just features
of the CoAP header.
+----------------------+
| Application |
+----------------------+
+----------------------+ \
| Requests/Responses | |
|----------------------| | CoAP
| Messages | |
+----------------------+ /
+----------------------+
| UDP |
+----------------------+
Figure 1: Abstract Layering of CoAP
Confirmable Message
Some messages require an acknowledgement. These messages are
called "Confirmable". When no packets are lost, each Confirmable
message elicits exactly one return message of type Acknowledgement
or type Reset.
Non-confirmable Message
Some other messages do not require an acknowledgement. This is
particularly true for messages that are repeated regularly for
application requirements, such as repeated readings from a sensor.
Acknowledgement Message
An Acknowledgement message acknowledges that a specific
Confirmable message arrived. By itself, an Acknowledgement
message does not indicate success or failure of any request
encapsulated in the Confirmable message, but the Acknowledgement
message may also carry a Piggybacked Response (see below).
Reset Message
A Reset message indicates that a specific message (Confirmable or
Non-confirmable) was received, but some context is missing to
properly process it. This condition is usually caused when the
receiving node has rebooted and has forgotten some state that
would be required to interpret the message. Provoking a Reset
message (e.g., by sending an Empty Confirmable message) is also
useful as an inexpensive check of the liveness of an endpoint
("CoAP ping").
Piggybacked Response
A piggybacked Response is included right in a CoAP Acknowledgement
(ACK) message that is sent to acknowledge receipt of the Request
for this Response (Section 5.2.1).
Separate Response
When a Confirmable message carrying a request is acknowledged with
an Empty message (e.g., because the server doesn't have the answer
right away), a Separate Response is sent in a separate message
exchange (Section 5.2.2).
Empty Message
A message with a Code of 0.00; neither a request nor a response.
An Empty message only contains the 4-byte header.
Shelby, et al. Standards Track [Page 10]
RFC 7252 The Constrained Application Protocol (CoAP) June 2014
2.1. Messaging Model
The CoAP messaging model is based on the exchange of messages over
UDP between endpoints.
CoAP uses a short fixed-length binary header (4 bytes) that may be
followed by compact binary options and a payload. This message
format is shared by requests and responses. The CoAP message format
is specified in Section 3. Each message contains a Message ID used
to detect duplicates and for optional reliability. (The Message ID
is compact; its 16-bit size enables up to about 250 messages per
second from one endpoint to another with default protocol
parameters.)
Reliability is provided by marking a message as Confirmable (CON). A
Confirmable message is retransmitted using a default timeout and
exponential back-off between retransmissions, until the recipient
sends an Acknowledgement message (ACK) with the same Message ID (in
this example, 0x7d34) from the corresponding endpoint; see Figure 2.
When a recipient is not at all able to process a Confirmable message
(i.e., not even able to provide a suitable error response), it
replies with a Reset message (RST) instead of an Acknowledgement
(ACK).
Client Server
| |
| CON [0x7d34] |
+----------------->|
| |
| ACK [0x7d34] |
|<-----------------+
| |
Figure 2: Reliable Message Transmission
A message that does not require reliable transmission (for example,
each single measurement out of a stream of sensor data) can be sent
as a Non-confirmable message (NON). These are not acknowledged, but
still have a Message ID for duplicate detection (in this example,
0x01a0); see Figure 3. When a recipient is not able to process a
Non-confirmable message, it may reply with a Reset message (RST).
Shelby, et al. Standards Track [Page 11]
RFC 7252 The Constrained Application Protocol (CoAP) June 2014
Client Server
| |
| NON [0x01a0] |
+----------------->|
| |
Figure 3: Unreliable Message Transmission
See Section 4 for details of CoAP messages.
As CoAP runs over UDP, it also supports the use of multicast IP
destination addresses, enabling multicast CoAP requests. Section 8
discusses the proper use of CoAP messages with multicast addresses
and precautions for avoiding response congestion.
Several security modes are defined for CoAP in Section 9 ranging from
no security to certificate-based security. This document specifies a
binding to DTLS for securing the protocol; the use of IPsec with CoAP
is discussed in [IPsec-CoAP].
2.2. Request/Response Model
CoAP request and response semantics are carried in CoAP messages,
which include either a Method Code or Response Code, respectively.
Optional (or default) request and response information, such as the
URI and payload media type are carried as CoAP options. A Token is
used to match responses to requests independently from the underlying
messages (Section 5.3). (Note that the Token is a concept separate
from the Message ID.)
A request is carried in a Confirmable (CON) or Non-confirmable (NON)
message, and, if immediately available, the response to a request
carried in a Confirmable message is carried in the resulting
Acknowledgement (ACK) message. This is called a piggybacked
response, detailed in Section 5.2.1. (There is no need for
separately acknowledging a piggybacked response, as the client will
retransmit the request if the Acknowledgement message carrying the
piggybacked response is lost.) Two examples for a basic GET request
with piggybacked response are shown in Figure 4, one successful, one
resulting in a 4.04 (Not Found) response.
Shelby, et al. Standards Track [Page 12]
RFC 7252 The Constrained Application Protocol (CoAP) June 2014
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" |
|<-----------------+ |<-----------------+
| | | |
Figure 4: Two GET Requests with Piggybacked Responses
If the server is not able to respond immediately to a request carried
in a Confirmable message, it simply responds with an Empty
Acknowledgement message so that the client can stop retransmitting
the request. When the response is ready, the server sends it in a
new Confirmable message (which then in turn needs to be acknowledged
by the client). This is called a "separate response", as illustrated
in Figure 5 and described in more detail in Section 5.2.2.
Client Server
| |
| CON [0x7a10] |
| GET /temperature |
| (Token 0x73) |
+----------------->|
| |
| ACK [0x7a10] |
|<-----------------+
| |
... Time Passes ...
| |
| CON [0x23bb] |
| 2.05 Content |
| (Token 0x73) |
| "22.5 C" |
|<-----------------+
| |
| ACK [0x23bb] |
+----------------->|
| |
Figure 5: A GET Request with a Separate Response
Shelby, et al. Standards Track [Page 13]
RFC 7252 The Constrained Application Protocol (CoAP) June 2014
If a request is sent in a Non-confirmable message, then the response
is sent using a new Non-confirmable message, although the server may
instead send a Confirmable message. This type of exchange is
illustrated in Figure 6.
Client Server
| |
| NON [0x7a11] |
| GET /temperature |
| (Token 0x74) |
+----------------->|
| |
| NON [0x23bc] |
| 2.05 Content |
| (Token 0x74) |
| "22.5 C" |
|<-----------------+
| |
Figure 6: A Request and a Response Carried in Non-confirmable
Messages
CoAP makes use of GET, PUT, POST, and DELETE methods in a similar
manner to HTTP, with the semantics specified in Section 5.8. (Note
that the detailed semantics of CoAP methods are "almost, but not
entirely unlike" [HHGTTG] those of HTTP methods: intuition taken from
HTTP experience generally does apply well, but there are enough
differences that make it worthwhile to actually read the present
specification.)
Methods beyond the basic four can be added to CoAP in separate
specifications. New methods do not necessarily have to use requests
and responses in pairs. Even for existing methods, a single request
may yield multiple responses, e.g., for a multicast request
(Section 8) or with the Observe option [OBSERVE].
URI support in a server is simplified as the client already parses
the URI and splits it into host, port, path, and query components,
making use of default values for efficiency. Response Codes relate
to a small subset of HTTP status codes with a few CoAP-specific codes
added, as defined in Section 5.9.
