• 通讯协议介绍&CoAP 协议解析


    目录

    1 通讯协议

    2 TCP/IP 网络模型

    2.1 TCP协议

    2.1.1 TCP 连接过程

    2.1.2 TCP 断开连接

    2.1.3 TCP协议特点

    2.2 UDP协议

    2.2.1 UDP 协议特点

    3 应用层协议简介

    3.1 HTTP 协议

    3.2 CoAP 协议

    3.3 MQTT 协议

    4 CoAP 协议详解

    4.1 REST 风格

    4.2 CoAP 首部分析

    4.3 CoAP 媒体类型

    4.4 CoAP 重传机制

    4.5 CoAP 报文解析


    1 通讯协议

    通讯协议又称通讯规程,是通信双方对数据传送控制的一种约定,双方必须共同准守。约定的内容包括:数据格式、同步方式、传送速度、传送速度、传送步骤、检纠错方式、控制字符定义等。双方实体需要准守通信协议中既定的规则,才能将有意义的信息传递给对方。

    市面上有很多物联网应用层协议,COAP、HTTP、MQTT 是最常见的三种。HTTP 和 MQTT 均使用 TCP 作为传输层协议,而 COAP 则是基于 UDP 传输协议。同时,传输层的 UDP 和 TCP 协议又都是依赖网络层的 IP 技术。

    2 TCP/IP 网络模型

    TCP/IP 是互联网相关的各类协议族的总称,比如 TCP、UDP、IP、FTP、HTTP、SMTP 等都属于 TCP/IP 族内的协议。

    TCP/IP 模型是互联网的基础,它是一系列网络协议的总称。这些协议可以划分为四层,分别为链路层、网络层、传输层和应用层。

    链路层:负责封装和解封装 IP 报文,发送和接收 ARP 和 RARP 报文等。

    网络层:负责路由以及把分组报文发送给目标网络或主机。

    传输层:负责对报文进行分组和重组,并以 TCP 或 UDP 协议格式封装报文。

    应用层:负责向用户提供应用程序,比如 HTTP、COAP、Telnet、MQTT、DNS 等。

    在网络体系结构中,网络通讯的建立必须是在通讯双方在对等层进行,不能交错。在整个数据传输过程中,数据在发送端时经过各层都要附加上相应层的协议头和协议尾(仅数据链路层需要封装协议尾)部分,也就是要对数据进行协议封装,以标识对应层所用的通讯协议。

    2.1 TCP协议

    当一台计算机想要与另一台计算机通讯时,两台计算机之间的通行需要畅通且可靠,这样才能保证正确收发数据。例如,当你想查看网页或查看电子邮件时,希望完整且按顺序查看网页,而不丢失任何内容。当你下载文件时,希望获得的是完整的文件,而不仅仅是文件的一部分,于是就用到了 TCP 。

    TCP(Transmission Control Protocol,传输控制协议),是是一种面向连接的、可靠的、基于字节流得到传输层通信协议,由 IETF 的 RFC 793 定义。TCP 是面向连接的、可靠的流协议,流是指不间断的数据结构,你可以把它想象成排水管中的水流。

    2.1.1 TCP 连接过程

    如下图所示,可以看到建立一个 TCP 连接的过程(三次握手的过程):

    第一次握手:客户端发送 SYN(SEQ=x)报文给服务器,进入 SYN_SEND 状态

    第二次握手:服务端接收到 SYN 报文,回应一个 SYN(SEQ=y)+ ACK(ACK=x+1)报文,并进入 SYN_RECV 状态。

    第三次握手:客户端收到服务端的 SYN 报文,回应一个 ACK(ACK=y+1)报文,进入连接(Established)状态。

    为了防止出现失效的连接请求报文被服务端接收的情况,从而产生错误,这个就是为什么 TCP 建立连接需要三次握手,而不是两次的原因。

    通过 wireshark 抓包工具我们也能复现这个过程:

    2.1.2 TCP 断开连接

    建立一个连接需要三次握手,而终止一个连接需要进经过四次握手,这是由于 TCP 的半关闭造成的,具体过程如下图所示:

    第一次握手:某个应用进程首先调用 close,称该端执行 “主动关闭(active close)”,该端的 TCP 于是发送一个 FIN 字节,表示数据发送完毕。

    第二次握手:接收到这个 FIN 的队端执行 “被动关闭(passive close)”,这个 FIN 由 TCP 确认。

    注意:FIN 的接收也作为一个文件结束符(end-of-file)传递给接收端应用进程,放在已排队等候该应用进程接收的任何其他数据之后,因为,FIN 的接收意味着接收端应用进程在相应连接上再无额外数据可接收。

    第三次握手:一段时间后,接收到这个文件结束符的应用进程将调用 close 关闭它的套接字。这导致它的 TCP 也发送一个 FIN。

    第四次握手:接收这个最终 FIN 的原发送端 TCP(即执行主动关闭的那一端)确认这个 FIN。

    既然每个方向都需要一个 FIN 和一个 ACK,因此通常需要4个分节。

    如下,通过 wireshark 抓包工具我们也能复现断开连接的过程:

    2.1.3 TCP协议特点

    面向连接

    面向连接,是指发送数据之前必须在两端建立连接。建立连接的方法是 ”三次握手“,这样能建立可靠的连接。

    仅支持单传播

    每条 TCP 传输连接只能有两个端点,只能进行点对点的数据传输,不支持多端和广播传输方式。

    面向字节流

    TCP 不像 UDP 那样一个个报文独立的传输,而是在不保留报文边界的情况下已字节流方式进行传输。

    可靠传输

    对于可靠传输,判断丢包、误码靠的是 TCP 的段编号以及确认号。

    提供拥塞控制

    当网络出现拥塞的时候,TCP 能够减小向网络注入数据的速率和数量,缓解拥塞。

    TCP 提供全双工通信

    TCP 允许通信双方的应用程序在任何时候都能发送数据,因为 TCP 连接的两端都没有缓存,用来临时存放存放双向通信的数据。当然,TCP可以立即发送一个数据段,也可以缓存一段时间以便一次发送更多的数据段。

    TCP 协议报文格式:

    源端口号(2字节):源设备上发送数据包进程的16位端口号。

    目标端口号(2字节):目标设备上接收进程的16位端口号。

    序号(4字节):由滑动窗口确认系统使用,作为数据分包的第一个字节的序号。在 SYN 位置为1的情况下,它表示初始序号。

    确认号(4字节):如果 ACK 位置为1,该字段有效并包含设备用于对接收到的数据包进行确认的序号。

    数据偏移(4位):表示数据包的开始位置与 TCP 首部的开始处偏移多少个 32位(4字节)的偏移量。该字段的值乘以4才得到字节形式表示的偏移量、

    控制位(6位):用于相关控制信息。这些控制信息包括 URG 紧急位、ACK 确认位、PUSH 推送位、RST 复位位、SYN 同步位和 FIN 结束位。

    窗口(2字节):用于流控制,表示该数据包的发送者在一定时间内能从其他设备接收的字节数。

    校验和(2字节):用于检测错误的 16 位校验和。

    紧急指针(2字节):如果 URG 位置为1,该字段包含紧急数据后面的 “正常” 数据的第一字节的序列号。

    2.2 UDP协议

    UDP(User Datagram Protocol,用户数据报协议),在网络中它与 TCP 协议一样用于处理数据包,是一种无连接的协议。在 OSI 模型中,在第四层传输层,处于 IP 协议的上一层。UDP 有不提供数据包分组、组装和不能对数据包进行排序的特点,也就是说,当报文发送之后,是无法得知其是否安全完整到达的。

    2.2.1 UDP 协议特点

    面向无连接

    首先 UDP 是不需要和 TCP 一样在发送数据前进行三次握手建立连接的,想发数据就可以开始发送了,并且也只是数据报文的搬运工,不会对数据报文进行任何拆分和拼接操作。

    具体来说就是:

    在发送端,应用层将数据传递给传输层的 UDP 协议,UDP 只会给数据增加一个 UDP 头,标识下是 UDP 协议,然后就传递给网络层了。

    在接收端,网络层将数据传递给传输层,UDP 只去除 IP 报文头后就传递给应用层,不会进行任何拼接操作。

    有单播,多播和广播的功能

    UDP 不只支持一对一的传输方式,同样支持一对多,多对多,多对一的方式,也就是说 UDP 提供了单播、多播、广播的功能。

    UDP 是面向报文的

    发送方的 UDP 对应用程序交下来的报文,在添加首部后就向下交付 IP 层。UDP 对应用层交下来的报文,既不合并,也不拆分,而是保留这些报文的边界。因此应用程序必须选择合适大小的报文。

    不可靠性

    首先不可靠性体现在无连接上,通信都不需要建立连接,想发送就发送,这样的情况肯定不可靠。并且收到什么数据就传递什么数据,并且也不会备份数据,发送数据也不会关心对方是否已经正确接收到数据了。

    再者网络环境时好时坏,但是 UDP 因为没有拥塞控制,一直会以恒定的速度发送数据。即使网络条件不好,也不会对发送速率进行调整,这样实现的弊端就是在网络条件不好的情况下可能会导致丢包,但是优点也很明显,在某些实时性要求高的场景(比如电话会议、直播等)就需要使用 UDP 而不是 TCP。

    头部开销小,传输数据报文时是很高效的

    UDP 头部包含了以下几个数据:

    两个十六位的端口号,分别为源端口(可选字段)和目标端口。

    整个数据报文的长度。

    整个数据报文的校验和(IPv4 可选字段),该字段用于发现头部信息和数据中的错误。

    因此 UDP 的头部开销小,只有八字节,相比 TCP 的至少二十字节要少的多,在传输数据报文时是很高效的。

    3 应用层协议简介

    3.1 HTTP 协议

    HTTP 协议,即超文本传输协议(Hypertext Transfer Protocol),是一种详细规定了浏览器和万维网服务器之间互相通信的规则,通过因特网传送万维网文档得到数据传送协议。

    目前 HTTP 协议作为 WEB 的标准协议已被广泛使用,它在一些物联网场景中同样可以使用,例如手机、PC等终端设备。但是作为适应浏览器场景的 HTTP 协议,并不适用于物联网的其他设备。

    适用范围:开放物联网中的资源,实现服务被其他应用所调用。

    优势:

    简单的工作模式,请求 / 响应。

    完整的方法定义。

    合理的状态码设计。

    友好的媒体类型支持,如文本、图片、视频等。

    缺点:

    单向传输,可以通过客户端轮询实现类似推送效果或者HTTP2.0

    安全性不高,HTTP是明文协议,可以使用 HTTPS 传输。

    HTTP 是文本协议,冗长的协议头部,对于运算、存储、带宽资源受限的设备来说开销大。

    3.2 CoAP 协议

    CoAP(Constrained Application Protocol)即受限的应用协议。CoAP 是为了让低功耗受限设备可以接入互联网,由 IETF 组织制定的,它借鉴了 HTTP 大量成功经验,同样使用请求 / 响应工作模式。

    使用范围:适用于互联网环境下一对一 M2M 通讯。

    优势:

    采用和 HTTP 相似语义的请求和响应码,使用二进制报文,报文大小较小。

    传输层基于 UDP 协议,比 TCP 数据包小,并不需要建立连接带来握手的开销。

    资源发送支持,通过观察者模式实现类似发布 / 订阅效果。

    缺点:

    基于 UDP 的不可靠传输,但通过四种报文类型的组合及重传机制提高了传输的可靠性。

    基于 UDP 的无连接传输,不利于不同网络间消息的回传。

    3.3 MQTT 协议

    MQTT(Message Queuing Telemetry Transport)即消息队列遥测传输。

    MQTT 协议最初是在 1999 年由 IBM 公司开发的,用于将石油管道上的传感器与卫星相连接。2014 年正式成为 OASIS 开放标准。

    MQTT 使用类似 MQ 常用的发布 / 订阅模式,起到应用程序解耦、异步消息、削峰填谷的作用。很多 MQ 中间件也支持 MQTT 协议,比如 ActiveMQ、RabbitMQ、Kafka 等。

    适用范围:在低带宽、不可靠的网络下提供基于云平台的远程设备的数据传输和监控。

    优势:

    使用发布 / 订阅模式,提供一对多的消息发布,使消息发送者和接受者在时间和时空上解耦。

    二进制协议,网络传输开销非常小(固定头部是2字节)。

    灵活的 Topic 订阅、QoS 等特性。

    缺点:

    集中化部署,服务端压力大,需要考虑流程控制及高可用。

    对于请求 / 响应模式的支持需要在应用层根据消息 ID 做发布主题和订阅主题之间的关联。

    4 CoAP 协议详解

    4.1 REST 风格

    REST(具象状态传输)是 Roy Thomas Fielding 博士于2000年在他的博士论文 “Architectural Styles and the Design of Network-based SoftwareArchitectures” 中提出来的一种 Web 软件架构风格。目前在三种主流的 Web 服务实现方案中,REST 模式与复杂的 SOAP 和 XML-RPC 相比更加简洁,越来越多的 Web服务 开始采用 REST 风格设计和实现。REST 是设计风格而不是标准,REST 通常基于使用 HTTP、URI、XML、JSON 和HTML 这些现有的协议和标准来实现。

    REST 风格具有以下特点:

    资源一般由 URI 来指定。

    无状态通信。

    对资源的操作包括获取、创建、修改和删除等,这些操作对应 HTTP 的 GET、POST、PUT 和 DELETE 方法。

    资源的表现形式可以是 XML、JSON 或 HTML 格式文件。

    CoAP 基于 REST 架构风格,基于简洁、清晰,且易于实现的特点。CoAP 和 HTTP 一样,使用请求 / 响应工作模式:客户端发送 CoAP请求,服务器一旦侦听到请求便会根据其包含的 URI 对资源进行定位,并按请求方法决定如何操作该资源:读取(GET)、创建(POST)、修改(PUT)或者删除(DELETE)。服务器处理完请求之后,将返回客户端一个 CoAP响应,其中包含响应码,也有可能有响应内容。

    虽然 CoAP 和 HTTP 多有相似,但其较 HTTP 简单的多。CoAP 建立在 UDP 栈上,这是与 HTTP 相比最主要的区别,它可以更快更好的进行资源优化。CoAP 可以使用与 10kb RAM 系统上,占用内存较少,同时,CoAP 能够发现网络中的节点,这对于低功耗无线传感器网络的自治金额自我修复设计非常有用。

    4.2 CoAP 首部分析

    CoAP 是一个完整的二进制应用层协议,和 TCP/IP 协议族中的其他协议一样,CoAP协议带有报文头,负载(Payload)和报文头之间使用单字节分隔符 0xFF 隔离。报文头里的版本编号 Ver、报文类型 T、标签长度指示 TKL、准则 Code、报文序号 MessageID 为必填内容。

    CoAP 协议报文结构如下:

    【 Ver 】版本编号,占2位,取固定值 0b01(0b开头表示后面的数据为二进制数);

    【 T 】报文类型,占2位,CoAP 协议定义了4种不同形式的报文:CON、NON、ACK、RST :

    【 TKL 】标签长度指示,占4位,用于指示 Token 区域的具体长度。当 CoAP 报文包含 Token 时,TKL 取值 0b0001(1个字节长度)、0b0010(2个字节长度)、0b0100(4个字节长度),当 CoAP 报文省略 Token 时,TKL 取值 0b0000。

    【 Code 】准则,占8位(一个字节)。Code 的值分为高三位 Class 部分和低五位 Detail 部分,采用 c.dd 的形式描述:c 和 dd 均采用十进制,c 的取值范围是 031。Code 在请求和响应中的具体表现显示有所不同:当 c=0 时,表示 CoAP 请求,否则表示 CoAP 响应。Code=0.00 表示空报文,是一种特殊形式的 CoAP 响应,Code 值与表达含义如下:

    【 Message ID 】报文序号,占2个字节,并采用大端格式描述,用于客户端和服务器建立请求和响应报文之间的一一对应关系,即起报文确认作用。一组对应的 CoAP 请求和 CoAP 响应使用相同的 Message ID,在同一次会话中 ID 保持不变,此次会话结束后该 ID 将会被回收利用。Message ID 可以弥补 UDP 传输方式带来的不可靠性。

    【 Token 】标签,长度由 TKL 定义,可以是1字节、2字节或4字节。通常用于应用确认。

    【 Options 】选项,CoAP 请求或响应中可携带一组或多组 Options,功能类似于 HTTP 中的通信首部字段、请求首部字段、响应首部字段和实体首部字段。Options 是 CoAP 核心协议中较为复杂的部分,但 Option 也给 CoAP 的应用带来了诸多灵活性。CoAP 选项包括 Uri-Host、Uri-Port、Uri-Path、Uri-Query、Content-Format、Accept、Etag、If-Match和If-None-Match 等部分。

    Option Delta 占4位,转换为10进制数值范围在0~12之间 。

    如果 Option Delta == 13,那么 Option Delta (extended) 部分为 1 字节,Option Delta = 13 + Option Delta(extended)

    如果 Option Delta == 14,那么 Option Delta (extended) 部分为 2 字节,Option Delta = 14 + 255 + Option Delta(extended)

    Option Delta == 15 无效

    Option Length 占4位, 转换为10进制数值范围在0~12之间 。

    如果 Option Length == 13,那么 Option Length (extended) 部分为 1 字节,Option Length = 13 + Option Length(extended)

    如果 Option Length == 14,那么 Option Length (extended) 部分为 2 字节,Option Length = 14 + 255 + Option Length(extended)

    Option Delta == 15 无效

    Option Value 由 Option Length 的值决定 Option Value 的长度。

    Option Delta 对应值的含义如下:

    3 Uri-Host:CoAP 主机名称,例如 iot.eclipse.org

    7  Uri-Port:CoAP 端口号,默认为5683

    11 Uri-Path:资源路由或路径,例如 \temperature。资源路径采用 UTF8 字符串形式,不计 \ 的长度。

    15 Uri-Query:访问资源参数,例如 ?value1=1&value2=2,参数与参数之间使用 “&” 分隔,Uri-Query 和 Uri-Path之间采用“?”分隔。

    在这些option中,Content-Format 和 Accept 用于表示CoAP负载的媒体格式。

    12 Content-Format:指定 CoAP 复杂媒体类型,媒体类型采用整数描述,例如 application/json 对应整数50,application/octet-stream 对应整数40。

    17 Accept:指定 CoAP 响应复杂中的媒体类型,媒体类型的定义和 Content-Format 相同。

    【 0xFF 】分隔符,占1个字节,用于区分 CoAP 首部和具体负载。

    【 Payload 】负载,正在有用的被交互的数据。CoAP 负载可能包含不同的媒体类型:二进制、文本、XML、JSON、CBOR 等,但并不支持 HTML 类型的负载。

    4.3 CoAP 媒体类型

    CoAP 负载支持多种媒体类型,并采用编号的方式对其进行定义。编号一般为2字节的无符号整数。

    文本类型(text/plain)、二进制类型(application/octet-stream)、JSON类型(application/json)是在物联网中应用最广泛的三种媒体类型,application/link-format 则是专属于 CoAP 的媒体类型,一般在 CoAP 资源发现中使用。

    (一)文本类型

    CoAP 中默认的媒体类型为文本类型,若负载为文本类型,那么 CoAP 请求和响应都不需要指定 Content-Format。虽然文本类型使用方便,但需要提前对负载结果的每个部分按顺序进行定义。

    如传感器的数据:21.3,62,2022-01-01 17:31:10,传输双方需要事先约定第一个值表示 ”温度“,第二个值表示 ”湿度“,第三个值表示 ”时间“,数据才能被正确解析。

    (二)二进制类型

    TLV 形式的二进制负载也经常出现在某些物联网应用中出现。TLV 是 Tag,Length 和 Value 的缩写,一个基本的数据元就包含上面三个域。Tag 是该数据元的唯一标识,Length 是 Value 域的长度,Value 就是数据本身。Type 和 Length 的长度固定,一般为 2 或 4 个字节,Value 的长度由 Length 指定,如字符串 9F0607A0000000031010,其中 9F06 是 Tag,07 是长度,A0000000031010 就是数据本身。

    (三)JSON类型

    JSON(JavaScript Object Notation,JS对象表示法)是一种轻量级的数据交换格式,易于使用者阅读和编写,也易于机器解析和生成。JSON 分为 JSON对象和 JSON 数组两种构造结构:

    JSON 对象

    JSON 对象是一个无序的键值对集合,以 { 开始并以 } 结束,每个键后面跟一个分号 :,每组键值对之间使用逗号 , 分隔。

    JSON 数组

    JSON 数组是值有有序集合,以 [ 开始并以 ] 结束,值之间使用逗号 , 分隔。

    4.4 CoAP 重传机制

    由于 CoAP 采用 UDP 作为其传输层协议,故在网络数据传输过程中,无论是请求还是响应,均存在丢包的风险。为此,CoAP 设计了双层结构 -- 消息层和请求/响应层,消息层处理端点之间的数据交换,并为各报文类型提供重传机制,来弥补传输过程中的不可靠性。

    前面提到过,CoAP 定义了四种不同类型的报文:CON、NON、ACK、RST。CON 报文需要被接受者确认,即每一个 CON 报文都对应一个准确热 ACK 报文或 RST 报文,如果在规定的时间内客户端未接受到 ACK 报文或 RST 报文,那么客户端将启动 “重传机制”,如:

    在某个时刻,CoAP 客户端发起 CON 类型的 GET 请求,试图从服务端获得温度传感器数据 temperature。如请求没有准确到达 CoAP 服务器(称作 “CoAP 请求丢失”),或服务器虽收到请求并返回响应,但响应未正确到达客户端(称作 “CoAP 响应丢失”),超过一定时间后,客户端就会将前一次 CoAP 请求判定为失败,并再次发送同样的 GET 请求,两次请求的首部和负载完全相同。

    CoAP 报文重传机制受制于 ACK_TIMEOUT、ACK_RAMDOM_FACTOR、MAX_RETRANSMIT 三个参数。ACK_TIMEOUT 是响应等待超时时间,典型值为 2s,ACK_RAMDOM_FACTOR 是一个不小于1的随机系数,典型值取1.5,MAX_RETRANSMIT 表示最大重传次数,典型值为4:

    对于一个 CON 报文而言,初始超时时间是 ACK_TIMEOUT 到 ACK_RAMDOM_FACTOR * MAX_RETRANSMIT 之间的随机数。重传计数器从0开始计数,一旦在初始超时时间内客户端未收到服务器回传的 ACK 报文或 RST 报文,那么 CON 报文将会被重新发送,重传计数器自动增加至1,并且下一次重传超时间自动递增为上一次超时时间的两倍。

    假设响应等待超时时间 ACK_TIMEOUT 取2s,随机系数 ACK_RAMDOM_FACTOR 取1.5,最大重传次数 MAX_RETRANSMIT 为4,则初始超时时间是2~3s之间的随机数(本例中我们取2.5s)。最极端的情况下,CoAP 客户端会发送一次正常的 CON 报文,并在重传4次后停止对该报文的传输。

    在该过程中,相邻 CON 报文的时间间隔分别为 2.5s、2 * 2.5s、4 * 2.5s、8 * 2.5s,总计时间即最大传输时间 MAX_TRANSMIT_SPAN = 2.5 * (1 + 2 + 8) = 37.5s。

    最后一次 CON 报文的重传并不意味整个传输过程已经结束,CoAP 客户端还要等待最后一次超时时间:16 * 2.5s,然后将停止本条报文的传输。从 CoAP 客户端发送第一次 CON 报文到最后停止传输,总共消耗的时间称为最大等待时间 MAX_TRANSMIT_WAIT = 2.5 *(1+2+4+8+16)= 77.5s。

    4.5 CoAP 报文解析

    以 电信 OC 平台上设备登录报文为例:

    4402AD3D3DAD0700B272641128396C776D326D3D312E300D0565703D38363131303730353937333934353903623D55066C743D333030FF3C2F3E3B72743D226F6D612E6C776D326D222C3C2F312F303E2C3C2F322F303E2C3C2F332F303E2C3C2F342F303E2C3C2F352F303E2C3C2F362F303E2C3C2F372F303E2C3C2F31392F303E2C3C2F31392F313E

    上述报文为十六进制数据,根据 [CoAP 首部分析](### CoAP 首部分析) 可以将报文分成7个部分:

    ① 44 1字节,转换为二进制可得 0b01000100,对应Ver、T、TKL 的值为:

    ② 02 1字节,Code 准则,转换为二进制可得 0b00000010,对应 Code 值为:

    ③ AD3D 2字节,Message ID 报文序号,对应的值为:

    ④ 3DAD0700 4字节,表示Token值, TLK 可知此报文 Token 长度为4字节,故此处截取4字节长度 Token 值。

    ⑤ B272641128396C776D326D3D312E300D0565703D38363131303730353937333934353903623D55066C743D333030 Options选项,

    由 Option Delta 和 Option Length 占一个字节,故取 B2 先进行解析,转换为二进制数为 0b10110010,Option Delta 和 Option Length 解析为:

    Option Value 取2个字节长度为:7264,转ASSIC为 rd,此 Option 表示为 uri-path=/rd。

    继续往下,截取 11,转换为二进制数为 0b00010001,Option Delta 和 Option Length 解析为 1、1,累加上第一个偏移量为 11 + 1 = 12,对应的 Option 选项名称为 Content-Format ,Option Value 长度为1,故值截取为 28,转换为十进制数为 40 ,对应 CoAP 媒体类型为 application/link-format。

    截取 39,转为为二进制数为 0b00111001,Option Delta 和 Option Length 解析为 3、9,累加前面的偏移量为 12 + 3 = 15,对应的 Option 选项名称为 Uri-Query,Option Value 长度为9,故值截取为 6C776D326D3D312E30,进行 ASCII 转换可以得到值为 lwm2m=1.0

    截取 0D,转为二进制数为 0b00001101,Option Delta 和 Option Length 解析为 0、13,由于 Option Length 为 13,故下面还含有 Option Delta(extended) 和 Option Length(extended),截取 05 可得二进制数 0b00000101,Option Delta(extended) 和 Option Length(extended) 解析为 0、5,故 Option Length 值为 13 + 5 = 18,即 Option Value 的长度为18,截取 65703D383631313037303539373339343539,可得值为 ep=861107059739459

    截取 03,转为二进制数得 0b00000011,Option Delta 和 Option Length 解析为 0、3,累加前面的偏移量为 15 + 0 = 15,对应的 Option 选项名称为 Uri-Query,Option Value 长度为3,故值截取为 623D55,进行 ASCII 转换可以得到值为 b=U

    截取 06,转为二进制数得 0b00000110,Option Delta 和 Option Length 解析为 0、6,累加前面的偏移量为 15 + 0 = 15,对应的 Option 选项名称为 Uri-Query,Option Value 长度为6,故值截取为 6C743D333030,进行 ASCII 转换可以得到值为 lt=300

    Uri-Query 参数与参数之间使用 & 符号隔开,故此参数完整形式为 lwm2m=1.0&ep=861107059739459&b=U<=300。

    ⑥ FF 1个字节,分隔符,用于区分 CoAP 首部 与 负载数据。

    ⑦ 3C2F3E3B72743D226F6D612E6C776D326D222C3C2F312F303E2C3C2F322F303E2C3C2F332F303E2C3C2F342F303E2C3C2F352F303E2C3C2F362F303E2C3C2F372F303E2C3C2F31392F303E2C3C2F31392F313E Payload 负载数据,ASSIC 转换后得 ;rt="oma.lwm2m",,,,,,,,, ,与 OC 平台文档 要求一致。

  • 相关阅读:
    19.声明式事务的事务隔离级别和事务传播行为
    语义分割笔记(三):通过opencv对mask图片来画分割对象的外接椭圆
    C primer plus学习笔记 —— 3、字符的IO(输入/输出)
    2022工控中国大会合作全面开启
    苹果Mac优化清理工具CleanMyMac X2023版本
    C++对string进行大小写转换的三种方法
    [AIGC] 深入理解Flink中的窗口、水位线和定时器
    不止于“初见成效”,阿斯利康要让数据流转,以 AI 带动决策智能
    vue input输入框限制输入负号、数字、以及两位小数
    迈向100倍加速:全栈Transformer推理优化
  • 原文地址:https://blog.csdn.net/h4241778/article/details/132907835