什么是 MQTT 协议
MQTT 全称(Message Queue Telemetry Transport)：一种基于发布/订阅（publish/subscribe）模式的轻量级通讯协议，通过订阅相应的主题来获取消息，是物联网（Internet of Thing）中的一个标准传输协议。
该协议将消息的发布者（publisher）与订阅者（subscriber）进行分离，因此可以在不可靠的网络环境中，为远程连接的设备提供可靠的消息服务，使用方式与传统的MQ有点类似。
TCP协议位于传输层，MQTT 协议位于应用层，MQTT 协议构建于TCP/IP协议上，也就是说只要支持TCP/IP协议栈的地方，都可以使用MQTT协议。
为什么要用 MQTT协议？
MQTT协议为什么在物联网（IOT）中如此受偏爱？而不是其它协议，比如我们更为熟悉的 HTTP协议呢？
- 首先HTTP协议它是一种同步协议，客户端请求后需要等待服务器的响应。而在物联网（IOT）环境中，设备会很受制于环境的影响，比如带宽低、网络延迟高、网络通信不稳定等，显然异步消息协议更为适合IOT应用程序。
- HTTP是单向的，如果要获取消息客户端必须发起连接，而在物联网（IOT）应用程序中，设备或传感器往往都是客户端，这意味着它们无法被动地接收来自网络的命令。
- 通常需要将一条命令或者消息，发送到网络上的所有设备上。HTTP要实现这样的功能不但很困难，而且成本极高。
特性
MQTT协议工作在低带宽、不可靠的网络的远程传感器和控制设备通讯而设计的协议，它具有以下主要的几项特性：
（1）使用发布/订阅消息模式，提供一对多的消息发布，解除应用程序耦合。
（2）对负载内容屏蔽的消息传输。
（3）使用TCP/IP提供网络连接。
主流的MQTT是基于TCP连接进行数据推送的，但是同样有基于UDP的版本，叫做MQTT-SN。这两种版本由于基于不同的连接方式，优缺点自然也就各有不同了。
（4）有三种消息发布服务质量：
“至多一次”，消息发布完全依赖底层TCP/IP网络。会发生消息丢失或重复。这一级别可用于如下情况，环境传感器数据，丢失一次读记录无所谓，因为不久后还会有第二次发送。这一种方式主要普通APP的推送，倘若你的智能设备在消息推送时未联网，推送过去没收到，再次联网也就收不到了。
“至少一次”，确保消息到达，但消息重复可能会发生。
“只有一次”，确保消息到达一次。在一些要求比较严格的计费系统中，可以使用此级别。在计费系统中，消息重复或丢失会导致不正确的结果。这种最高质量的消息发布服务还可以用于即时通讯类的APP的推送，确保用户收到且只会收到一次。
（5）小型传输，开销很小（固定长度的头部是2字节），协议交换最小化，以降低网络流量。
这就是为什么在介绍里说它非常适合“在物联网领域，传感器与服务器的通信，信息的收集”，要知道嵌入式设备的运算能力和带宽都相对薄弱，使用这种协议来传递消息再适合不过了。
（6）使用Last Will和Testament特性通知有关各方客户端异常中断的机制。
Last Will：即遗言机制，用于通知同一主题下的其他设备发送遗言的设备已经断开了连接。
Testament：遗嘱机制，功能类似于Last Will。
MQTT协议原理
MQTT协议实现方式
实现MQTT协议需要客户端和服务器端通讯完成，在通讯过程中，MQTT协议中有三种身份：发布者（Publish）、代理（Broker）（服务器）、订阅者（Subscribe）。其中，消息的发布者和订阅者都是客户端，消息代理是服务器，消息发布者可以同时是订阅者。
MQTT传输的消息分为：主题（Topic）和负载（payload）两部分：
（1）Topic，可以理解为消息的类型，订阅者订阅（Subscribe）后，就会收到该主题的消息内容（payload）；
（2）payload，可以理解为消息的内容，是指订阅者具体要使用的内容。
网络传输与应用消息
MQTT会构建底层网络传输：它将建立客户端到服务器的连接，提供两者之间的一个有序的、无损的、基于字节流的双向传输。
当应用数据通过MQTT网络发送时，MQTT会把与之相关的服务质量（QoS）和主题名（Topic）相关连。
MQTT客户端
一个使用MQTT协议的应用程序或者设备，它总是建立到服务器的网络连接。客户端可以：
（1）发布其他客户端可能会订阅的信息；
（2）订阅其它客户端发布的消息；
（3）退订或删除应用程序的消息；
（4）断开与服务器连接。
MQTT服务器
MQTT服务器以称为"消息代理"（Broker），可以是一个应用程序或一台设备。它是位于消息发布者和订阅者之间，它可以：
（1）接受来自客户的网络连接；
（2）接受客户发布的应用信息；
（3）处理来自客户端的订阅和退订请求；
（4）向订阅的客户转发应用程序消息。
MQTT协议中的订阅、主题、会话
一、订阅（Subscription）
订阅包含主题筛选器（Topic Filter）和最大服务质量（QoS）。订阅会与一个会话（Session）关联。一个会话可以包含多个订阅。每一个会话中的每个订阅都有一个不同的主题筛选器。
二、会话（Session）
每个客户端与服务器建立连接后就是一个会话，客户端和服务器之间有状态交互。会话存在于一个网络之间，也可能在客户端和服务器之间跨越多个连续的网络连接。
三、主题名（Topic Name）
连接到一个应用程序消息的标签，该标签与服务器的订阅相匹配。服务器会将消息发送给订阅所匹配标签的每个客户端。
四、主题筛选器（Topic Filter）
一个对主题名通配符筛选器，在订阅表达式中使用，表示订阅所匹配到的多个主题。
五、负载（Payload）
消息订阅者所具体接收的内容。
MQTT协议中的方法
MQTT协议中定义了一些方法（也被称为动作），来于表示对确定资源所进行操作。这个资源可以代表预先存在的数据或动态生成数据，这取决于服务器的实现。通常来说，资源指服务器上的文件或输出。主要方法有：
（1）Connect。等待与服务器建立连接。
（2）Disconnect。等待MQTT客户端完成所做的工作，并与服务器断开TCP/IP会话。
（3）Subscribe。等待完成订阅。
（4）UnSubscribe。等待服务器取消客户端的一个或多个topics订阅。
（5）Publish。MQTT客户端发送消息请求，发送完成后返回应用程序线程。
MQTT协议数据包结构
前边说过MQTT是一种轻量级的协议，它只专注于发消息， 所以此协议的结构也非常简单。
MQTT数据包
在MQTT协议中，一个MQTT数据包由：固定头（Fixed header）、 可变头（Variable header）、 消息体（payload）三部分构成。
固定头（Fixed header），所有数据包中都有固定头，包含数据包类型及数据包的分组标识。
可变头（Variable header），部分数据包类型中有可变头。
内容消息体（Payload），存在于部分数据包类，是客户端收到的具体消息内容。
固定头
固定头部，使用两个字节，共16位：
固定头存在于所有MQTT数据包中，其结构如下：
|
Bit |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
byte 1 |
MQTT数据包类型 |
DUP flag |
Qos Level |
Retain |
||||
|
byte 2… |
剩余长度 |
|||||||
MQTT数据包类型
位置：byte 1, bits 7-4。
相于一个4位的无符号值，类型如下：
|
名称 |
值 |
流方向 |
描述 |
|
Reserved |
0 |
不可用 |
保留位 |
|
CONNECT |
1 |
客户端到服务器 |
客户端请求连接到服务器 |
|
CONNACK |
2 |
服务器到客户端 |
连接确认 |
|
PUBLISH |
3 |
双向 |
发布消息 |
|
PUBACK |
4 |
双向 |
发布确认 |
|
PUBREC |
5 |
双向 |
发布收到（保证第1部分到达） |
|
PUBREL |
6 |
双赂 |
发布释放（保证第2部分到达） |
|
PUBCOMP |
7 |
双向 |
发布完成（保证第3部分到达） |
|
SUBSCRIBE |
8 |
客户端到服务器 |
客户端请求订阅 |
|
SUBACK |
9 |
服务器到客户端 |
订阅确认 |
|
UNSUBSCRIBE |
10 |
客户端到服务器 |
请求取消订阅 |
|
UNSUBACK |
11 |
服务器到客户端 |
取消订阅确认 |
|
PINGREQ |
12 |
客户端到服务器 |
PING请求 |
|
PINGRESP |
13 |
服务器到客户端 |
PING应答 |
|
DISCONNECT |
14 |
客户端到服务器 |
中断连接 |
|
Reserved |
15 |
不可用 |
保留位 |
标识位
位置：byte 1, bits 3-0。
在不使用标识位的消息类型中，标识位被做为保留位。如果收到无效的标志时，接收端必须关闭网络连接：
DUP Flag（重试标识）
DUP：发布消息的副本。用来在保证消息的可靠传输，如果设置为 1，则在下面的变长中增加MessageId，并且需要回复确认，以保证消息传输完成，但不能用于检测消息重复发送。
QoS Level（消息质量等级）
QoS：发布消息的服务质量，即：保证消息传递的次数
00：最多一次，即：<=1
01：至少一次，即：>=1
10：一次，即：=1
11：预留
RETAIN（持久化）
值为1：表示发送的消息需要一直持久保存，而且不受服务器重启影响，不但要发送给当前的订阅者，且以后新加入的客户端订阅了此Topic，订阅者也会马上得到推送。 注意：新加入的订阅者，只会取出最新的一个RETAIN flag = 1的消息推送。
值为0：仅为当前订阅者推送此消息。
Remaining Length（剩余长度）
在当前消息中剩余的byte(字节)数，包含可变头部和消息体payload。
2、可变头
|
Bit |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
byte 1 |
包标签符（MSB） |
|||||||
|
byte 2… |
包标签符（LSB） |
|||||||
固定头部仅定义了消息类型和一些标志位，一些消息的元数据需要放入可变头部中。可变头部内容字节长度 + 消息体payload = 剩余长度。
可变头部居于固定头部和payload中间，包含了协议名称，版本号，连接标志，用户授权，心跳时间等内容。
可变头存在于这些类型的消息：PUBLISH (QoS > 0)、PUBACK、PUBREC、PUBREL、PUBCOMP、SUBSCRIBE、SUBACK、UNSUBSCRIBE、UNSUBACK。
3、消息体payload
消息体payload只存在于CONNECT、PUBLISH、SUBSCRIBE、SUBACK、UNSUBSCRIBE这几种类型的消息：
CONNECT：包含客户端的ClientId、订阅的Topic、Message以及用户名和密码。
PUBLISH：向对应主题发送消息。
SUBSCRIBE：要订阅的主题以及QoS。
SUBACK：服务器对于SUBSCRIBE所申请的主题及QoS进行确认和回复。
UNSUBSCRIBE：取消要订阅的主题。
消息质量（QoS ）
消息质量（Quality of Service），即消息的发送质量，发布者（publisher）和订阅者（subscriber）都可以指定qos等级，有QoS 0、QoS 1、QoS 2三个等级。
边分别说明一下这三个等级的区别。
1、Qos 0：At most once（至多一次），只发送一次消息，不保证消息是否成功送达，没有确认机制，消息可能会丢失或重复。
2、Qos 1：At least once（至少一次），相对于QoS 0而言Qos 1增加了ack确认机制，发送者（publisher）推送消息到MQTT代理（broker）时，两者自身都会先持久化消息，只有当publisher 或者 Broker分别收到 PUBACK确认时，才会删除自身持久化的消息，否则就会重发。
但有个问题，尽管我们可以通过确认来保证一定收到客户端 或 服务器的message，可我们却不能保证仅收到一次message，也就是当客户端publisher没收到Broker的puback或者 Broker没有收到subscriber的puback，那么就会一直重发。
publisher -> broker 大致流程：
publisher store msg -> publish ->broker （传递message）
broker -> puback -> publisher delete msg （确认传递成功）
3、Qos 2：Exactly once（只有一次），相对于QoS 1，QoS 2升级实现了仅接受一次message，publisher 和 broker 同样对消息进行持久化，其中 publisher 缓存了message和 对应的msgID，而 broker 缓存了 msgID，可以保证消息不重复，由于又增加了一个confirm 机制，整个流程变得复杂很多。
publisher -> broker 大致流程：
publisher store msg -> publish ->broker -> broker store
msgID（传递message） broker -> puberc （确认传递成功）
publisher -> pubrel ->broker delete msgID （告诉broker删除msgID）
broker -> pubcomp -> publisher delete msg （告诉publisher删除msg）
LWT（最后遗嘱）
LWT 全称为 Last Will and Testament，其实遗嘱是一个由客户端预先定义好的主题和对应消息，附加在CONNECT的数据包中，包括遗愿主题、遗愿 QoS、遗愿消息等。
当MQTT代理 Broker 检测到有客户端client非正常断开连接时，再由服务器主动发布此消息，然后相关的订阅者会收到消息。
举个栗子：聊天室中所有人都订阅一个叫talk的主题 ，但小富由于网络抖动突然断开了链接，这时聊天室中所有订阅主题 talk的客户端都会收到一个 “小富离开聊天室” 的遗愿消息。
遗嘱的相关参数：
Will Flag：是否使用 LWT，1 开启
Will Topic：遗愿主题名，不可使用通配符
Will Qos：发布遗愿消息时使用的 QoS
Will Retain：遗愿消息的 Retain 标识
Will Message：遗愿消息内容
那客户端Client 有哪些场景是非正常断开连接呢？
Broker 检测到底层的 I/O 异常；
客户端 未能在心跳 Keep Alive 的间隔内和 Broker 进行消息交互；
客户端 在关闭底层 TCP 连接前没有发送 DISCONNECT 数据包；
客户端 发送错误格式的数据包到 Broker，导致关闭和客户端的连接等。
注意：当客户端通过发布 DISCONNECT 数据包断开连接时，属于正常断开连接，并不会触发 LWT 的机制，与此同时Broker 还会丢弃掉当前客户端在连接时指定的相关 LWT 参数。
MQTT协议应用场景
MQTT协议广泛应用于物联网、移动互联网、智能硬件、车联网、电力能源等领域。使用的场景也是非常非常多，下边列举一些：
物联网M2M通信，物联网大数据采集
Android消息推送，WEB消息推送
移动即时消息，例如Facebook Messenger
智能硬件、智能家具、智能电器
车联网通信，电动车站桩采集
智慧城市、远程医疗、远程教育
电力、石油与能源等行业市场