CoAP是受限制的应用协议(Constrained Application Protocol)的代名词。在当前由PC机组成的世界，信息交换是通过TCP和应用层协议HTTP实现的。但是对于小型设备而言，实现TCP和HTTP协议显然是一个过分的要求。为了让小设备可以接入互联网，CoAP协议被设计出来。CoAP是一种应用层协议，它运行于UDP协议之上而不是像HTTP那样运行于TCP之上。CoAP协议非常小巧，最小的数据包仅为4字节。
1 CoAP协议综述
和其他TCP IP协议簇中的协议一样，CoAP协议总是以“头”的形式出现在负载之前，而负载和CoAP头之间使用单字节0xFF分离。学习CoAP协议最好的方法便是结合RFC文档，详细分析CoAP协议报文格式的每一部分，便是CoAP协议报文结构示意图。
图1.1 CoAP协议报文结构示意图
2 CoAP协议报文各部分
【Ver】 版本编号，指示CoAP协议的版本号。类似于HTTP 1.0 HTTP 1.1。版本编号占2位，取值为01B。
【T】报文类型，CoAP协议定了4种不同形式的报文，CON报文，NON报文，ACK报文和RST报文。
【TKL】CoAP标识符长度。CoAP协议中具有两种功能相似的标识符，一种为Message ID(报文编号)，一种为Token(标识符)。其中每个报文均包含消息编号，但是标识符对于报文来说是非必须的。
【Code】功能码/响应码。Code在CoAP请求报文和响应报文中具有不同的表现形式，Code占一个字节，它被分成了两部分，前3位一部分，后5位一部分，为了方便描述它被写成了c.dd结构。其中0.XX表示CoAP请求的某种方法，而2.XX、4.XX或5.XX则表示CoAP响应的某种具体表现。
【Message ID】报文编号
【Token】标识符具体内容，通过TKL指定Token长度。
【Option】报文选项，通过报文选项可设定CoAP主机，CoAP URI，CoAP请求参数和负载媒体类型等等。
【1111 1111B】CoAP报文和具体负载之间的分隔符。
3 Code部分详解
Code部分被分成了两部分，为了便于阅读，Code被描述为c.dd形式。具体内容可参考RFC7252 #12.1.1 Method Codes
3.1 请求
在CoAP请求中，Code被定义为CoAP请求方法，这些方法有GET、POST、PUT和DELETE，这些方法和HTTP协议非常相似。
【0.01】GET方法——用于获得某资源
【0.02】POST方法——用于创建某资源
【0.03】PUT方法——用于更新某资源
【0.04】DELETE方法——用于删除某资源
3.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 服务器不支持代理功能。
4 Option部分详解
CoAP支持多个Option，CoAP的Option的表示方法比较特殊，采用增量的方式描述，细节可参考RFC7252 #3.1
图4.1 CoAP部分Option定义
一般情况下Option部分包含Option Delta、Option Length和Option Value三部分。
【Option Delta】表示Option的增量，当前的Option的具体编号等于之前所有Option Delta的总和。
【Option Length】表示Option Value的具体长度。
【Option Value】表示Option具体内容
CoAP中所有的Option都采用编号的方式，这些Option及编号的定义如下图所示。
图4.2 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协议中找到对应项。
5 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。
6 示例
该示例来自于RFC7252。
【流程描述】
CoAP客户端通过GET方法从Server端获得温度传感器数据，CoAP URI如下
coap://www.server.com/temperautre
CoAP请求采用CON报文，Server接收到CON报文必须返回一个ACK报文。CoAP请求采用0.01 GET方法，若操作成功CoAP Server返回2.05 Content，相当于HTTP 200 OK。请求和响应的MID必须完全相同，此处为0x7d34。请求响应中的Token域为空。CoAP请求中包含Option，该Option的类型为Uri-Path，那么Option Delta的值为0+11=11，Option Value的值为字符串形式的“temperature”。CoAP返回中包含温度数据，使用字符串形式描述，具体值为"22.3"。
图6.1 CoAP 请求响应流程
【格式描述】
图6.2 CoAP请求响应具体格式
7 总结
一旦熟悉了CoAP协议的格式，那么再学习CoAP协议的应用就轻松多了。
