概述CoAP协议-编程知识

概述

1 认识CoAP协议

2 CoAP的消息

2.1 CoAP消息类型

2.2 可靠传输和不可靠传输

2.2.1 可靠传输

2.2.2 不可靠消息

2.3 Request/Response Model

3 CoAP消息的格式

3.1 格式介绍

3.2 协议分析

4 CoAP URL

4.1 coap URI Scheme

4.2 coaps URI Scheme

5 CoAP-HTTP Proxying

5.1 GET

5.2 PUT

5.3 DELETE

5.4 POST

6 HTTP-CoAP Proxying

6.1 GET

6.2 HEAD

6.3 POST

6.4 PUT

6.5 DELETE

6.6 CONNECT

7 CoAP Code

7.1 Method Codes

7.2 Response Codes

8 参考资料：

概述

本文主要介绍CoAP的一些知识，CoAP协议是一个非常庞大的系统，不可能在一篇文章中面面俱到。笔者根据自己实际应用的需要，将一些可能使用的重要知识点罗列出来，便于工作和学习中查阅。

1 认识CoAP协议

CoAP（Constrained Application Protocol）是一种专为物联网设备设计的轻量级通信协议。它在UDP（User Datagram Protocol）上运行，具有低带宽和低能耗的特点，适用于资源受限的网络环境。

以下是CoAP协议的一些重要特性：

轻量级：COAP协议使用简单的二进制格式，占用较少的网络带宽和资源。它可以在嵌入式系统等资源受限的设备上运行。
简单性：COAP协议定义了一组简单的方法来进行通信，包括GET、POST、PUT和DELETE等。这使得开发者可以轻松地实现和使用COAP协议。
可靠性：COAP协议在传输层使用了可靠的确认和重传机制，以确保数据的可靠传输。它还支持重复消除，以避免重复请求。
低能耗：COAP协议的设计考虑了物联网设备的低能耗需求。它使用了一些技术来减少通信的能耗，如触发式通信和低功耗传输模式。
安全性：COAP协议支持基于DTLS（Datagram Transport Layer Security）的安全传输。它可以使用加密和身份验证来保护通信的安全性。

COAP协议主要用于物联网设备之间的通信，支持各种应用场景，如智能家居、工业自动化和智能城市等。它提供了一种简单、可靠和高效的通信方式，以满足物联网设备的通信需求。

2 CoAP的消息

2.1 CoAP消息类型

CoAP的消息类型总共有四种，其总结如下

消息类型	说明
CON	需要被确认的请求，如果CON请求被发送，那么对方必须做出响应。这有点像TCP，对方必须给确认收到消息，用以可靠消息传输。
NON	不需要被确认的请求，如果NON请求被发送，那么对方不必做出回应。这适用于消息会重复频繁的发送，丢包不影响正常操作。这个和UDP很像。用以不可靠消息传输。
ACK	应答消息，对应的是CON消息的应答。
RST	复位消息，可靠传输时候接收的消息不认识或错误时，不能回ACK消息，必须回RST消息。

2.2 可靠传输和不可靠传输

2.2.1 可靠传输

在CoAP协议框架下，CON类型的消息被称作为可靠传输，Client发送消息至Server。Server在接收到消息后，必须对其作出响应。

2.2.2 不可靠消息

在CoAP协议框架下，NON类型的消息被称作为不可靠传输，Client发送消息至Server。Server在接收到消息后，不需要对其作出响应。

2.3 Request/Response Model

CoAP请求和响应语义在CoAP消息中携带，其中分别包括方法代码或响应代码。可选的(或默认的)请求和响应信息，例如URI和有效负载媒体类型作为CoAP选项携带。令牌是用于独立于底层匹配对请求的响应消息。(请注意，Token是一个单独的概念从消息ID。)

请求以可确认(CON)或非可确认(NON)方式传送。消息，如果立即可用，则返回对请求的响应
在可确认消息中携带的消息在结果中携带确认(ACK)消息。这被称为“piggy-backed”响应)没有必要像客户端那样，单独确认一个附带的响应如果确认消息携带不抱希望的回应是失败的。)两个基本GET请求的示例如图4所示，一个成功，一个导致4.04(未找到)响应。

如果服务器不能立即响应承载的请求在Confirmable消息中，它只是用一个Empty来响应确认消息，以便客户端可以停止重传请求。当响应准备好时，服务器将其发送到新的可确认消息(然后需要确认)由客户端决定。

如果请求以非确认消息的形式发送，则响应使用新的非确认消息发送，尽管服务器可以
而是发送一条confirable消息。

3 CoAP消息的格式

3.1 格式介绍

CoAP消息的格式如下：

CoAP头部：包含了消息的版本、类型、代码、标识符和选项字段的信息。

CoAP头部信息	说明
版本	CoAP协议的版本号。
类型	消息的类型，包括CON（可靠性传输）、NON（非可靠性传输）、ACK、RST等。
代码	消息的操作码，表示请求类型（GET、POST、PUT、DELETE）或响应类型（成功、错误等）。
标识符	用于区分不同CoAP消息的唯一标识符。
选项字段	可选的参数，用于传输额外的信息。

