学习CoAP最简单的方法便是阅读协议文档。该协议文档并不是那么复杂。当然如果有一个CoAP的简单介绍那就再好不过了。
什么是CoAP
CoAP是受限制的应用协议(Constrained Application Protocol)的代名词。在最近几年的时间中，专家们预测会有更多的设备相互连接，而这些设备的数量将远超人类的数量。在这种大背景下，物联网和M2M技术应运而生。虽然对人而言，连接入互联网显得方便容易，但是对于那些微型设备而言接入互联网非常困难。在当前由PC机组成的世界，信息交换是通过TCP和应用层协议HTTP实现的。但是对于小型设备而言，实现TCP和HTTP协议显然是一个过分的要求。为了让小设备可以接入互联网，CoAP协议被设计出来。CoAP是一种应用层协议，它运行于UDP协议之上而不是像HTTP那样运行于TCP之上。CoAP协议非常的小巧，最小的数据包仅为4字节。
CoAP协议是否可以替换HTTP协议？
CoAP并不能替代HTTP协议，但是对于那些小设备（256KB Flash 32KB RAM 20MHz主频）而言CoAP的确是一个好的解决方案。
CoAP消息类型
CoAP采用和HTTP协议相同的请求响应工作模式。CoAP协议共有4中不同的消息类型。
CON——需要被确认的请求，如果CON请求被发送，那么对方必须做出响应。
NON——不需要被确认的请求，如果NON请求被发送，那么对方不必做出回应。
ACK——应答消息，如果接受到CON消息的响应。
RST——复位消息，当接收者接受到的消息包含一个错误，接受者解析消息或者不再关心发送者发送的内容，那么复位消息将会被发送。
CoAP消息结构
一个CoAP消息最小为4个字节，以下是CoAP协议不同部分的描述。
【版本Version】：类似于IPv6和IPv6，仅仅是一个版本号。
【消息类型Message Type】：CON，NON，ACK，RST。这些消息类型相当于HTTP协议的PUTGET等
【消息ID Message ID】：每个CoAP消息都有一个ID，在一次会话中ID总是保持不变。但是在这个会话之后该ID会被回收利用。
【标记 Token】：标记是ID的另一种表现、
【选项 Options】：CoAP选项类似于HTTP请求头，它包括CoAP消息本身，例如CoAP端口号，CoAP主机和CoAP查询字符串等。
【负载Payload】：真正有用的被交互的数据。
CoAP的URL
在HTTP的世界中，正式RESTFul协议由于其简单性和适用性，在WEB应用中越来越受欢迎，这样的道理同样适用于CoAP。一个CoAP资源可以被一个URI所描述，例如一个设备可以测量温度，那么这个温度传感器的URI被描述为：CoAP://machine.address:5683/sensors/temperature。请注意，CoAP的默认UDP端口号为5683。
CoAP观察模式
在物联网的世界中，你需要去监控某个传感器例如温度或湿度等。在这种情况下，CoAP客户端并不需要不停的查询CoAP服务器端的数据变化情况。CoAP客户端可以发送一个观察请求到服务器端。从该时间点开始计算，服务器便会记住客户端的连接信息，一旦温度发生变化，服务器将会把新结果发送给客户端。如果客户端不在希望获得温度检测结果，那么客户端将会发送一个RST复位请求，此时服务器便会清除与客户端的连接信息。
CoAP块传输
CoAP协议的特点是传输的内容小巧精简，但是在某些情况下不得不传输较大的数据。在这种情况下可以使用CoAP协议中的某个选项设定分块传输的大小，那么无论是服务器或客户端可完成分片和组装这两个动作。
最近做了一个项目，使用GPRS模块上传数据应用UDP协议，而服务器没有应答机制。每个数据包均包括一个序列号，序列号占用两个字节。为了保证客户端上传的数据服务器可以收到，客户端采用重发机制，简单的说同一个数据发送2次或者3次，为了区别同一个数据包还加入了子序列号。项目进行到最后出现了一些问题，对比CoAP协议做一个总结。
一个数据包是否需要应答？
这个需要分情况而定，如果是一个传感器的温度数据，那么传输该数据时可能不需要应答，因为即使该数据丢失了下一时刻新的数据也会把旧的数据覆盖掉。但是如果温度超过一个阈值通俗的讲便是温度报警，在这种情况下传输该数据包往往需要应答，必须要保证服务器接收到该数据包，温度报警往往预示着一个紧急情况即将发生或已经发生。从这个角度看看CoAP协议便发觉CoAP协议设计的非常好，CoAP协议支持4种消息，例如CON需确认消息，NON无需确认消息，CON和NON便可解决该项目的困惑。可以肯定的是，继续研究CoAP协议将会获得更大的收获。
参考资料
【CSDN博客：CoAP协议和开源实现】
摘自：
