MQTT特点

MQTT应用

车联网M2M通信、WEB消息推送、移动即时通信、智慧城市、远程医疗、智能家居等等。

MQTT发布订阅模式

发布订阅模式是传统 Client/Server 模式的一种解耦方案，发布者通过 Broker 与订阅者之间通信。

Broker 的作用是将收到的消息通过某种过滤规则，正确地发送给订阅者。

主题本质上是一个字符串。

通配符

mqtt消息格式

固定长度头部，2 个字节，所有消息类型里都有。

可变长度头部，它驻位于固定的头和负载之间。可变头的内容因数据包类型而不同，较常的应用是作为包的标识：很多类型数据包中都包括一个2字节的数据包标识字段。

有效载荷 Payload，只有某些消息类型里有，对于发布者来说有效载荷就是应用消息。

QoS服务质量

QoS 0 - 最多分发一次：
当 QoS 为 0 时，消息的分发依赖于底层网络的能力。发布者只会发布一次消息，接收者不会应答消息，发布者也不会储存和重发消息。消息在这个等级下具有最高的传输效率，但可能送达一次也可能根本没送达。

Qos 1 - 至少分发一次：
当 QoS 为 1 时，可以保证消息至少送达一次。MQTT 通过简单的 ACK 机制来保证 QoS 1。发布者会发布消息，并等待接收者的 PUBACK 报文的应答，如果在规定的时间内没有收到 PUBACK 的应答，发布者会将消息的 DUP 置为 1 并重发消息。接收者接收到 QoS 为 1 的消息时应该回应 PUBACK 报文，接收者可能会多次接受同一个消息，无论 DUP 标志如何，接收者都会将收到的消息当作一个新的消息并发送 PUBACK 报文应答。

QoS 2 - 只分发一次：
当 QoS 为 2 时，发布者和订阅者通过两次会话来保证消息只被传递一次，这是最高等级的服务质量，消息丢失和重复都是不可接受的。使用这个服务质量等级会有额外的开销。

发布者发布 QoS 为 2 的消息之后，会将发布的消息储存起来并等待接收者回复 PUBREC 的消息，发送者收到 PUBREC 消息后，它就可以安全丢弃掉之前的发布消息，因为它已经知道接收者成功收到了消息。发布者会保存 PUBREC 消息并应答一个 PUBREL，等待接收者回复 PUBCOMP 消息，当发送者收到 PUBCOMP 消息之后会清空之前所保存的状态。

QoS适应场景

以下情况下可以选择 QoS 0
可以接受消息偶尔丢失。
在同一个子网内部的服务间的消息交互，或其他客户端与服务端网络非常稳定的场景。

以下情况下可以选择 QoS 1
对系统资源消耗较为关注，希望性能最优化。
消息不能丢失，但能接受并处理重复的消息。

以下情况下可以选择 QoS 2
不能忍受消息丢失（消息的丢失会造成生命或财产的损失），且不希望收到重复的消息。
数据完整性与及时性要求较高的银行、消防、航空等行业。

MQTT会话保持

MQTT 没有假设设备或 Broker 使用了 TCP 的保活机制，而是设计了协议层的保活机制：在 CONNECT 报文里可设置 Keepalive 字段，来设置保活心跳包 PINGREQ/PINGRESP 的发送时间间隔。当长时间无法收到设备的 PINGREQ 的时候，Broker 就会认为设备已经下线。

CoAP

是一种专用的Web传输协议，用于受约束的节点和网络。

CoAP提供了应用程序端点之间的请求/响应交互模型，支持服务的资源发现，并包括Web的关键概念，例如URI和Internet媒体类型。

CoAP是二进制格式的，HTTP是文本格式的，COAP比HTTP更加紧凑。

CoAP协议网络运输层为UDP。

支持可靠传输，数据重传，块传输

支持IP多播, 即可以同时向多个设备发送请求

非长连接通信，适用于低功耗物联网场景。

CoAP消息类型

CON—— 需要被确认的请求，如果CON请求被发送，那么对方必须做出响应。
ACK ——应答消息，对应的是CON消息的应答。
RST —— 复位消息，可靠传输时候接收的消息不认识或错误时，不能回ACK消息，必须回RST消息。
NON—— 不需要被确认的请求，如果NON请求被发送，那么对方不必做出回应。

CoAP请求响应模型

1、携带模式。
2、分离模式。
3、非确认模式。

LwM2M

Lightweight M2M，轻量级M2M。由开发移动联盟（OMA）提出，是一种轻量级的、标准通用的物联网设备管理协议，可用于快速部署客户端/服务器模式的物联网业务。

总结对比