coap 返回版本信息_物联网协议之CoAP协议开发学习笔记之协议详解

哪有什么天生如此，只是我们天天坚持。 -Zhiyuan

续上篇文章《物联网协议之CoAP协议开发学习笔记》 没看过的同学可以出门左转。https://segmentfault.com/a/11...

在进入正题之前强烈建议先看一下关于CoAP协议的一些术语，我已经为大家准备好了

这篇文章我们进入正题详解一下CoAP协议：

CoAP协议的交互模型

CoAP协议的交互模型与HTTP的客户端/服务端模型类似。

然而，在M2M的交互场景中，一个使用CoAP协议的设备通常既是客户端又是服务端。

CoAP中的请求与HTTP协议中的请求相同，是由客户端发起的，请求一个位于服务端的资源(用URI标识)，执行一个动作(用Method Code标识)。然后服务端发回一个响应，带有一个响应代码(Response Code)，这个响应中有可能也包含一个资源的表现(附带响应格式)。

与HTTP协议不同的是，CoAP的交互是异步的，构建于面向数据报的传输协议，如UDP。

交互是通过一个消息层来实现的，消息层提供了可选的可靠性支持(采用指数回退)。

CoAP协议中定义了四种类型的消息： CON, NON, ACK和RST。(下文有介绍)这四种类型的消息中包含有请求和响应标识码，标识着这些消息是请求还是响应。请求可以包含在CON和NON两种类型中，而响应则除了可以包含在CON和NON之中，还可以包含在附带响应的ACK中。

从逻辑上，可以把CoAP协议划分为两层：

消息层

消息层，用于处理UDP数据包和异步；

请求/响应层

请求/响应层，使用Method和Response Code，具体见图1。

当然，CoAP是一个协议，消息和请求/响应仅仅是其头部特性。

CoAP的四种消息类型

CON——需要被确认的请求，如果CON请求被发送，那么对方必须做出响应。

NON——不需要被确认的请求，如果NON请求被发送，那么对方不必做出回应。

ACK——应答消息，接受到CON消息的响应。

RST——复位消息，当接收者接受到的消息包含一个错误，接受者解析消息或者不再关心发送者发送的内容，那么复位消息将会被发送。

CoAP消息结构

CoAP的消息格式是很紧凑的，默认运行在UDP上(每个CoAP消息都是UDP数据包中的数据部分)。

CoAP也可以运行在DTLS协议上(见9.1节)和其它传输协议上，例如SMS，TCP或SCTP，这些不属于本文档的范畴(CoAP不支持UDP-lite[RFC3828]和UDP zero checksum[RFC6936])。

CoAP消息用二进制格式进行编码。 这个消息格式以一个固定4个字节的头部开始。

此后是一个长度在0到8字节之间的Token。Token值之后是0个或多个Type-Length-Value(TLV)格式的选项(Option)。之后到整个数据报的结尾都是payload部分，payload可以为空。

头部字段定义如下：

版本号(Ver)

2-bit无符号整型，代表CoAP版本号。本文档(7252)的实现必须设置这个字段为0b01。其它的值为今后其它版本保留。对于带有未知版本号的消息，必须忽略。

类型(T)

2-bit无符号整型。代表这个消息的类型是：CON(0), NON(1), ACK(2),或RST(3)。

Token长度(TKL)

4-bit无符号整型。表示变长的Token字段(0-8字节)的长度。长度9-15是保留的，不能设置长度为9-15。如果设置了长度为9-15，必须被当作消息格式错误来处理。

列代码(Code)

8-bit无符号整型。拆分为3-bit的分类信息和5-bit详细信息。

写作”