Labs 导读
作为物联网世界的主流协议之一,CoAP协议为低功耗受限设备的数据交互和网络接入提供了可能,IETF在RFC7252中对其进行了详细的定义,本文结合CoAP协议在和家亲中的应用场景对其双层模型及输特性进行介绍。
作者:毛小俊
单位:中国移动智慧家庭运营中心
和家亲是中国移动面向智慧家庭用户推出的智能连接类App,是物联网在家庭应用场景中的落地实践。物联网强调的是物与物之间的连接通信,在和家亲中实现这种物物连接的就是Andlink协议,它是对多种主流物联网协议的综合运用,其中包含CoAP、MQTT、LwM2M、HTTP等协议,他们的简单对比如下表所示。由于多个协议都涉及到CoAP,因此本文重点介绍CoAP协议双层模型及其传输特性。
Part 01 ●和家亲哪些场景用到了CoAP?●
在和家亲中,CoAP主要应用在下述2个场景中:
LPWAN网络(包括NB-IoT、LoRa、SigFox等)下,智能设备与家开平台通过LwM2M协议进行交互,LwM2M协议的底层便是基于UDP/UDP+DTLS传输层协议之上的CoAP协议。
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模型对保障传输可靠性,提高客户端和服务端的交互效率十分重要。
审核编辑:刘清
-
物联网
+关注
关注
2900文章
44052浏览量
370096 -
ACK
+关注
关注
0文章
28浏览量
11128 -
RST
+关注
关注
0文章
31浏览量
7375 -
CoAP
+关注
关注
0文章
10浏览量
10570 -
TCP通信
+关注
关注
0文章
146浏览量
4200
原文标题:技术 | COAP协议的双层模型及其传输特性
文章出处:【微信号:5G通信,微信公众号:5G通信】欢迎添加关注!文章转载请注明出处。
发布评论请先 登录
相关推荐
评论