物联网应用协议CoAP详解与实现

需积分: 10 24 浏览量更新于2024-07-16 收藏 176KB PDF 举报

"这篇文章主要介绍了IETF制定的约束应用协议（CoAP），它是一种专为资源受限的设备和网络设计的轻量级Web传输协议。CoAP被设计用于物联网（IoT）场景，如智能能源和建筑自动化，适用于低功耗无线个人区域网络（6LoWPANs）等环境。该协议提供了请求/响应的交互模式，支持服务和资源的内置发现，并结合了URI和互联网媒体类型等Web关键概念。CoAP旨在与HTTP轻松接口，以实现与Web的集成，同时满足特殊需求，如组播支持和极低的开销。" 详细内容：《约束应用协议（CoAP）》是针对物联网环境的一种优化协议，由IETF的CoRE（Constrained RESTful Environments）工作小组提出。由于物联网设备往往具有有限的内存和计算能力，传统的HTTP协议在这种环境下显得过于复杂和资源密集。因此，CoAP应运而生，它是6LoWPAN协议栈中应用层的重要组成部分，专门针对资源受限的设备和网络进行设计。 CoAP的核心特性包括： 1. 请求/响应模型：类似于HTTP，CoAP采用客户端/服务器模型，通过请求-响应模式进行通信。这使得设备可以发起请求获取或更新服务器上的信息。 2. 资源发现：CoAP支持设备和服务的内置发现，允许设备自动查找网络中的可用资源，简化了物联网网络的部署和管理。 3. URI和互联网媒体类型：CoAP使用统一资源标识符（URI）来定位资源，这与HTTP一致，方便与Web的集成。同时，它还支持多种互联网媒体类型，便于处理不同类型的数据。 4. 组播支持：CoAP提供了对组播的支持，使得一条消息可以同时发送到多个接收者，这对于大规模的设备网络尤其有用，例如在智能家居或智能照明系统中。 5. 低开销：为了适应资源有限的环境，CoAP的协议设计尽可能简洁，降低了传输和处理数据所需的计算和存储资源。此外，文章还展示了如何在uIPv6 START KIT无线网络开发套件上，使用Contiki操作系统实现CoAP协议。通过浏览器和自编写的客户端程序，不仅能查看实时数据，还能通过与数据库交互，获取历史数据，这表明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页未读，继续阅读

True92

粉丝: 6
资源: 15

物联网应用协议CoAP详解与实现

RFC7252-CoAP

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

coap 协议 rfc7252

keytool -export -rfc -keystore upload-keystore.jks -alias upload -file upload_certificate.pem

rfc1305-1992

rfc全部文档离线下载rfc1-rfc8505

rfc3261中文版 pdf 下载

DeprecationWarning: Setting the TLS ServerName to an IP address is not permitted by RFC 6066. This will be ignored in a future version. (Use `node --trace-deprecation ...` to show where the warning was created)

30[单选题]下列哪个是网络标准化组织?-|||-○ A.ISO-|||-○ B.IEEE-|||-○ C.IETF-|||-○ D.W3C

最新资源