CoAP：约束应用协议详解

5星 · 超过95%的资源需积分: 9 183 浏览量更新于2024-07-30 收藏 213KB PDF 举报

"Constrained Application Protocol (CoAP) 是一种针对受限网络和节点的专用Web传输协议，常用于物联网（IoT）场景，如智能能源和建筑自动化。它由CoRE工作组的Z. Shelby、Sensinode公司、K. Hartke、Universitaet Bremen TZI的C. Bormann以及SkyFoundry的B. Frank共同制定，并在草案draft-ietf-core-coap-06中详细描述。" 《Constrained Application Protocol (CoAP)》文档定义了在资源受限的网络和设备上使用的CoAP，它是HTTP的一个精简子集，旨在满足低功耗、低内存、低带宽的环境需求。这些受限的节点通常配备8位微控制器，拥有少量的ROM和RAM，而如6LoWPAN这样的网络可能具有高丢包率和约10kbps的典型吞吐量。 CoAP的核心特性包括： 1. 方法/响应交互模型：CoAP提供了一种在应用程序端点之间进行方法调用和响应的交互方式，类似于HTTP的请求/响应模式。 2. 内置资源发现：支持节点间的资源发现功能，使得设备可以轻松找到和访问网络上的其他资源。 3. Web概念集成：协议包含关键的Web概念，如统一资源标识符（URI）和内容类型，这使得CoAP能够与Web无缝对接。 4. HTTP兼容性：CoAP设计成可以很容易地转换为HTTP，以便与Web服务集成，同时仍能满足特殊需求，如多播支持、极低的开销和对受限环境的简单操作。该文档的意图状态为“标准轨道”，表明CoAP正在朝着成为互联网标准的方向发展。此Internet-Draft的提交完全符合IETF的流程，其有效期至2011年11月5日。 CoAP的适用性和优势在于其设计时考虑了物联网环境中的诸多挑战，例如： - 低功耗：CoAP的简洁设计减少了处理和传输的能耗，这对于电池供电或能量采集的设备至关重要。 - 高错误率网络适应：在网络条件差的情况下，CoAP依然能保持可靠的数据传输。 - 多播支持：CoAP支持多播通信，允许一次消息广播到多个接收者，提高了效率并降低了网络负载。 - 小型化：CoAP协议栈适合在资源有限的设备上运行，如8位微控制器。 CoAP是物联网领域的关键协议之一，它在保留Web服务基本特性的同时，针对受限环境进行了优化，确保了高效、可靠且易于实施的通信。随着物联网的快速发展，CoAP在智能家居、智能城市等领域的应用前景广阔。

Internet-Draft Constrained Application Protocol (CoAP) May 2011

3.1.1. Message Size Implementation Considerations

Note that CoAP’s choice of message size parameters works well with

IPv6 and with most of today’s IPv4 paths. (However, with IPv4, it is

harder to absolutely ensure that there is no IP fragmentation. If

IPv4 support on unusual networks is a consideration, implementations

may want to limit themselves to more conservative IPv4 datagram sizes

such as 576 bytes; worse, the absolute minimum value of the IP MTU

for IPv4 is as low as 68 bytes, which would leave only 40 bytes minus

security overhead for a UDP payload. Implementations extremely

focused on this problem set might also set the IPv4 DF bit and

perform some form of path MTU discovery; this should generally be

unnecessary in most realistic use cases for CoAP, however.) A more

important kind of fragmentation in many constrained networks is that

on the adaptation layer (e.g., 6LoWPAN L2 packets are limited to 127

bytes including various overheads); this may motivate implementations

to be frugal in their packet sizes and to move to block-wise

transfers [I-D.ietf-core-block] when approaching three-digit message

sizes.

Note that message sizes are also of considerable importance to

implementations on constrained nodes. Many implementations will need

to allocate a buffer for incoming messages. If an implementation is

too constrained to allow for allocating the above-mentioned upper

bound, it could apply the following implementation strategy:

Implementations receiving a datagram into a buffer that is too small

are usually able to determine if the trailing portion of a datagram

