CoAP：物联网的受限应用协议

需积分: 14 138 浏览量更新于2024-07-15 收藏 423KB PDF 举报

"CoAP_rfc7252.pdf" 本文档详细介绍了Constrained Application Protocol（CoAP），这是一个专为有限节点和受限网络（如低功耗、高丢包率网络）设计的特定于应用的网络传输协议。CoAP是物联网（IoT）领域中用于智能能源、建筑自动化等机器对机器（M2M）应用的重要协议。 CoAP协议的关键特性包括： 1. **请求/响应模型**：CoAP支持应用端点之间的请求/响应交互模式，这类似于HTTP协议。客户端可以向服务器发送请求，服务器则返回响应。 2. **内置服务和资源发现**：CoAP提供了内置的服务和资源发现机制，使得设备能够轻松找到并交互其他设备或资源，这对于物联网环境中的自组织网络非常重要。 3. **URI和互联网媒体类型**：CoAP利用统一资源标识符（URI）来定位资源，与Web概念一致，同时也支持多种互联网媒体类型，允许不同类型的数据显示和交换。 4. **与HTTP的互操作性**：CoAP设计时考虑了与HTTP的轻松接口，以便于与Web集成。通过转换层，CoAP和HTTP之间可以进行通信，从而实现广泛使用的Web服务与受限设备的兼容。 5. **多播支持**：CoAP支持多播，这意味着一个消息可以同时发送到多个目的地，这对于广播消息或在组播网络中进行通信非常有用，降低了网络负载和延迟。 6. **极低的开销**：CoAP设计目标之一是保持非常低的协议开销，以适应资源有限的设备，如8位微控制器。它使用简洁的报文格式，减少了处理和传输所需的内存和计算资源。 7. **适应性**：CoAP能够适应受限网络的条件，如高丢包率。它使用了确认机制和重传策略，确保在网络不稳定时也能可靠地传输数据。 8. **安全性**：虽然文档未详细提及，但RFC7252中会讨论CoAP的安全机制，如使用DTLS（Datagram Transport Layer Security）提供端到端的安全性，保护数据的完整性和隐私。 CoAP协议的设计旨在平衡功能性和效率，使其成为物联网中各种设备间通信的理想选择，尤其是在低功耗和性能受限的环境中。通过这些特性，CoAP能够推动智能设备的普及，并为构建高效、可靠的物联网系统提供基础。

RFC 7252

The Constrained Application Protocol (CoAP) June 2014

Following the Token value comes a sequence of zero or more CoAP

Options in Type-Length-Value (TLV) format, optionally followed by a

payload that takes up the rest of the datagram.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

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

|Ver| T | TKL | Code | Message ID |

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

| Token (if any, TKL bytes) ...

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

| Options (if any) ...

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

|1 1 1 1 1 1 1 1| Payload (if any) ...

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

Figure 7: Message Format

The fields in the header are defined as follows:

Version (Ver): 2-bit unsigned integer. Indicates the CoAP version

number. Implementations of this specification MUST set this field

to 1 (01 binary). Other values are reserved for future versions.

Messages with unknown version numbers MUST be silently ignored.

Type (T): 2-bit unsigned integer. Indicates if this message is of

type Confirmable (0), Non-confirmable (1), Acknowledgement (2), or

Reset (3). The semantics of these message types are defined in

Section 4.

Token Length (TKL): 4-bit unsigned integer. Indicates the length of

the variable-length Token field (0-8 bytes). Lengths 9-15 are

reserved, MUST NOT be sent, and MUST be processed as a message

format error.

Code: 8-bit unsigned integer, split into a 3-bit class (most

significant bits) and a 5-bit detail (least significant bits),

documented as "c.dd" where "c" is a digit from 0 to 7 for the

3-bit subfield and "dd" are two digits from 00 to 31 for the 5-bit

subfield. The class can indicate a request (0), a success

response (2), a client error response (4), or a server error

response (5). (All other class values are reserved.) As a

special case, Code 0.00 indicates an Empty message. In case of a

request, the Code field indicates the Request Method; in case of a

response, a Response Code. Possible values are maintained in the

CoAP Code Registries (

Section 12.1). The semantics of requests

and responses are defined in

Section 5.

Shelby, et al. Standards Track [Page 16]

RFC 7252

The Constrained Application Protocol (CoAP) June 2014

Message ID: 16-bit unsigned integer in network byte order. Used to

detect message duplication and to match messages of type

Acknowledgement/Reset to messages of type Confirmable/Non-

confirmable. The rules for generating a Message ID and matching

messages are defined in

Section 4.

The header is followed by the Token value, which may be 0 to 8 bytes,

as given by the Token Length field. The Token value is used to