CoAP选项：可选的参数，用于传输额外的信息。

CoAP选项	说明
编号	表示此选项的类型。
长度	选项值的长度。
选项值	具体的选项值。

CoAP负载：用于传输应用层数据。

3.2 协议分析

CoAP基于压缩消息的交换，默认情况下，通过UDP传输(即，每个CoAP消息占用数据一个UDP数据报的部分)。CoAP也可以在数据报上使用传输层安全性(DTLS)。也可能是在其他传输(如SMS、TCP或SCTP)上使用的其规格超出了本文档的范围

CoAP消息以简单的二进制格式编码。的消息Format以固定大小的4字节头开始。后面跟着a
variable-length令牌值，长度在0到8字节之间。以上翻译结果来自有道神经网络翻译（YNMT）· 通用场景。Token值之后是一个由0个或多个CoAP组成的序列TLV (Type-Length-Value)格式的选项，后面可选地跟一个占用数据报其余部分的有效负载。

消息头部分内容

Version (Ver):

2位无符号整数。CoAP版本号号码。此规范的实现必须设置此字段到1(01二进制)。其他值为以后的版本保留。版本号未知的消息必须被静默忽略。

Type (T):

2位无符号整数。指示此消息是否为类型可确认(0)、不可确认(1)、确认(2)或Reset(3)

Token Length (TKL):

4位无符号整数。的长度。可变长度Token字段(0-8字节)。长度9-15是保留，MUST不能发送，并且必须作为消息处理格式错误。

Code:

数据类型：8位无符号整数。拆分为3位类(大多数)有效位)和5位细节(最低有效位)，文档记录为"c.d "，其中"c"是0到7之间的数字3位子字段和“dd”是5位从00到31的两位数字子域。该类可以指示一个请求(0)，一个成功响应(2)、客户端错误响应(4)或服务器错误response(5).(保留所有其他类的值。)作为一个特殊情况下，代码0.00表示空消息。如果…请求时，Code字段表示请求方法;如果…response，一个响应代码。

Message ID:

数据类型：16位无符号整数网络字节顺序。用于检测消息重复并匹配类型的消息确认/重置为可确认/非确认类型的消息可证实的。

4 CoAP URL

CoAP使用“CoAP”和“coaps”URI模式来标识CoAP资源并提供定位资源的方法。资源是否按等级组织并由潜在的CoAP起源管理侦听CoAP请求(“CoAP”)或dtls安全CoAP的服务器在给定的UDP端口上请求(“coaps”)。CoAP服务器为通过泛型语法的权限组件标识，该组件包括一个主机组件和可选的UDP端口号。的URI的剩余部分被认为是标识一个资源可以通过CoAP协议定义的方法进行操作。因此，可以将“coap”和“coaps”URI模式与“http”和“coaps”URI模式进行比较"https" URI方案。

4.1 coap URI Scheme

coap-URI = "coap:" "//" host [ ":" port ] path-abempty [ "?" query ]

如果主机组件作为ip字面值或IPv4address提供，那么就可以通过该IP地址访问CoAP服务器。如果host是已注册的名称，则该名称被视为间接标识符端点可以使用名称解析服务(如DNS)来找到该主机的地址。主机不能为空;如果一个URI接收到的权限缺失或主机空，那么必须被认为无效。port子组件表示UDP端口CoAP服务器所在的位置。如果它是空的或者没有给出，然后假定缺省端口为5683。

路径标识主机和端口范围内的资源。它由一系列用斜杠分隔的路径段组成字符(U+002F SOLIDUS "/")。该查询用于进一步参数化资源。它由由一个&字符 (U+0026 AMPERSAND "&")分隔的参数序列。常用的格式为：“key=value”。

4.2 coaps URI Scheme

coaps-URI = "coaps:" "//" host [ ":" port ] path-abempty  [ "?" query ]

上述“覆盖”计划的所有要求也是除了一个默认的UDP端口如果端口子组件为空或，则假设[IANA_TBD_PORT]，并且UDP数据报必须通过使用DTLS。

通过“coaps”方案提供的资源没有共享使用“coap”方案标识，即使它们的资源标识符也是如此
表示相同的授权机构(侦听相同UDP的相同主机)端口)。它们是不同的名称空间，并且被认为是
不同的原始服务器。

5 CoAP-HTTP Proxying

如果请求包含代理uri或代理方案选项'http'或'https' URI ，然后是接收CoAP端点(以后称为“代理”)被请求执行操作由请求方法指定的HTTP资源和将结果返回给客户端。此部分为任何CoAP请求指定CoAP响应代理应该返回到客户端。代理是如何满足请求是一个实现细节，尽管典型的预期案例是代理翻译和转发将请求发送到HTTP源服务器。由于HTTP和CoAP共享基本的请求方法集，在HTTP资源上执行CoAP请求并没有太大的不同在CoAP资源上执行它。的含义在HTTP资源上执行单个CoAP方法时在本节的子节中解释。如果代理不能或不愿意使用HTTP URI，则返回5.05(不支持代理)响应客户端。如果代理通过与第三方(如HTTP源服务器)，无法获取在一个合理的时间框架内得到一个结果，一个5.04(网关超时)返回响应;如果一个结果可以得到，但没有得到理解后，返回5.02(坏网关)响应。

