COAP协议

一、初识COAP协议

（一）、起源

（二）、 概念

​ CoAP约束应用协议（Constrained Application Protocol）是一种专用于受限设备的Internet应用协议，如RFC 7252所定义，它使那些被称为“节点”的受约束设备能够使用类似的协议与更广泛的Internet进行通信。CoAP被设计用于同一受限网络（例如，低功耗、有损网络）上的设备之间、设备和因特网上的一般节点之间以及由因特网连接的不同受限网络上的设备之间使用。CoAP也被用于其他机制，如移动通信网络上的SMS。

​ 总结：CoAP是受约束设备的专用Internet应用程序协议。

（三）、特点

• 基于消息模型，定义了4个消息类型，以消息为数据通信载体，通过交换网络消息来实现设备间数据通信
• 基于请求/响应模型 ,对CoAP Server云端设备资源操作都是通过请求与响应机制来完成，类似HTTP，设备端可通过4个请求方法（GET, PUT, POST, DELETE）对服务器端资源进行操作。 请求与响应的数据包都是放在CoAP消息里面进行传输的
• 基于消息的双向通信（M2M），CoAP Client与CoAP server双方都可以独立向对方发送请求.双方可当client或者server角色
• 轻量最小长度仅为4B
• 支持可靠传输 ,数据重传，块传输。 确保数据可靠到达。
• 支持IP多播 , 即可以同时向多个设备发送请求（比如CoAP client搜索CoAP Server）
• 低功耗 ,非长连接通信
• 支持受限设备
• 支持观察模式
• 支持异步通信
  …

（四）、 与其他物联网协议(HTTP、CoAP、MQTT)的区别

协议内容:CoAP是一个完整的二进制应用层协议，消息格式紧凑，默认运行在UDP上。

讯享网

• HTTP和CoAP
  • HTTP代表超文本传输协议，CoAP代表约束应用协议;
  • HTTP协议的传输层采用了TCP，CoAP协议的传输层使用UDP;
  • CoAP协议是HTTP协议的简化版;
  • CoAP协议和HTTP协议一样使用请求/响应模型，拥有相同的方法;
  • CoAP开销更低，并支持多播;
  • CoAP专为资源构成应用而设计，如:IoT/WSN/M2M等…
• CoAP和MQTT
  • MQTT协议使用发布/订阅模型，CoAP协议使用请求/响应模型;
  • MQTT是长连接，CoAP协议是无连接;
  • MQTT通过中间代理传递消息的多对多协议，CoAP协议是Server和Client之间消息传递的单对单协议;
  • MQTT不支持带有类型或者其它帮助Clients理解的标签消息，CoAP内置内容协商和发现支持，允许设备彼此窥测以找到交换数据的方式。

二、CoAP协议初解

CoAP字段详解：

• Ver （占两位）：默认为01，其它为后续预留
• T（报文类型，占两位）：

  

  • Confirmable Message(CON)：CON 报文需要被接受者确认，即每一个 CON报文都需要对应一个 ACK 报文或 RST 报文。即 00
  • Non-Confirmable Message(NON)：不需要被确认的报文，常用于传感器一类只需单向传送数据的应用场景，纯单向传输，不需要应答，收不到也不管。即01
  • Acknowledgement Message(ACK)：应答报文用于确认 CON 报文，用于确认 CON 报文。即 10
  • Reset Message(RST)：复位报文，当服务器收到一个 CON 报文，如果报文中出现上下文缺失，导致无法处理时，服务器将返回一个 RST 报文。让客户端再发一次。即 11
• TKL（占两位，标签长度指示(代表Token的长度)）：0为特殊情况，代表空报文，可以没有Token
• Code（占八位，响应码）：分为高三位(0~7)+低五位(0 ~ 31)方式既 x.xx格式。

  请求Code类型:

  Code	Name	Description
  0.00	NULL(空报文)	特殊形式的 CoAP 响应
  0.01	GET(读取资源)	客户端要求通过请求中的URI访问资源信息
  0.02	POST(创建资源)	客户端要求服务器请求要求创建新的资源
  0.03	PUT(更新资源)	客户端要求咫务器根据请求中的URI和资源描述信息更新服务器内指定资源
  0.04	DELETE(删除资源)	客户端要求服务器根据请求中的URI删除指定资源

  响应Code类型：

  Code	Name	Description
  2.01	Created	创建资源成功
  2.02	Deleted	删除资源成功
  2.03	Valid
  2.04	Changed	资源已更新
  2.05	Content	请求执行
  4.00	Bad Request	请求错误，服务器无法处理
  4.01	Unauthorized	没有范围权限
  4.02	Bad Option	请求中包含错误选项
  4.03	Forbidden	服务器拒绝请求
  4.04	Not Found	服务器找不到资源
  4.05	Method Not Allowed	非法请求方法
  4.06	Not Acceptable	请求选项和服务器生成内容选项不一致
  4.12	Precondition Failed	请求参数不足
  4.15	Unsuppor Conten-Type	请求中的媒体类型不被支持
  5.00	Internal Server Error	服务器内部错误
  5.01	Not Implemented	服务器无法支持请求内容
  5.02	Bad Gateway	服务器作为网关时，收到了一个错误的响应
  5.03	Service Unavailable	服务器过载或者维护停机
  5.04	Gateway Timeout	服务器作为网关时，执行请求时发生超时错误
  5.05	Proxying Not Supported	服务器不支持代理功能

• Message ID (占16位，消息 ID) ：用来表示是否为同一个的报文（重发场景下，去重会用到），或者CON请求报文和ACK响应报文的匹配
• Token(长度由TKL字段决定)：表示一次会话记录，用来关联请求和响应.(CON类型的请求报文与ACK类型的响应报文可以用Message ID进行关联，但NON类型的报文由于没有要求是一对的，所以如果NON类型的报文想成对，那就只能通过相同的Token来匹配了)
• Options(长度不确定)：表示报文的选项。一般的Options包含Option Delta、Option Length和Option Value三部分。
  • 【Option Delta】表示Option的增量，当前的Option的具体编号等于之前所有Option Delta的总和。

| NO. | Name | Description | | ---- | -------------- | ------------------------------------------------------------ | | 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之间采用“?”分隔 | | 12 | Content-Format | 指定CoAP复杂媒体类型，媒体类型采用整数描述：<br />【text/plain】 编号为0，表示负载为字符串形式，默认为UTF8编码<br />【application/link-format】编号为40，CoAP资源发现协议中追加定义，该媒体类型为CoAP协议特有<br />【application/xml】编号为41，表示负载类型为XML格式<br />【application/octet-stream】编号为42，表示负载类型为二进制格式<br />【application/exi】编号为47，表示负载类型为“精简XML”格式。（翻译不一定准确）<br />【application/json】编号为50，表示负载类型为json格式<br />【applicaiton/cbor】编号为60 | | 17 | Accept | 指定CoAP响应复杂中的媒体类型，媒体类型的定义和Content-Format相同 | 

• 【Option Length】表示Option Value的具体长度。
• 【Option Value】表示Option具体内容

  具体格式如下所示，以增量的方式描述：
  

• 0xFF（Payload Marker）：用来隔离Options字段和Payload字段
• Payload（长度不定）：表示应用层需要的数据

三、CoAP协议示例

UDP client 发送 字节流 48 01 B1 08 C4 C9 BB EF FC 3F 21 04 39 6C 6F 63 61 6C 68 6F 73 74 8A 68 65 6C 6C 6F 57 6F 72 6C 64