correlate requests and responses. The rules for generating a Token

and correlating requests and responses are defined in

Section 5.3.1.

Header and Token are followed by zero or more Options (

Section 3.1).

An Option can be followed by the end of the message, by another

Option, or by the Payload Marker and the payload.

Following the header, token, and options, if any, comes the optional

payload. If present and of non-zero length, it is prefixed by a

fixed, one-byte Payload Marker (0xFF), which indicates the end of

options and the start of the payload. The payload data extends from

after the marker to the end of the UDP datagram, i.e., the Payload

Length is calculated from the datagram size. The absence of the

Payload Marker denotes a zero-length payload. The presence of a

marker followed by a zero-length payload MUST be processed as a

message format error.

Implementation Note: The byte value 0xFF may also occur within an

option length or value, so simple byte-wise scanning for 0xFF is

not a viable technique for finding the payload marker. The byte

0xFF has the meaning of a payload marker only where the beginning

of another option could occur.

3.1. Option Format

CoAP defines a number of options that can be included in a message.

Each option instance in a message specifies the Option Number of the

defined CoAP option, the length of the Option Value, and the Option

Value itself.

Instead of specifying the Option Number directly, the instances MUST

appear in order of their Option Numbers and a delta encoding is used

between them: the Option Number for each instance is calculated as

the sum of its delta and the Option Number of the preceding instance

in the message. For the first instance in a message, a preceding

option instance with Option Number zero is assumed. Multiple

instances of the same option can be included by using a delta of

zero.

Shelby, et al. Standards Track [Page 17]

RFC 7252

The Constrained Application Protocol (CoAP) June 2014

The resulting Option Delta is used as the difference between the

Option Number of this option and that of the previous option (or

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

calculated by simply summing the Option Delta values of this and

all previous options before it.

Option Length: 4-bit unsigned integer. A value between 0 and 12

indicates the length of the Option Value, in bytes. Three values

are reserved for special constructs:

13: An 8-bit unsigned integer precedes the Option Value and

indicates the Option Length minus 13.

14: A 16-bit unsigned integer in network byte order precedes the

Option Value and indicates the Option Length minus 269.

15: Reserved for future use. If the field is set to this value,

it MUST be processed as a message format error.

Value: A sequence of exactly Option Length bytes. The length and

format of the Option Value depend on the respective option, which

MAY define variable-length values. See

Section 3.2 for the

formats used in this document; options defined in other documents

MAY make use of other option value formats.

3.2. Option Value Formats

The options defined in this document make use of the following option

value formats.

empty: A zero-length sequence of bytes.

opaque: An opaque sequence of bytes.

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

order using the number of bytes given by the Option Length

field.

An option definition may specify a range of permissible

numbers of bytes; if it has a choice, a sender SHOULD

represent the integer with as few bytes as possible, i.e.,

without leading zero bytes. For example, the number 0 is

represented with an empty option value (a zero-length

sequence of bytes) and the number 1 by a single byte with

the numerical value of 1 (bit combination 00000001 in most

significant bit first notation). A recipient MUST be

prepared to process values with leading zero bytes.

Shelby, et al. Standards Track [Page 19]

RFC 7252

The Constrained Application Protocol (CoAP) June 2014

Implementation Note: The exceptional behavior permitted

for the sender is intended for highly constrained,

templated implementations (e.g., hardware

implementations) that use fixed-size options in the

templates.

string: A Unicode string that 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 (except where

Unicode strings that are not known to be normalized are

imported from sources outside the CoAP protocol). Note

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

control characters) are always valid UTF-8 Net-Unicode

strings.

4. Message Transmission

CoAP messages are exchanged asynchronously between CoAP endpoints.

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

of which are defined in

Section 5.

As CoAP is bound to unreliable 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.

4.1. Messages and Endpoints

A CoAP endpoint is the source or destination of a CoAP message. The

specific definition of an endpoint depends on the transport being

used for CoAP. For the transports defined in this specification, the

endpoint is identified depending on the security mode used (see

Section 9): With no security, the endpoint is solely identified by an

IP address and a UDP port number. With other security modes, the

endpoint is identified as defined by the security mode.

Shelby, et al. Standards Track [Page 20]

剩余111页未读，继续阅读

田园诗人之园

粉丝: 4084
资源: 14

CoAP：物联网的受限应用协议

coap 概况 中文

RFC7252-CoAP

RFC7252-受限应用协议（CoAP协议中文版）.pdf

emqx3.5怎么配置coap网关

HI3861L 使用coap的示例

undefined reference to 'coap_pdu_get_code'

coap协议C语言实现

emqx安装coap插件

阿里云远程连接，配置libcoap

nginx反向代理coap服务器

最新资源

coap 概况中文