5.1 GET

方法请求代理返回控件的表示形式由请求URI标识的HTTP资源。如果成功，应该返回一个2.05 (Content)响应码。的响应的有效载荷必须是目标HTTP的表示形式资源，并相应地设置内容格式选项。响应必须指示一个Max-Age值，该值不能大于剩下的时间可以被认为是新鲜的。如果HTTP实体有一个实体标签，代理应该包含一个ETag响应中的选项和处理请求中的ETag选项下面描述。

客户端可以通过以下方式影响GET请求的处理:

接受: 请求可能包括一个接受选项，该选项标识首选的响应内容格式。

ETag: 请求可能包括一个或多个ETag选项，标识客户端存储的响应。这请求代理发送一个2.03(有效)响应时，它将发送一个2.05(内容)响应，在请求的集合中包含实体标记.否则。注意，CoAP etag总是强etagHTTP的感觉;CoAP没有HTTP弱etag的等价物，在交叉代理中没有很好的方法来利用这些。

5.2 PUT

PUT方法请求代理更新或创建HTTP由请求,是通过URI标识的资源来表示。

如果在请求URI处创建了新资源，则2.01(已创建)响应必须返回给客户端。如果现有资源是
修改后，必须返回2.04(已更改)响应来指示请求成功完成。

5.3 DELETE

DELETE方法请求代理删除HTTP资源由HTTP源服务器上的请求URI标识。

2.02(已删除)响应必须返回给客户端如果在请求时资源不存在。

5.4 POST

POST方法请求代理具有该表示请求中包含的内容将由HTTP源服务器处理。POST方法执行的实际功能由源服务器，并依赖于请求所标识的资源URI。

如果POST方法执行的操作没有导致可以通过URI标识的资源，即2.04(已更改)响应必须返回给客户端。如果资源已创建在对于源服务器，必须返回2.01(已创建)响应。

6 HTTP-CoAP Proxying

如果HTTP请求包含带有'coap'或'coaps'的请求uriURI，然后是接收HTTP端点(以后称为“代理”)被请求执行由请求方法指定的操作在指定的CoAP资源上执行，并将结果返回给客户端。此部分为任何HTTP请求指定HTTP响应代理应该返回到客户端。除非另有规定所做的所有陈述都是推荐行为;一些高度受约束的实现可能需要求助于捷径。如何代理实际满足请求是一个实现细节，虽然典型的情况预计是代理翻译和将请求转发到CoAP源服务器。的含义在CoAP资源上执行单个HTTP方法时在本节的子节中解释。如果代理不能或不愿意使用CoAP为请求提供服务URI，则将501(未实现)响应返回给客户端。如果代理通过与第三方交互来为请求提供服务(如CoAP源服务器)，并且无法获得结果在合理的时间范围内，504(网关超时)响应是返回;如果可以得到一个结果，但不能理解，则502返回(坏网关)响应。

6.1 GET

GET方法: 请求代理返回控件的表示形式由请求uri标识的CoAP资源。成功后，返回一个200 (OK)响应。有效载荷响应必须是目标CoAP资源的表示形式，并且设置报头字段Content-Type和Content-Encoding相应的行动。响应必须指示一个最大年龄指令指定的值不大于系统的剩余时间代表可以被认为是新鲜的。如果CoAP响应具有选项时，代理应该被响应。

客户端可以通过以下方式影响GET请求的处理以下选项:

Accept:

HTTP Accept报头的首选媒体类型字段映射到CoAP Accept选项。HTTP接受不支持媒体类型范围、参数和扩展名CoAP接受选项。如果代理不能发送响应是可接受的，那么代理发送406(不可接受)响应。代理人可以然后用来自HTTP的其他媒体类型重试请求接受报头字段。

Conditional GETs:

Conditional HTTP GET 请求包含“If-”“Match”或“If-None-Match”请求头字段可以映射到相应的CoAP请求。“If- modified - since”和“If-。未修改-因为“请求头”字段不直接支持通过CoAP，但由缓存代理在本地实现。

6.2 HEAD

HEAD方法与GET方法相同，只是服务器必须不这样做在响应中返回消息体。尽管CoAP中没有直接对应HTTP的HEAD方法，HTTP-CoAP代理响应对CoAP资源的HEAD请求返回的HTTP报头没有消息体。

6.3 POST

POST方法请求代理具有该表示请求中包含的内容将由CoAP源服务器处理。POST方法执行的实际功能由源服务器，并依赖于请求所标识的资源URI。如果POST方法执行的操作没有导致资源，可以通过URI, 200 (OK)或204 (No内容响应必须返回给客户端。如果一个资源如果在源服务器上已创建，则必须是201(已创建)响应返回。

如果CoAP响应中存在任何Location-*选项，则由这些选项的值构造的位置报头字段为返回。