CoAP与 MQTT 初步了解总结

1.什么是CoAP

 CoAP(Constrained Application Protocol)，CoAP是一种应用层协议，它运行于UDP协议之上而不是像HTTP那样运行于TCP之上。CoAP协议非常小巧，最小的数据包仅为4字节. CoAP并不能替代HTTP协议，但是对于那些小设备（256KB Flash 32KB RAM 20MHz主频）而言CoAP的确是一个好的解决方案.

2.CoAP消息类型

coap 采用的的类似于http的请求响应工作模式，它总共有四种不同的消息类型
 1. CON---需要被确认的请求，如果发送CON请求，对方必须进行回应
 2. NON---不需要被确认的请求，如果发送NON请求，那么对方不必做出回应
 3. ACK---应答消息，对CON请求的响应
 4. RST---复位消息，当接受者接受到的消息包含一段错误信息，接受者解析消息，或者不在关心发送者发送的内容，复位消息将会被发送

3.CoAP结构体

 一个CoAP消息最小为4个字节，以下是CoAP协议不同部分的描述。

【版本Version】：类似于IPv6和IPv6，仅仅是一个版本号。
【消息类型Message Type】：CON，NON，ACK，RST。
【消息ID Message ID】：每个CoAP消息都有一个ID，在一次会话中ID总是保持不变。但在这个会话之后该ID会被回收利用。
【标记 Token】：标记是ID的另一种表现。
【选项 Options】：CoAP选项类似于HTTP请求头，它包括CoAP消息本身，例如CoAP端口号，CoAP主机和CoAP查询字符串等。
【负载Payload】：真正有用的被交互的数据。

4.CoAP的URL

在HTTP的世界中，RESTFul协议由于其简单性和适用性，在WEB应用中越来越受欢迎，这样的道理同样适用于CoAP。一个CoAP资源可以被一个URI所描述，例如一个设备可以测量温度，那么这个温度传感器的URI被描述为：CoAP://machine.address:5683/sensors/temperature。请注意，CoAP的默认UDP端口号为5683。

5.CoAP观察模式

 CoAp采用的是观察者模式，当你去监控某个传感器的数据信息时，你不需要不停地去查询数据。CoAP客户端可以发送一个观察请求到服务器端。从该时间点开始计算，服务器便会记住客户端的连接信息，一旦温度发生变化，服务器将会把新结果发送给客户端。如果客户端不在希望获得温度检测结果，那么客户端将会发送一个RST复位请求，此时服务器便会清除与客户端的连接信息。

MQTT

MQTT是基于二进制消息的发布/订阅编程模式的消息协议，最早由IBM提出的，如今已经成为OASIS规范。由于规范很简单，非常适合需要低功耗和网络带宽有限的IoT场景，比如：

遥感数据
汽车
智能家居
智慧城市
医疗医护

由于物联网的环境是非常特别的，所以MQTT遵循以下设计原则：

精简，不添加可有可无的功能。
发布/订阅（Pub/Sub）模式，方便消息在传感器之间传递。
允许用户动态创建主题，零运维成本。
把传输量降到最低以提高传输效率。
把低带宽、高延迟、不稳定的网络等因素考虑在内。
支持连续的会话控制。
理解客户端计算能力可能很低。
提供服务质量管理。
假设数据不可知，不强求传输数据的类型与格式，保持灵活性。

发布/订阅模式

与请求/回答这种同步模式不同，发布/定义模式解耦了发布消息的客户（发布者）与订阅消息的客户（订阅者）之间的关系，这意味着发布者和订阅者之间并不需要直接建立联系。打个比方，你打电话给朋友，一直要等到朋友接电话了才能够开始交流，是一个典型的同步请求/回答的场景；而给一个好友邮件列表发电子邮件就不一样，你发好电子邮件该干嘛干嘛，好友们到有空了去查看邮件就是了，是一个典型的异步发布/订阅的场景。
熟悉编程的同学一定非常熟悉这种设计模式了，因为它带来了这些好处：

发布者与订阅者不比了解彼此，只要认识同一个消息代理即可。
发布者和订阅者不需要交互，发布者无需等待订阅者确认而导致锁定。
发布者和订阅者不需要同时在线，可以自由选择时间来消费消息。

主题

MQTT是通过主题对消息进行分类的，本质上就是一个UTF-8的字符串，不过可以通过反斜杠表示多个层级关系。主题并不需要创建，直接使用就是了。
主题还可以通过通配符进行过滤。其中，+可以过滤一个层级，而*只能出现在主题最后表示过滤任意级别的层级。举个例子：

building-b/floor-5：代表B楼5层的设备。
+/floor-5：代表任何一个楼的5层的设备。
building-b/*：代表B楼所有的设备。

注意，MQTT允许使用通配符订阅主题，但是并不允许使用通配符广播。
服务质量

为了满足不同的场景，MQTT支持三种不同级别的服务质量（Quality of Service，QoS）为不同场景提供消息可靠性：

级别0：尽力而为。消息发送者会想尽办法发送消息，但是遇到意外并不会重试。
级别1：至少一次。消息接收者如果没有知会或者知会本身丢失，消息发送者会再次发送以保证消息接收者至少会收到一次，当然可能造成重复消息。
级别2：恰好一次。保证这种语义肯待会减少并发或者增加延时，不过丢失或者重复消息是不可接受的时候，级别2是最合适的。

服务质量是个老话题了。级别2所提供的不重不丢很多情况下是最理想的，不过往返多次的确认一定对并发和延迟带来影响。级别1提供的至少一次语义在日志处理这种场景下是完全OK的，所以像Kafka这类的系统利用这一特点减少确认从而大大提高了并发。级别0适合鸡肋数据场景，食之无味弃之可惜，就这么着吧。

消息类型

MQTT拥有14种不同的消息类型：

1.CONNECT：客户端连接到MQTT代理
2.CONNACK：连接确认
3.PUBLISH：新发布消息
4.PUBACK：新发布消息确认，是QoS 1给PUBLISH消息的回复
5.PUBREC：QoS 2消息流的第一部分，表示消息发布已记录
6.PUBREL：QoS 2消息流的第二部分，表示消息发布已释放
7.PUBCOMP：QoS 2消息流的第三部分，表示消息发布完成
8.SUBSCRIBE：客户端订阅某个主题
9.SUBACK：对于SUBSCRIBE消息的确认
10.UNSUBSCRIBE：客户端终止订阅的消息
11.UNSUBACK：对于UNSUBSCRIBE消息的确认
12.PINGREQ：心跳
13.PINGRESP：确认心跳
14.DISCONNECT：客户端终止连接前优雅地通知MQTT代理

http://www.cnblogs.com/ibrahim/p/amazon-aws-iot.html