was discarded and to retrieve the initial portion. So, if not all of

the payload, at least the CoAP header and options are likely to fit

within the buffer. A server can thus fully interpret a request and

return a 4.13 (Request Entity Too Large) response code if the payload

was truncated. A client sending an idempotent request and receiving

a response larger than would fit in the buffer can repeat the request

with a suitable value for the Block Option [I-D.ietf-core-block].

3.2. Option Format

Options MUST appear in order of their Option Number (see

Section 5.4.5). A delta encoding is used between options, with the

Option Number for each Option calculated as the sum of its Option

Delta field and the Option Number of the preceding Option in the

message, if any, or zero otherwise. Multiple options with the same

Option Number can be included by using an Option Delta of zero.

Following the Option Delta, each option has a Length field which

specifies the length of the Option Value, in bytes. The Length field

can be extended by one byte for options with values longer than 14

bytes. The Option Value immediately follows the Length field.

Shelby, et al. Expires November 5, 2011 [Page 14]

Internet-Draft Constrained Application Protocol (CoAP) May 2011

0 1 2 3 4 5 6 7

+---+---+---+---+---+---+---+---+

| Option Delta | Length | for 0..14

+---+---+---+---+---+---+---+---+

| Option Value ...

+---+---+---+---+---+---+---+---+

for 15..270:

+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

| Option Delta | 1 1 1 1 | Length - 15 |

+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

| Option Value ...

+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Figure 8: Option Format

The fields in an option are defined as follows:

Option Delta: 4-bit unsigned integer. Indicates the difference

between the Option Number of this option and the previous option

(or zero for the first option). In other words, the Option Number

is calculated by simply summing the Option Delta fields of this

and previous options before it. The Option Numbers 14, 28, 42,

... are reserved for no-op options when they are sent with an

empty value (they are ignored) and can be used as "fenceposts" if

deltas larger than 15 would otherwise be required.

Length: Indicates the length of the Option Value, in bytes.

Normally Length is a 4-bit unsigned integer allowing value lengths

of 0-14 bytes. When the Length field is set to 15, another byte

is added as an 8-bit unsigned integer whose value is added to the

15, allowing option value lengths of 15-270 bytes.

The length and format of the Option Value depends on the respective

option, which MAY define variable length values. Options defined in

this document make use of the following formats for option values:

uint: A non-negative integer which is represented in network byte

order using a variable number of bytes (see Appendix A).

string: A Unicode string which is encoded using UTF-8 [RFC3629] in

Net-Unicode form [RFC5198]. Note that here and in all other

places where UTF-8 encoding is used in the CoAP protocol, the

intention is that the encoded strings can be directly used and

compared as opaque byte strings by CoAP protocol

implementations. There is no expectation and no need to

perform normalization within a CoAP implementation unless

Unicode strings that are not known to be normalized are

imported from sources outside the CoAP protocol. Note also

Shelby, et al. Expires November 5, 2011 [Page 15]

Internet-Draft Constrained Application Protocol (CoAP) May 2011

that ASCII strings (that do not make use of special control

characters) are always valid UTF-8 Net-Unicode strings.

opaque: An opaque sequence of bytes.

Option Numbers are maintained in the CoAP Option Number Registry

(Section 11.2). See Section 5.10 for the semantics of the options

defined in this document.

4. Message Semantics

CoAP messages are exchanged asynchronously between CoAP end-points.

They are used to transport CoAP requests and responses, the semantics

of which are defined in Section 5.

As CoAP is bound to non-reliable transports such as UDP, CoAP

messages may arrive out of order, appear duplicated, or go missing

without notice. For this reason, CoAP implements a lightweight

reliability mechanism, without trying to re-create the full feature

set of a transport like TCP. It has the following features:

o Simple stop-and-wait retransmission reliability with exponential

back-off for "confirmable" messages.

o Duplicate detection for both "confirmable" and "non-confirmable"

messages.

o Multicast support.

4.1. Reliable Messages

The reliable transmission of a message is initiated by marking the

