1、前言
目前做的nb网关，只支持公司内部传感器接入，为了兼容市面上绝大部分nb传感器接入，需要支持目前主流物联网协议，如COAP
2、概念
CoAP是受限制的应用协议(Constrained Application Protocol)的代名词。在当前由PC机组成的世界，信息交换是通过TCP和应用层协议HTTP实现的。但是对于小型设备而言，实现TCP和HTTP协议显然是一个过分的要求。为了让小设备可以接入互联网，CoAP协议被设计出来。CoAP是一种应用层协议，它运行于UDP协议之上而不是像HTTP那样运行于TCP之上。CoAP协议非常小巧，最小的数据包仅为4字节。
RFC 7252 这是协议文档
3、COAP协议简述
Version (Ver)：长度为2位，表示CoAP协议的版本号。当前版本为01（二进制表示形式）。
Type (T)：长度为2位，表示报文类型。其中各类型及二进制表示形式如下，Confirmable (00)、Non-confirmable (01)、Acknowledgement (10)、Reset (11)。在描述的时候为了简便，会将Confirmable缩写为CON，Non-confirmable缩写为NON，Acknowledgement缩写为ACK，Reset缩写为RST。比如一个报文的类型为Confirmable，我们就会简写为CON报文。
Token Length (TKL)：长度为4位，表示Token字段的长度。
Code：长度为8位，表示响应码。其中前3位代表一个数，后5位代表一个数。如010 00000，转为十进制就是2.00（表示时中间带一个点），其意思可以理解为HTTP中200 OK响应码。
Message ID：长度为16位，表示消息id。用来表示是否为同一个的报文（重发场景下，去重会用到），或者CON请求报文和ACK响应报文的匹配。
Token：长度由TKL字段决定，表示一次会话记录。用来关联请求和响应。有人可能有疑惑，Message ID不是可以将请求和响应关联吗？的确，CON类型的请求报文与ACK类型的响应报文可以用Message ID进行关联，但NON类型的报文由于没有要求是一对的，所以如果NON类型的报文想成对，那就只能通过相同的Token来匹配了。
Options：长度不确定，表示报文的选项。类似为HTTP的请求头，内容包括Uri-Host、Uri-Path、Uri-Port等等。
1 1 1 1 1 1 1 1：Payload Marker，用来隔离Options字段和Payload字段。
Payload：长度由数据包决定，表示应用层需要的数据。
3.1 Code部分详解
Code部分被分成了两部分，为了便于阅读，Code被描述为c.dd形式。具体内容可参考RFC7252 #12.1.1 Method Codes
3.1.1 请求
在CoAP请求中，Code被定义为CoAP请求方法，这些方法有GET、POST、PUT和DELETE，这些方法和HTTP协议非常相似。
【0.01】GET方法——用于获得某资源
【0.02】POST方法——用于创建某资源
【0.03】PUT方法——用于更新某资源
【0.04】DELETE方法——用于删除某资源
3.1.2 响应
在CoAP响应中，Code被定义为CoAP响应码，类似于HTTP 200 OK等等。
【2.01】Created
【2.02】Deleted
【2.03】Valid
【2.04】Changed
【2.05】Content。类似于HTTP 200 OK
【4.00】Bad Request 请求错误，服务器无法处理。类似于HTTP 400。
【4.01】Unauthorized 没有范围权限。类似于HTTP 401。
【4.02】Bad Option 请求中包含错误选项。
【4.03】Forbidden 服务器拒绝请求。类似于HTTP 403。
【4.04】Not Found 服务器找不到资源。类似于HTTP 404。
【4.05】Method Not Allowed 非法请求方法。类似于HTTP 405。
【4.06】Not Acceptable 请求选项和服务器生成内容选项不一致。类似于HTTP 406。
【4.12】Precondition Failed 请求参数不足。类似于HTTP 412。
【4.15】Unsuppor Conten-Type 请求中的媒体类型不被支持。类似于HTTP 415。
【5.00】Internal Server Error 服务器内部错误。类似于HTTP 500。
【5.01】Not Implemented 服务器无法支持请求内容。类似于HTTP 501。
【5.02】Bad Gateway 服务器作为网关时，收到了一个错误的响应。类似于HTTP 502。
【5.03】Service Unavailable 服务器过载或者维护停机。类似于HTTP 503。
【5.04】Gateway Timeout 服务器作为网关时，执行请求时发生超时错误。类似于HTTP 504。
【5.05】Proxying Not Supported 服务器不支持代理功能。
3.2 Option部分详解
CoAP支持多个Option，CoAP的Option的表示方法比较特殊，采用增量的方式描述，细节可参考RFC7252 #3.1
一般情况下Option部分包含Option Delta、Option Length和Option Value三部分。
【Option Delta】表示Option的增量，当前的Option的具体编号等于之前所有Option Delta的总和。
【Option Length】表示Option Value的具体长度。
【Option Value】表示Option具体内容
CoAP中所有的Option都采用编号的方式，这些Option及编号的定义如下图所示。
在这些option中，Uri-Host、Uri-Port、Uri-Path和Uri-Query等和资源“位置”和参数有关。
【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相同。
CoAP协议中支持多个Option，例如
第一个Option Delta=11，表示该Option表示Uri-Path(11)
第二个Option Delta=1，表示该Option=1+11，表示Content-Format(12)
第三个Option Delta=3，表示该Option=3+1+11，表示Uri-Query(15)
CoAP采用这样的方式表示多个Option，而每种Option都可以在HTTP协议中找到对应项。
3.3 Content-Format描述
CoAP支持多种媒体类型，具体可参考RFC7252 #12.3。从下图的信息可以发现，CoAP协议中关于媒体类型的定义比较简单，未来应该会根据实际情况扩展。
图5.1 Content-Format编号内容
【text/plain】 编号为0，表示负载为字符串形式，默认为UTF8编码。
【application/link-format】编号为40，CoAP资源发现协议中追加定义，该媒体类型为CoAP协议特有。
【application/xml】编号为41，表示负载类型为XML格式。
【application/octet-stream】编号为42，表示负载类型为二进制格式。
【application/exi】编号为47，表示负载类型为“精简XML”格式。（翻译不一定准确）
另外，还有一种格式也北IANA认定，也会在CoAP协议中广泛使用那便是CBOR格式，该格式可理解为二进制JSON格式。
【applicaiton/cbor】编号为60。
4 示例
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
以上是客户端发送消息示例
5 开源框架 Californium 浅析
待续......
