Mqtt协议规范
早教英文儿歌
MQTT（Message Queue Telemetry Transport），遥测传输协议，提供订阅/发布模式，更为简约、轻量，易于使⽤，针对受限环境（带宽低、⽹络延迟⾼、⽹络通信不稳定），可以简单概括为物联⽹打造，官⽅总结特点如下：
1.使⽤发布/订阅消息模式，提供⼀对多的消息发布，解除应⽤程序耦合。
2. 对负载内容屏蔽的消息传输。
3. 使⽤ TCP/IP 提供⽹络连接。
4. 有三种消息发布服务质量：
“⾄多⼀次”，消息发布完全依赖底层 TCP/IP ⽹络。会发⽣消息丢失或重复。这⼀级别可⽤于如下情况，环境传感器数据，丢失⼀次读记录⽆所谓，因为不久后还会有第⼆次发送。
“⾄少⼀次”，确保消息到达，但消息重复可能会发⽣。
“只有⼀次”，确保消息到达⼀次。这⼀级别可⽤于如下情况，在计费系统中，消息重复或丢失会导致不正确的结果。
5. ⼩型传输，开销很⼩（固定长度的头部是 2 字节），协议交换最⼩化，以降低⽹络流量。
6. 使⽤ Last Will 和 Testament 特性通知有关各⽅客户端异常中断的机制。
消息格式
⼀：固定头部
ＭＱＴＴ的消息包含着⼀个有两个字节⼤⼩的固定头部
bit76543210
byte 1Message Type DUP flag QoS level RETAIN
byte 2Remaining Length
⼆：消息类型（Message Tpe）
消息类型(4-7)，使⽤4位⼆进制表⽰，可代表16种消息类型：
Mnemonic Enumeration Description
Rerved0Rerved----保留待⽤
描述CONNECT1Client request to connect to Server----客户端连接请求
CONNACK2Connect Acknowledgment----连接反馈
PUBLISH3Publish message-----发布消息
PUBACK4Publish Acknowledgment-----发布反馈
PUBREC5Publish Received (assured delivery part 1)----发布消息被接收
PUBREL6Publish Relea (assured delivery part 2)
PUBCOMP7Publish Complete (assured delivery part 3)----发布消息完成
SUBSCRIBE8Client Subscribe request----客户端订阅
SUBACK9Subscribe Acknowledgment----订阅反馈
UNSUBSCRIBE10Client Unsubscribe request----客户端解除订阅
UNSUBACK11Unsubscribe Acknowledgment----接触订阅反馈
PINGREQ12PING Request-------⼼跳检测
PINGRESP13PING Respon----⼼跳反馈
PINGRESP13PING Respon----⼼跳反馈
DISCONNECT14Client is Disconnecting----客户端断开连接
Rerved15Rerved----保留待⽤
三：DUP flag（打开标志）
保证消息可靠传输，默认为0，只占⽤⼀个字节，表⽰第⼀次发送。不能⽤于检测消息重复发送等。只适⽤于客户端或服务器端尝试重发PUBLISH, PUBREL, SUBSCRIBE 或 UNSUBSCRIBE消息，注意需要满⾜以下条件：
当QoS > 0
消息需要回复确认
此时，在可变头部需要包含消息ID。当值为1时，表⽰当前消息先前已经被传送过。
四：QoS(Quality of Service，服务质量)
使⽤两个⼆进制表⽰PUBLISH类型消息：
QoS value bit 2bit 1Description
000⾄多⼀次发完即丢弃<=1 101⾄少⼀次需要确认回复>=1 210只有⼀次需要确认回复=1 311待⽤，保留位置
五：RETAIN(保持)
仅针对PUBLISH消息。不同值，不同含义：
1：表⽰发送的消息需要⼀直持久保存（不受服务器重启影响），不但要发送给当前的订阅者，并且以后新来的订阅了此Topic name的订阅者会马上得到推送。
备注：新来乍到的订阅者，只会取出最新的⼀个RETAIN flag = 1的消息推送。
0：仅仅为当前订阅者推送此消息。
假如服务器收到⼀个空消息体(zero-length payload)、RETAIN = 1、已存在Topic name的PUBLISH消息，服务器可以删除掉对应的已被持久化的PUBLISH消息。
六：QoS level决定的消息流challenging
QoS level为Quality of Service level的缩写，翻译成中⽂，服务质量等级。
MQTT 3.1协议在"4.1 Quality of Service levels and flows"章节中，仅仅讨论了客户端到服务器的发布流程，不太完整。因为决定消息到达率，能够提升发送质量的，应该是服务器发布PUBLISH消息到订阅者这⼀消息流⽅向。
QoS level 0
⾄多发送⼀次，发送即丢弃。没有确认消息，也不知道对⽅是否收到。
Client Message and direction Server
PUBLISH Action: Publish message to subscribers then Forget
笑对人生QoS = 0PUBLISH
-
--------->
Action: Publish message to subscribers then Forget
Reception: <=1
jillian murray针对的消息不重要，丢失也⽆所谓。
⽹络层⾯，传输压⼒⼩。
QoS level 1
所有QoS level 1都要在可变头部中附加⼀个16位的消息ID。
SUBSCRIBE和UNSUBSCRIBE消息使⽤QoS level 1。
针对消息的发布，Qos level 1，意味着消息⾄少被传输⼀次。
发送者若在⼀段时间内接收不到PUBACK消息，发送者需要打开DUB标记为1，然后重新发送PUBLISH消息。因此会导致接收⽅可能会收到两次PUBLISH消息。针对客户端发布消息到服务器的消息流：
Client Message and direction Server
QoS = 1
DUP = 0
Message ID = x Action: Store message PUBLISH
跟我来的英文
---------->
Actions:
Store message
Publish message to subscribers
Delete message
Reception: >=1
Action: Discard message PUBACK
<----------
Message ID = x
工程造价培训针对服务器发布到订阅者的消息流：
Server Message and direction Subscriber
二年级数学试题
QoS = 1
DUP = 0 Message ID = x PUBLISH
---------->rn
Actions:
Store message
Make message available
Reception: >=1
PUBACK
<----------
Message ID = x
发布者（客户端/服务器）若因种种异常接收不到PUBACK消息，会再次重新发送PUBLISH消息，同时设置DUP标记为1。接收者以服务器为例，这可能会导致服务器收到重复消息，按照流程，broker（服务器）发布消息到订阅者（会导致订阅者接收到重复消息），然后发送⼀条PUBACK确认消息到发布者。
在业务层⾯，或许可以弥补MQTT协议的不⾜之处：重试的消息ID⼀定要⼀致接收⽅⼀定判断当前接收的消息ID是否已经接受过
但⼀样不能够完全确保，消息⼀定到达了。
QoS level 2
仅仅在PUBLISH类型消息中出现，要求在可变头部中要附加消息ID。
级别⾼，通信压⼒稍⼤些，但确保了仅仅传输接收⼀次。
先看协议中流程图，Client -> Server⽅向，会有⼀个总体印象：
Client Message and direction Server
QoS = 2
DUP = 0
Message ID = x Action: Store message PUBLISH
---------->ctc
Action(a) Store message
or
Actions(b):
Store message ID
