CoAP协议详解：物联网低功耗网络的标准规范

下载需积分: 34 | PDF格式 | 169KB | 更新于2024-07-22 | 29 浏览量 | 举报

1 收藏

CoAP标准参考文档详细阐述了由Internet Engineering Task Force (IETF) 设计并发布的Constrained Application Protocol (CoAP)，RFC 7252版本由Z. Shelby、K. Hartke和C. Bormann共同编撰，于2014年6月发布。这份文档针对的是物联网(IoT)环境中特别设计的应用协议，目标是与低功耗、数据丢失率高的网络环境，如IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)等配合使用。 CoAP的主要特点是它为资源受限（如8位微控制器和小内存）的节点设计，旨在支持机器对机器(M2M)应用，比如智能家居和智能建筑自动化。协议的核心交互模型是基于请求/响应机制，允许应用程序端点之间进行高效通信。它内置了服务和资源的自动发现功能，借鉴了Web的关键概念，如Uniform Resource Identifiers (URIs) 和 Internet Media Types (MIME类型)。为了兼容互联网，并满足特殊需求，CoAP设计时考虑了以下几点： 1. **易集成与HTTP**：尽管专为M2M场景优化，但CoAP被设计成能够轻松与超文本传输协议(HTTP)协同工作，以便在物联网中无缝融入Web架构。 2. **多播支持**：CoAP支持多播，使得单个消息可以同时发送给多个接收者，提高了数据传输效率。 3. **低开销**：考虑到物联网设备的资源限制，CoAP注重减少协议头部和数据包的大小，以降低通信成本。 4. **错误处理**：在高丢包率的网络环境下，CoAP具有容错机制，能有效处理通信中的错误。 5. **网络效率**：通过优化的传输层机制，如无连接的交换模式，CoAP能够在低带宽条件下提供稳定的性能。 CoAP标准文档为物联网开发人员提供了关于如何在资源受限的网络中实现高效、可靠且节能的数据传输的重要指南，是构建和部署IoT应用不可或缺的技术基石。

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页未读，继续阅读

wangdawei_1980

粉丝: 1
资源: 8

CoAP协议详解：物联网低功耗网络的标准规范

C语言实现的Lobaro-CoAP: 嵌入式系统中的CoAP协议

Node.js中CoAP协议的客户端和服务器库实现

SIM7020C模块全面技术文档指南

CoAP_specification

LwIP协议深度剖析与实战演练_coap_mqtt_spec

ISO IEC标准 Internet of things (物联网) - Vocabulary -完整英文版（12页）.pdf

RFC文档RFC文档RFC文档RFC文档

wotkit-docs:WoTKit公共文档

行业文档-设计装置-一种基于云服务平台的自动扶梯的远程实时检测终端.zip

LwM2M技术规范v1.0.2官方文档

最新资源