什么是CoAP
CoAP（Constrained Application Protocol）是一种简化压缩的 HTTP RESTful API 协议 。其目标是实现在资源受限 ( 低能源、网络环境差 ) 的环境下的应用（ 例如M2M应用 ）进行通信。
什么是M2M 应用？
M2M （ Machine to Machine ） 是指通过一些移动通信对设备进行有效控制。例如移动监控、移动物流管理等。
CoAP 的特点
在受限制的环境下可以满足 M2M 所需要的Web协议环境。 可选转为可靠的 UDP 进行绑定，支持单播和多播。 异步交换信息。 简单的报文头部。 URI 和 内容类型 （ Content-type ）的支持。 简单的代理和缓存功能。 可通过构建代理以提供 HTTP 统一方式来访问的接口。 绑定数据包传输层安全性协议。 名词解释：
单播 一个节点只与一个节点进行通信。
类似你和你朋友聊天，你一句他一句。
多播 一个节点与多个节点进行通信。
例如网络视频会议，网络直播。一个人讲，多个人看。
CoAP 内部详解
CoAP 是一个很像 HTTP Client/Server 模型的协议。可以简单将CoAP 分为两层。
UDP 层 ：基于UDP 进行消息传输。 CoAP 消息传递层：用于处理UDP 和 异步交互。
CoAP 的URI
CoAP 的 URI 也是类似 HTTP 。使用 “coap” ( 类似 http )、 “coaps”（ 类似 https ）来区分是否为 CoAP 服务。
官方提醒：随着时间的流逝，其URI的格式已经十分的复杂。需要仔细检查。
Implementation Note: Unfortunately, over time, the URI format has acquired significant complexity. Implementers are encouraged to examine [RFC3986] closely. For example, the ABNF for IPv6 addresses is more complicated than maybe expected. Also, implementers should take care to perform the processing of percent-decoding or percent-encoding exactly once on the way from a URI to its decoded components or back. Percent-encoding is crucial for data transparency but may lead to unusual results such as a slash character in a path component.
CoAP URI 格式：coap-URI = “coap:” “//” host [ “:” port ] path-abempty [ “?” query ]
注：[] 内为可选值
与 HTTP 不同，CoAP 协议的默认端口为：5683。
CoAPs URI 格式：coaps-URI = “coaps:” “//” host [ “:” port ] path-abempty [ “?” query ]
注：[] 内为可选值
与 HTTPS 不同，CoAPS 协议的默认端口为：5684。
关于URI的一些规范 CoAP 协议后的参数和 HTTP 相同，即为 key=value 键值对，并用 (U+0026 AMPERSAND “&”) 进行分隔。 COAP 协议规定如何端口等于协议的默认端口，则通常取消其端口展示。如： coap：//example.com：5683 /〜sensors / temp.xml
等于：coap：//example.com/〜sensors / temp.xml
CoAP 内的路径如果不填，则默认为绝对路径 “/” Host 不区分大小写。 除了 “保留的字符集” 以外，其他的字符等同于其百分比的编码。下面三个链接意义相等。
coap：//example.com：5683 /〜sensors / temp.xml coap：//EXAMPLE.com/%7Esensors/temp.xml coap：//EXAMPLE.com：/%7esensors/temp.xml消息类型
CoAP 基于UDP 进行信息交换。每条消息包含一个消息ID，用于检测重复和可靠性（ 可选 ）。CoAP 协议规定共有四种消息类型：
CON — 指定需要被确定（ ACK ）的请求。如果对方返回则会进行重试。（ 用以要求可靠性的请求 ） ACK — 对CON的确认应答。 RST — 复位消息。如果接收端不可处理或者错误则返回 RST 消息。
Request/Response 模型
简单通信如果客户端和服务端之间通信可以立马返回相关的响应，则其称其为（ Piggybacked response ），如下图：
如果服务端不能理解返回客户端所需要的响应，则会先返回一个空的ACK 报文，当服务端处理完成后，将会重新发送给客户端一个CON 报文进行把刚才响应进行传输。
基于 UDP 的 CoAP 可以发送不可靠的通信包。经常用在检测一个实时进度，不需要对后面进行追测的数据。
Coap 使用类似 HTTP 请求的 GET、PUT、POST、DELETE 方法进行通信。
虽大致相同，但也是有一些地方有较大的差异，例如 CoAP 可以支持多播的情况等，本文不展开讲解，如想深入了解可以阅读相关规范。
CoAP 消息格式
CoAP消息以简单的二进制格式编码。 消息格式以固定大小的4字节报头开头。 其后是可变长度的Token值，该值的长度可以在0到8个字节之间。TOKEN 之后是Type-Length-Value（TLV）格式的一系列零个或多个CoAP选项，Options 的是后面跟有一个有效载荷，占满了数据报的其余部分。
第一行的消息头，其固定长度4个字节。下面讲解其中各个字段意义：
Ver(2 bit unsigned integer) CoAP的版本号。规定为 1（ 二进制01 ）。 T (2 bit unsigned integer) 该消息的类型。 0 可确认 1 不可确认 2 确认 3 重置 TKL （4 bit unsigned integer）可变长度令牌的长度。 Code （8 bit unsigned integer）前3bit代表类型 和后5bit表示详细信息。 Message ID (16 bit unsigned integer）用于检测消息重复和消息匹配。CoAP 的可靠传输
既然CoAP 是基于UDP 的。那么它是如何做到可靠传输的呢？
通过在CoAP标头中将消息标记为“可确认”来启动消息的可靠传输。其主要规则如下：
可确认消息 ( CON ) 始终带有请求或响应（ 除非它仅用于引发复位消息，在这种情况下为空 ）。 收件人必须用确认消息 ( ACK ) 确认一条确认消息 ( CON )，如果收件人缺乏上下文来正确处理该消息，包括该消息为空的情况，则拒绝该消息。 如果消息格式错误。通过发送匹配的“重置”消息 ( RST )并忽略它。 确认消息 ( ACK ) 与重置消息( RST ) 必须回显可确认消息的消息ID( Message ID )，并且必须携带响应或为空。 拒绝确认或重置消息（包括确认携带带有保留类的请求或代码，或者重置消息不为空的情况）是通过无视其忽略来实现的。 重传CoAP 的重传机制是由超时时间和重传计数控制，对于每一个发出的CON类型的消息，发送端必须一直维护超时时间和重传计数,直到收到对应的ACK或者RST，才会被认为该消息成功。
总结
本篇简单带着大家了解了一下物联网传输协议中的 CoAP( Constrained Application Protocol ) 协议。其主要运用在一些受限制（ 例如能源、网络受限 ）的 M2M的机器设备上。 该协议实现了类似 HTTP 协议的一些方法和特点。也提供了基于 UDP 的可靠性与重传机制。
