开发者学堂课程【嵌入式之 RFID 开发与应用2020版：NB-IoT 之 CoAP 协议格式介绍】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/665/detail/11196
NB-IoT 之 CoAP 协议格式介绍
内容介绍：
一、CoAP 协议简介
二、CoAP 协议结构
三、小结
一、CoAP 协议简介
CoAP 协议是非常重要的一个协议，不管是三大运营商，还是各大云平台、互联网平台，都会用到这个协议。要么直接用 CoAP 协议；要么就是在 CoAP 协议之上用这个 lwhm 的协议。所以这个协议很重要，一定要了解。
前面讲过的 MQTT 作为互联网通讯里面非常重要的一个协议， CoAP 也不例外。 CoAP 协议是一种受限制的应用协议，主要是因为现在的物联网环境里面，终端设备和资源本身就是受限制，计算能力、空间都是受限制的。因为最终设备是要联网的，按照过去通过 CoAP 端去访问网络服务器，通常是 http ，或者其他的一些httpd 啊或者是 tftp。如果用 http 的话，协议就过于庞大，并不适用。所以说 IETF 工作小组发布了 CoAP 协议，其核心包括 RFC 7252 以及一些扩展相关的协议。
这个协议首先是工作在应用层，运行在 UDP 的传输层之上，属于 TCP 协议族中的一部分。对于 IEFT 工作小组，它提出的这种架构不只是基于 UDP ，也是一种基于 REST 架构的思想。REST 其实就是一种基于利用类似 http 的一些特征来实现对服务器的数据，包括终端数据的一些操作。
Coap 是基于 REST 风格，对数据进行增删查改。过去在 http 里面，正常情况下要去访问一个资源，一般通过输入 GET/xx/yy/ops 把要操作的方式跟在路径里面。对于这种 REST 风格，就不要把相关的操作跟在某个 GET 或者 POST 的后面。
对以下内容做出规定
GET： 就是获取资源的(查)
POST ：就是添加资源的（增）
PUT ：操作即修改资源（改）
DELETE：删除（删）
这就是利用了 http 之前的动态、特性来实现这种操作。所以说 CoAP 是基于 REST 的风格，而并不是一种新的标准。
传输层采用的是 UDP ，网络层的话默认是用的是这个 6LoWPAN，也就是默认IPv6。但是也可以去进行修改。
二、CoAP 协议结构：
1.协议的具体架构
对比着之前学过的 MQTT 来看，对于我们的 CoAP 的话，底层用的就是 6LoWPAN，上面的话就是 UDP 。应用层是 CoAP，是我们的应用协议。再往上的话，就是又对它进行了分层，把它分成了 lwM2M 的协议，以及目标、实力、资源，这些就属于更上层的东西。
所以不管是研究 LwM2M 去使用这种协议，还是用直接用 CoAP 协议，都需要去了解 CoAP 。它跟 MQTT 处在同一层，但是这个 CoAP 的资源会更少，因为 UDP 本身是面向无连接的。 CoAP 无连接是一种不可靠的，所以 CoAP 在这种不可靠的基础上又增加了一些协议。增加的内容其实并不多，最少的时候可以只有4个字节，即只在 UDP 的基础上加上4个字节，此时开销就很小。 TCP 本身这个要三次握手，还要挥手就很多，再加上往上的 MQTT 或者 http ，就会让整个协议变得复杂庞大，功耗、内存、空间相应的也会增加。
协议的分层通常是底层是 Mac 层、网络层、传输层、应用层。但是如果要看这个包，就需要倒过来看，也就是 MAC 需要放上面，先是目的地址、原地址，然后是协议类型；IP 的话涉及到版本、报头、服务类型。包括源 IP、目的 IP、可选项； UDP 的参数比较少，源端口、目的端口、报文长度以及带伪尾头部； CoAP 的核心部分是 Ver （占两个比特位）、T（报文类型，占两位）、TKL（代表Token的长度，在这里可以没有，即字段为 0）、Code（即各种操作），也就是它的版本。包括报文类型、版本号。Message ID 消息 ID 是可有可无的，Options 选项也是同理，可有可无。
载荷如果没有的话，就不会有分割符了。所以后面这些都可以没有。最少的情况下就是 4 个字节，即 Ver 、T、TKL、Code。就只能完成一个简单的应答或者是请求，此时就只需要增加这 4 个字节就可以了。这个协议非常简单，很容易理解。有关版本的话，一般情况下默认都是 01，就是这两个 Ver 默认都是 01，按照这存储的这个顺序，如果 Ver 是 01， T 为 00 的话，此时这个半制的话，16 进制就是4， Topic 如果也没有的话，就是 40，所以会发现如果抓包的话，抓出来的协议大部分都是40，就是这个原因。Code 即为它的一些操作了。
先看报文类型，会发现有时候它并不是 0，还有可能是 1，有可能是 2。 T 也是占两位，存在以下几种情况：
CoAP 协议定义了4种不同形式的报文 (CON，NON，ACK，RST):
（1）Confirmable Message(CON)，CON 报文需要被接受者确认，即每一个 CON报文都需要对应一个 ACK 报文或 RST 报文。即 00.
（2）Non-Confirmable Message(NON)，不需要被确认的报文，常用于传感器一类只需单向传送数据的应用场景，纯单向传输，不需要应答，收不到也不管。即01.
（3）Acknowledgement Message(ACK),应答报文用于确认 CON 报文，用于确认 CON 报文。即 10,.
（4）Reset Message(RST)，复位报文，当服务器收到一个 CON 报文，如果报文中出现上下文缺失，导致无法处理时，服务器将返回一个 RST 报文。让客户端再发一次。即 11.
后面没有讲报文类型二进制的表达，但可以抓包看一下，一共就 2 位，共 4 种情况：00、01、10、11
TKL：标签长度指示
占 4 位，用于指示 Token 区域的具体长度。 TKL 本身是 16 个比特，也就是 2 个字节，当 CoAP 报文包含 Token 时，TKL 取值 0b0001(1)、0b0010(2)或0b0100(4)
>当 CoAP 报文省略 Token 时，TKL 取值 0b0000
TKL 的区域如果存在的话，取值的以是 1、2、4 这样三种情况。如果报文取0的话， TKL 就不存在。
Code：准则，代表应答、请求；一些具体操作。
Code 是占 8 位，因为 Ver、T总共是两个字节，后面还有 2 个字节。这八位其中的高三位 Class 是用做 message ；低五位 Detall 部分采用 c.dd 的形式描述。
来看一下表达形式：高三位加上低五位就是写成 c.dd，c 代表是高三位，dd 代表的是低五位，且均采用十进制。高三位的取值范围就是 0~7 了，因为只有 3 位；后面低五位可以到 0~31，其取值范围更大一些。当 c=0，也就是高三位为0的时候，就是一个 CoAP 请求；如果高三位不是 0 的话，那表示它是一个 CoAP 响应。Code =0.00 表示空报文，是特殊形式的 CoAP 响应。具体形式如下：
格式里面如果出现的是 0.xx，就表示它是一个请求。比如说去 get 资源、POST 资源、删除资源等。这都是 CoAP 端向服务器发出的请求。URI 就是我们的资源定位。
应答请求码对照如下：
首先成功的应答分为已创建资源成功 2.01；删除资源成功 2.02；更新资源的更新是指的是执行缓存响应一般为空的时候；2.04 是资源已更新。2.05 为请求执行。
另外几种情况如下表：
例如请求的服务器是出错了，就是 4.00；请求的 CoAP 端没有权限，比如删某个东西没有权限去删除的话，应答的就是 4.01；包括还有一些什么出错、找不到资源的非法请求，这些也会给大家演示。还有 5 开头的服务器出错，服务器本身的错误，左边是 CoAP 端的错误，右边服务器的错误。
了解了这些协议之后，通过后面的例子，就可以看到反馈的这些值大概是多少，对应的错误是什么，来查上边的这张表。
2.Messagr ID
消息 ID 它不是必须的，占 16 位采用大端的方式去存储。是 CoAP 端和服务器之间建立的一一对应关系，起到了报文的确定确认的作用。也就是在一次会话当中，如果 Message ID没有变，就是没有问题。会话结束的时候呢这个 ID就会变成下一个，相当于就是回收了。消息ID其实就是完成了或者弥补了 UDP 里面的这种数据报的不可靠性，把它变得稍微可靠一点，但是也可以不要它，沿用之前的数据信息、数据模式。
3.Token
是一种相互确认，在 http里面经常用到一些垫权，也会用到它。这个地方把它简化了。
4.Options ：选项
选项内容它可长可短，类似于 htttp 里面的首部字段，它可以是多个字节，可长可短。不知道有多长不知道有多短，
5.Oxff：分隔符
通过ff来区分 CoAP 这个协议的载荷部分，就是要传输的实际的数据部分。
6.Payload：负载
是真正有用的被交互的数据； CoAP 负载可包含不同的媒体类型：二进制、文本、XML、JSON、CBOR等。媒体类型采用编号的方式进行定义，编号占16位。
常见类型如下：
对于传输的这个模式，会有一个类型约定是什么类型的产品。
7.CoAP 协议的通信过程
4 种报文格式约束了整个通讯的过程，它不是单向的，而是双向、互相确认的过程。弥补了 UDP 的单向不可靠。比如说 CON 就是需要必须应答的，
除了 NON 这个以外是不需要应答的，下面的两种就是应答内容、应答的包。
三、小结
CoAP 协议大概就这么多,总结一下我们之前学过的 MQTT 和 CoAP 它们之间有什么样的区别？
1. MQTT 更开放一些，整个的数据、内容由用户自己决定； CoAP 协议里面有帮助 CoAP 端理解的标签信息。协议里面就包含了一些 CoAP 端帮助客户理解的内容，包括讲到比如说请求资源删除资源，以及应答带了这么多种格式，就告诉我们的服务器或者服务器高手的 CoAP 端，这个包里面具体错在哪以及做什么操作。信息量更大，与 MQTT 完全由自己的主题内容去决定不同。
MQTT 是长连接的， CoAP 是一次单独通信，开销是比较大的。
3. MQTT 是多对多的，是一个中介，是一个 broker，完成了各种 CoAP 端的这种解耦，实现多个 CoAP 端之间的通信；对于 CoAP 来说，只是服务器跟 CoAP 端之间的这种单对单的投资。
假如说功耗允许的情况下，其实还是建议使用 MQTT 因为其更加自由、灵活一些。
