Labs 导读

作为物联网世界的主流协议之一，CoAP协议为低功耗受限设备的数据交互和网络接入提供了可能，IETF在RFC7252中对其进行了详细的定义，本文结合CoAP协议在和家亲中的应用场景对其双层模型及输特性进行介绍。

和家亲是中国移动面向智慧家庭用户推出的智能连接类App，是物联网在家庭应用场景中的落地实践。物联网强调的是物与物之间的连接通信，在和家亲中实现这种物物连接的就是Andlink协议，它是对多种主流物联网协议的综合运用，其中包含CoAP、MQTT、LwM2M、HTTP等协议，他们的简单对比如下表所示。由于多个协议都涉及到CoAP，因此本文重点介绍CoAP协议双层模型及其传输特性。

Part 01.  和家亲哪些场景用到了CoAP？  

在和家亲中，CoAP主要应用在下述2个场景中：

1??LPWAN网络(包括NB-IoT、LoRa、SigFox等)下，智能设备与家开平台通过LwM2M协议进行交互，LwM2M协议的底层便是基于UDP/UDP+DTLS传输层协议之上的CoAP协议。

2??Wi-Fi网络下，配网是实现智能设备后续注册、上线、管控的前提条件，配网过程中涉及到智能组网终端查找、发送入网请求、通知设备入网信息、设备入网成功广播、智能组网终端密码变更同步等步骤，这些步骤的交互即是通过CoAP协议完成。

Part 02.  什么是CoAP协议？ 

CoAP协议(Constrained Application Protocol，标准文档RFC7252)，属于应用层协议，在M2M通信中的作用和互联网中的HTTP类似，但在定义上只是实现了REST的一个子集，更重要区别是HTTP运行于TCP之上，而CoAP运行于UDP协议之上，由于UDP建立的是非可靠连接，在网络数据传输过程中，无论是请求还是响应，均存在丢包的风险。那CoAP协议的传输如何保障可靠性呢？这就涉及到CoAP协议的双层模型：

CoAP协议逻辑上分为Messaging Model和Request/Response Model，其中：

• Messaging Model：处理端到端之间的数据交换，并为各报文类型提供重传机制，来弥补传输过程中的不可靠性。通过CoAP消息头部的Message ID建立请求与应答消息之间的关联，实现可靠传输。
• Request/Response Model：定义了Client侧通过URI向服务端的资源发出操作请求和服务端响应的规则。通过CoAP消息头部的Token建立Request和Response关联，实现可靠响应。

注意区分Request/Response Model中的Token和Messaging Model中的Message ID是两个不同字段，如下图^[1]所示：

下面分别从Request/Response Model和Messaging Model分析CoAP协议的传输特性。

Part 03.  Messaging Model的可靠消息传输  

上述介绍的中间CoAP定义了四种不同类型的报文：CON、NON、ACK、RST。其中CON报文需要接收方确认，即每一个CON报文都对应一个头部带有相同Message ID的ACK报文或RST报文，如果在规定的时间内请求方未收到ACK报文或RST报文，那么客户端将启动 “重传机制”。发送方未收到ACK/RST报文可能有两种原因：

• CoAP请求丢失：CoAP请求已经发出，但未到达服务端
• CoAP响应丢失：服务器已收到请求并返回响应信息，但响应未正确到达客户端

与重传机制相关的参数包括：ACK_TIMEOUT、ACK_RANDOM_FACTOR、MAX_RETRANSMIT、MAX_TRANSMIT_SPAN、MAX_TRANSMIT_WAIT

• ACK_TIMEOUT：超时响应等待时间，默认2s。一个CON报文的初始等待时间为一个随机数，取值范围是ACK_TIMEOUT到ACK_TIMEOUT*ACK_RANDOM_FACTOR之间。随着重传次数增加，每一次的等待时间均为前一次的2倍。
• ACK_RANDOM_FACTOR：随机系数，默认1.5。
• MAX_RETRANSMIT：最大重传次数，固定值4次。
• MAX_TRANSMIT_SPAN：第一次发出CON报文到最后一次重新发送的最长时间间隔。
• MAX_TRANSMIT_WAIT：第一次发出CON报文到发送方放弃接收ACK或RST报文的最长时间间隔。

为进一步说明Messaging Model重传机制，以和家亲中设备端向智能组网终端发送入网CON请求为例，假如在本次CON报文发送中

ACK_TIMEOUT=2s

ACK_RANDOM_FACTOR=1.5

首次超时响应等待时间取t1=2.5s (2s<=t1<=2*1.5s)

由于网络较差尝试了4次重新发送都未收到ACK或RST响应报文，可以得到如下图所示的交互结果：

需要注意的是上图只是为了说明重传机制的完整流程，只要CON消息发送后任意时刻，设备端收到来自服务端的ACK/RST消息，本次消息传送便会终止。通过这种重传机制，CoAP协议保证了端到端消息传输的可靠性。

Part 04.  Request/Response Model的消息传输 

Request/Response模型的交互方式类似于HTTP协议中的客户端和服务端交互的C/S模型。

Request关注的是根据URI向服务端的资源发出操作请求，请求类型包括GET、POST、PUT 和 DELETE，但和HTTP不同的是不会先建立连接，而是通过CoAP消息进行异步交互，Request和Response之间通过CoAP消息头部的Token字段进行匹配。

Response则根据Request类型和服务端当前状态的差异，分为Piggybacked Response、Separate Response、Non-confirmable Response3种不同类型：

? Piggybacked Response（附带响应）

下图[1]中展示了对于两个GET请求，服务端返回附带响应的例子，一个成功，一个导致了4.04（资源未找到）。通过ACK报文回应CON报文，是最通用的类型，属于可靠响应模式。

图片

? Separate Response（独立响应）

假如Server由于系统繁忙等原因无法直接给出数据响应，那么它就会立即发回一个空的ACK消息，服务端在数据准备好后服务器端就会把它组装成一个新的CON类型消息（这需要客户端的ACK），进行异步响应。独立响应也属于可靠响应模式。下图[1]中可以看到两次交互中使用的Token一致，都是0x73；但是Message ID已经变掉了，从0x7a10变成了0x23bb。

? Non-confirmable Response（无需响应）

Client的请求如果是NON类型，Server一般也回NON类型消息，但服务器也有可能发送一个CON类型的消息作为响应。适用于对响应可靠性要求不高的场景。例如对温度传感器数据的重复读取，并不需要每一次都成功。图中[1]request和response使用了相同的Token：0x74。

Part 05.  总结  

CoAP协议目前在和家亲的智能设备大网和局域网连接、管控中都起到了重要的连接作用。作为物联网的主流协议之一，CoAP协议除了本身单独使用之外，还是LwM2M协议的底层消息传递协议，和MQTT相比，CoAP更加轻量、开销更低，在诸如和家亲设备配网等场景中更加合适。在使用CoAP时结合场景选择合适的Message和Request/Response模型对保障传输可靠性，提高客户端和服务端的交互效率十分重要。