RFC7252详解：约束应用协议（CoAP）

需积分: 9 132 浏览量更新于2024-07-18 收藏 373KB PDF 举报

身份认证购VIP最低享 7 折!

30元优惠券

"rfc7252是关于Constrained Application Protocol (CoAP)的协议文档，该协议是2014年的版本，主要应用于物联网(IoT)领域，特别是针对资源有限的设备和低功耗、高丢包率的网络环境。CoAP是一种专门设计用于机器对机器(M2M)应用的协议，如智能能源和建筑自动化。" 在物联网环境中，CoAP协议扮演着重要的角色。RFC 7252详细定义了CoAP的设计原理和操作机制，它提供了一个请求/响应的交互模型，允许应用端点之间进行通信。这种模型类似于HTTP，但更加适合低功耗和资源受限的设备。CoAP的核心特性包括： 1. **服务和资源发现**：CoAP支持内置的服务和资源发现功能，允许设备在连接到网络后自动发现和交互其他设备或服务。 2. **URI和互联网媒体类型**：与万维网(www)兼容，CoAP使用统一资源标识符(URI)来标识网络上的资源，并支持多种互联网媒体类型，以表示不同类型的资源数据。 3. **与HTTP的互操作性**：尽管CoAP是为低功耗环境设计的，但它可以轻松与HTTP接口，以便于与传统Web服务集成。这通过CoAP的DTLS（Datagram Transport Layer Security）安全层和CoAP-to-HTTP转换机制实现。 4. **多播支持**：CoAP支持多播通信，使得一个请求可以同时到达多个目的地，这对于大规模的设备管理，如智能家居或智能电网的同步操作非常有用。 5. **低开销**：为了适应资源有限的设备，CoAP设计得非常轻量级，具有极低的协议开销，以减少传输数据时的能量消耗和网络拥堵。 6. **适应性**：CoAP能够适应网络条件的变化，比如在网络质量差的环境下，它能通过重传机制和确认机制保证消息的可靠传输。 7. **安全性**：虽然没有在描述中直接提及，但CoAP提供了DTLS安全协议，用于加密和认证通信，保护物联网设备免受攻击。 RFC 7252定义的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页未读，继续阅读

charmousl

粉丝: 0
资源: 3

RFC7252详解：约束应用协议（CoAP）

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

RFC7252-CoAP

coap 协议 rfc7252

rfc768协议 crc16

java RFC3164 协议解析

rdp8.0协议 rfc文档

关于udp协议的rfc文档

rfc3261(sip协议)中文版

定义应用层协议端口号的rfc

rfc959 ftp传输协议(中文版)下载

OMCI 协议RFC

详细讲解一下rfc 5246

rfc9000文档下载

rfc 7230 and rfc 3986

ipv6 rfc相关文档

XML标准和RFC官方文档

lacp的rfc文档

rfc 3550 中文版

rfc1332.txt

specify the rfc 5246

最新资源