MQTT 是一个客户端-服务器发布/订阅消息传输协议. 它轻量，开放，简单, 并易于实现.这些特性，使它在许多情况下适合使用, 包括受限的环境中,如机器对机器(M2M)之间通信和物联网(IoT)环境中,需要体积小的代码和/或网络带宽是昂贵的。
此协议运行于TCP/IP以上, 或在其他网络协议，提供有序、 无损、 双向网络连接. 它的功能包括:
· 使用发布/订阅消息模式提供一个一对多的消息分发,解除了应用程序之间的耦合。
· 对负载内容屏蔽的消息传输。
· 有三种消息传递服务质量 ：
· "At most once", 至多一次”,消息传送根据操作环境的最好状态。会发生消息丢失。 这一级别可用于如下情况,如环境传感器数据,这种情况下,丢失一次读记录无所谓,因为第二个 数据的发布紧跟其后。
· "At least once" “至少一次”,确保消息到达,但可能发生消息重复。
· "Exactly once", “只有一次”,确保消息只到达一次。这一级别可用于如下情况,如计费系统中,消息重复或丢失会导致不正确的收费问题。
· 小型传输,开销很小,协议交换最小化,以减少网络流量。
· 提供一种机制,使得发生异常中断时,能够通知有关各方 。
Terminology（术语）
Network Connection:（网络连接）
MQTT使用的底层传输协议所提供的概念
· 它将客户端连接到服务器。
· 它提供发送有序、无损、双向的字节流方法。
Application Message:（应用程序消息）
MQTT协议通过网络为应用程序携带的数据。 当应用程序消息通过 MQTT 传输他们有关联的服务质量和主题名称。
Client:（客户端）
使用 MQTT 的程序或设备。客户端总是建立到服务器的网络连接。它能
· 发布其他客户端可能会感兴趣的应用程序消息。
· 订阅它感兴趣的应用程序消息。
· 取消订阅应用程序消息。
· 从服务器断开连接。
Server:（服务器）
一个在发布应用程序消息的客户端和订阅的客户端之间充当中介的程序或设备。一个服务器：
· 从客户端接受网络连接。
· 接受由客户端发布的应用程序消息。
· 处理来自客户端的订阅和取消订阅请求
· 转发匹配客户端订阅的应用程序消息。
Subscription:（订阅）
订阅包括主题筛选器和最大的 QoS。订阅与单个会话相关联。一个会话可以包含多个订阅。会话中的每个订阅具有一个不同的主题筛选器。
Topic Name:（主题名）
附加到服务器已知的与订阅相匹配的应用程序的标签，服务器将应用程序消息的副本发送到具有匹配订阅的每个客户端。
Topic Filter:（主题过滤器）
包含在订阅中的表达式，来表示一个或多个感兴趣的话题。主题筛选器可以包含通配符字符。
Session:（会话）
客户端和服务器之间的状态交互。一些会话维持只要网络连接，其他的可以跨越多个连续的客户端和服务器之间的网络连接。
MQTT Control Packet:（MQTT 控制包）
在网络连接上发送的信息包。MQTT 规范定义了十四个不同类型的控制包，其中之一 （PUBLISH packet发布包） 用来发送应用程序消息。
MQTT 14个控制包
/*
RESERVED = 0x00 保留
CONNECT = 0x01 连接请求:客户端请求连接到服务器
CONACK = 0x02 连接确认
PUBLISH = 0x03 发布消息
PUBACK = 0x04 发布确认
PUBREC = 0x05 发布信息收到(确保分发的第1部分)
PUBREL = 0x06 发布信息分发(确保分发的第2部分);
PUBCOMP = 0x07 发布完成(确保分发的第3部分);
SUBSCRIBE = 0x08 客户端订阅请求
SUBACK = 0x09 订阅确认
UNSUBSCRIBE = 0x0a 客户端取消订阅请求
UNSUBACK = 0x0b 取消订阅确认
PINGREQ = 0x0c ping请求
PINGRESP = 0x0d ping响应
DISCONNECT = 0x0e 客户端正在断开连接
RESERVED = 0x0f 保留
*/
Wills 针对连接
//定义了客户端（没有主动发送DISCONNECT消息）出现网络异常导致连接中断的情况下，服务器需要做的一些措施。
每个客户端都要订阅一个 遗嘱消息 ,如客户端 1,订阅last will 主题为qq/1 ,如客户端 2,订阅last will 主题为qq/2;接收客户端
订阅last will 主题为qq/#,就能接收到所有客户端的非正常断开. 要和retain消息一起使用,以便存储客户端状态.
Will Message会在某些情况下发布，包括但不限于：
- 服务端发现I/O错误或网络失败。
- 客户端在Keep Alive时间内通信失败。
- 客户端没有发送DISCONNECT包就关闭了网络连接。
- 服务端因协议错误关闭了网络连接。
更多更看这里http://www.hivemq.com/mqtt-essentials-part-9-last-will-and-testament/
Clean Session 持久连接 针对连接 (qos1 &qos2 设为0) （）
//0，表示如果订阅的客户机断线了，要保存为其要推送的消息（QoS为1和QoS为2），若其重新连接时，需将这些消息推送（若客户端长时间不连接，需要设置一个过期值）。 1，断线服务器即清理相关信息，重新连接上来之后，会再次订阅。
通常，客户端应该一直使用CleanSession 0或一直使用CleanSession 1来建立连接，而不要切换来切换去。选择哪个由应用程序决定。使用CleanSession 1的客户端不会收到旧的应用消息，而且每次连接都要重新订阅感兴趣的话题。客户端使用CleanSession 0会收到上次短线之后的QoS 1和QoS 2的消息。因此，为了确保消息不会再断线时丢失，使用QoS 1或QoS 2并把CleanSession设为0
/*
Clean Session
Position: bit 1 of the Connect Flags byte.
This bit specifies the handling of the Session state.
The Client and Server can store Session state to enable reliable messaging to continue across a sequence of Network Connections. This bit is used to control the lifetime of the Session state.
If CleanSession is set to 0, the Server MUST resume communications with the Client based on state from the current Session (as identified by the Client identifier). If there is no Session associated with the Client identifier the Server MUST create a new Session. The Client and Server MUST store the Session after the Client and Server are disconnected [MQTT-3.1.2-4]. After the disconnection of a Session that had CleanSession set to 0, the Server MUST store further QoS 1 and QoS 2 messages that match any subscriptions that the client had at the time of disconnection as part of the Session state [MQTT-3.1.2-5]. It MAY also store QoS 0 messages that meet the same criteria.
If CleanSession is set to 1, the Client and Server MUST discard any previous Session and start a new one. This Session lasts as long as the Network Connection. State data associated with this Session MUST NOT be reused in any subsequent Session [MQTT-3.1.2-6].
The Session state in the Client consists of:
· QoS 1 and QoS 2 messages which have been sent to the Server, but have not been completely acknowledged.
· QoS 2 messages which have been received from the Server, but have not been completely acknowledged.
The Session state in the Server consists of:
· The existence of a Session, even if the rest of the Session state is empty.
· The Client’s subscriptions.
· QoS 1 and QoS 2 messages which have been sent to the Client, but have not been completely acknowledged.
· QoS 1 and QoS 2 messages pending transmission to the Client.
· QoS 2 messages which have been received from the Client, but have not been completely acknowledged.
· Optionally, QoS 0 messages pending transmission to the Client.
Retained messages do not form part of the Session state in the Server, they MUST NOT be deleted when the Session ends [MQTT-3.1.2.7].
See Section 4.1 for details and limitations of stored state.
When CleanSession is set to 1 the Client and Server need not process the deletion of state atomically.
Non normative comment
To ensure consistent state in the event of a failure, the Client should repeat its attempts to connect with CleanSession set to 1, until it connects successfully.
Non normative comment
Typically, a Client will always connect using CleanSession set to 0 or CleanSession set to 1 and not swap between the two values. The choice will depend on the application. A Client using CleanSession set to 1 will not receive old Application Messages and has to subscribe afresh to any topics that it is interested in each time it connects. A Client using CleanSession set to 0 will receive all QoS 1 or QoS 2 messages that were published while it was disconnected. Hence, to ensure that you do not lose messages while disconnected, use QoS 1 or QoS 2 with CleanSession set to 0.
Non normative comment
When a Client connects with CleanSession set to 0, it is requesting that the Server maintain its MQTT session state after it disconnects. Clients should only connect with CleanSession set to 0, if they intend to reconnect to the Server at some later point in time. When a Client has determined that it has no further use for the session it should do a final connect with CleanSession set to 1 and then disconnect.
RETAIN(保持) 针对发布
* 仅针对PUBLISH消息。不同值，不同含义：
1：表示发送的消息需要一直持久保存（不受服务器重启影响），不但要发送给当前的订阅者，并且以后新来的订阅了此Topic name的订阅者会马上得到推送。
备注：新来乍到的订阅者，只会取出最新的一个RETAIN flag = 1的消息推送。
0：仅仅为当前订阅者推送此消息。
假如服务器收到一个空消息体(zero-length payload)、RETAIN = 1、已存在Topic name的PUBLISH消息，服务器可以删除掉对应的已被持久化的PUBLISH消息。*/
Position: byte 1, bit 0.
If the RETAIN flag is set to 1, in a PUBLISH Packet sent by a Client to a Server, the Server MUST store the Application Message and its QoS, so that it can be delivered to future subscribers whose subscriptions match its topic name[MQTT-3.3.1-5]. When a new subscription is established, the last retained message, if any, on each matching topic name MUST be sent to the subscriber [MQTT-3.3.1-6]. If the Server receives a QoS 0 message with the RETAIN flag set to 1 it MUST discard any message previously retained for that topic. It SHOULD store the new QoS 0 message as the new retained message for that topic, but MAY choose to discard it at any time - if this happens there will be no retained message for that topic [MQTT-3.3.1-7]. See Section 4.1 for more information on storing state.
When sending a PUBLISH Packet to a Client the Server MUST set the RETAIN flag to 1 if a message is sent as a result of a new subscription being made by a Client [MQTT-3.3.1-8]. It MUST set the RETAIN flag to 0 when a PUBLISH Packet is sent to a Client because it matches an established subscription regardless of how the flag was set in the message it received [MQTT-3.3.1-9].
A PUBLISH Packet with a RETAIN flag set to 1 and a payload containing zero bytes will be processed as normal by the Server and sent to Clients with a subscription matching the topic name. Additionally any existing retained message with the same topic name MUST be removed and any future subscribers for the topic will not receive a retained message [MQTT-3.3.1-10]. “As normal” means that the RETAIN flag is not set in the message received by existing Clients. A zero byte retained message MUST NOT be stored as a retained message on the Server [MQTT-3.3.1-11].
If the RETAIN flag is 0, in a PUBLISH Packet sent by a Client to a Server, the Server MUST NOT store the message and MUST NOT remove or replace any existing retained message [MQTT-3.3.1-12].
Non normative comment
Retained messages are useful where publishers send state messages on an irregular basis. A new subscriber will receive the most recent state.
QoS 针对发布者和订阅者
转载请注明：来自Lenix的博客 http://blog.p2hp.com/ http://blog.p2hp.com/archives/1528
最后更新于 2021年6月28日