message as "confirmable" in the CoAP header. A recipient MUST

acknowledge such a message with an acknowledgement message (or, if it

lacks context to process the message properly, MUST reject it with a

reset message). The sender retransmits the confirmable message at

exponentially increasing intervals, until it receives an

acknowledgement (or reset message), or runs out of attempts.

Retransmission is controlled by two things that a CoAP end-point MUST

keep track of for each confirmable message it sends while waiting for

an acknowledgement (or reset): a timeout and a retransmission

counter. For a new confirmable message, the initial timeout is set

to a random number between RESPONSE_TIMEOUT and (RESPONSE_TIMEOUT *

RESPONSE_RANDOM_FACTOR), and the retransmission counter is set to 0.

When the timeout is triggered and the retransmission counter is less

than MAX_RETRANSMIT, the message is retransmitted, the retransmission

Shelby, et al. Expires November 5, 2011 [Page 16]

Internet-Draft Constrained Application Protocol (CoAP) May 2011

counter is incremented, and the timeout is doubled. If the

retransmission counter reaches MAX_RETRANSMIT on a timeout, or if the

end-point receives a reset message, then the attempt to transmit the

message is canceled and the application process informed of failure.

On the other hand, if the end-point receives an acknowledgement

message in time, transmission is considered successful.

An acknowledgement or reset message is related to a confirmable

message by means of a Message ID. The Message ID is a 16-bit

unsigned integer that is generated by the sender of a confirmable

message and included in the CoAP header. The Message ID MUST be

echoed in the acknowledgement or reset message by the recipient. A

CoAP end-point generates Message IDs by keeping a single Message ID

variable, which is changed each time a new confirmable message is

sent regardless of the destination address or port. The initial

variable value SHOULD be randomized. The same Message ID MUST NOT be

re-used within the potential retransmission window, calculated as

RESPONSE_TIMEOUT * RESPONSE_RANDOM_FACTOR * (2 ^ MAX_RETRANSMIT - 1)

plus the expected maximum round trip time.

A recipient MUST be prepared to receive the same confirmable message

(as indicated by the Message ID) multiple times, for example, when

its acknowledgement went missing or didn’t reach the original sender

before the first timeout. The recipient SHOULD acknowledge each

duplicate copy of a confirmable message using the same

acknowledgement or reset message, but SHOULD process any request or

response in the message only once. This rule MAY be relaxed in case

the confirmable message transports a request that is idempotent (see

Section 5.1). Examples for relaxed message deduplication:

o A server MAY relax the requirement to answer all retransmissions

of an idempotent request with the same response (Section 4.1), so

that it does not have to maintain state for Message IDs. For

example, an implementation might want to process duplicate

transmissions of a GET, PUT or DELETE request as separate requests

if the effort incurred by duplicate processing is less expensive

than keeping track of previous responses would be.

o (As an implementation consideration, a constrained server MAY even

want to relax this requirement for certain non-idempotent requests

if the application semantics make this trade-off favorable. For

example, if the result of a POST request is just the creation of

some short-lived state at the server, it may be less expensive to

incur this effort multiple times for a request than keeping track

of whether a previous transmission of the same request already was

processed.)

Implementation notes: Note that a CoAP end-point that sent a

Shelby, et al. Expires November 5, 2011 [Page 17]

剩余80页未读，继续阅读

xueqiao_

粉丝: 0
资源: 5

CoAP：约束应用协议详解

RFC7252-The Constrained Application Protocol (CoAP) - en.pdf

COAP - The Constrained Application Protocol文件格式

tinycoap:TinyOS的CoAP实施-开源

Constrained Application Protocol for Low Power.pdf

Constrained Application Protocol: Python:过时：请参阅 libcoap-开源

chance-constrained-knapsack-one-plus-one

RFC8516 "Too Many Requests" Response Code for Constrained Application Protocol

constrained-hamiltonian-neural-networks

constrained-extreme-learning-machine-master__machinelear

matlab精度检验代码-Locality-constrained-Linear-Coding-for-Image-Classificatio

最新资源