序言
MQTT协议是当今世界上最受欢迎的物联网协议。它已广泛应用于车联网、智能家居、即时聊天应用和工业互联网等领域。目前通过MQTT协议连接的设备已经过亿，这些都得益于MQTT 协议为设备提供了稳定、可靠、易用的通信基础。本篇将从最基础的知识开始，向您讲解MQTT协议的应用。通过本篇的学习，您将学会MQTT协议开发物联网项目。
MQTT是什么
MQTT是一个客户端服务端架构的发布/订阅模式的消息传输协议。它的设计思想是轻巧、开放、简单、规范，易于实现。这些特点使得它对很多场景来说都是很好的选择，特别是对于受限的环境如机器与机器的通信（M2M）以及物联网环境（IoT）。
以上MQTT（消息队列遥测传输）协议规范中的介绍很好地描述了MQTT的全部含义。它是一种很轻的通讯协议。与HTTP之类的协议相比，MQTT在通过网络传输数据时表现出众。该协议的另一个重要特点是易于在客户端实现。因此，MQTT成为了当今世界上最受欢迎的物联网协议。它已广泛应用于车联网、智能家居、即时聊天应用和工业互联网等领域。目前通过MQTT协议连接的设备已经过亿，这些都得益于MQTT 协议为设备提供了稳定、可靠、易用的通信基础。
MQTT历史
MQTT协议最初版本是在1999年建立的。该协议的发明人是的Andy Stanford-Clark和Arlen Nipper。
MQTT协议发明人之一Andy-Stanford-Clark
MQTT协议发明人之一Arlen Nipper
他们当时正在开发一个利用卫星通讯监控输油管道的项目。为了实现这个项目要求，他们需要开发一种用于嵌入式设备的通讯协议，这种通讯协议必须满足以下条件：
- 易于实现
- 数据传输的服务质量可控
- 占用带宽小
- 传输数据内容不可预知
- 设备连接状态可知
从以上几点不难看出，MQTT 从诞生之初就是专为低带宽、高延迟或不可靠的网络而设计的。虽然历经几十年的更新和变化，以上这些特点仍然是MQTT协议的核心特点。但是与最初不同的是，MQTT协议已经从嵌入式系统应用拓展到开放的物联网（IoT）领域。
OASIS标准
2014年10月29日，MQTT成为OASIS（结构化信息标准促进组织）正式批准的通讯标准。OASIS是一个推进电子商务标准的发展、融合与采纳的非盈利性国际化组织。相比其他组织，OASIS形成了Web服务标准的同时也提出了安全的电子商务标准，同时在针对公众领域和特定应用市场的标准化方面也付出很多的努力。自1993年成立开始，OASIS已经发展成为了由来自100多个国家的600多家组织、企业。简言之，由众多业内专家组成的OASIS愿意为MQTT背书，组件该协议在物联网领域的重要性。
MQTT版本
目前MQTT主流版本有两个，分别是MQTT3.1.1和MQTT5。MQTT3.1.1是在2014年10月发布的，而MQTT5是在2019年3月发布的。由于MQTT3.1.1与MQTT5的时间相差了将近五年，且MQTT5的发布时间距今不久，因此在本文书写时（2020年10月），MQTT3.1.1仍然主流版本。
MQTT5是在MQTT3.1.1的基础上进行了升级。因此MQTT5是完全兼容MQTT3.1.1的。 而MQTT5是在MQTT3.1.1的基础上添加了更多的功能补充完善MQTT协议。
本教程将会重点针对MQTT3.1.1进行介绍，这么做有几点原因：
- MQTT3.1.1是MQTT5的基础，因此掌握了MQTT3.1.1后可以通过进一步学习掌握MQTT5的使用。
- 当前多种流行编程语言的MQTT客户端库仍然只支持MQTT3.1.1，而不支持MQTT5。
- 目前物联网环境中的大量设备仍然使用MQTT3.1.1协议而不支持MQTT5协议。
基于以上几点原因，本教程将以MQTT3.1.1作为重点讲解。毕竟掌握了MQTT3.1.1，对于学习MQTT5是没有任何浪费的。学会MQTT3.1.1后，如果想要使用MQTT5。那么无需重新学习MQTT5，而只要利用MQTT3.1.1的基础再学习MQTT5的新功能就可以了。
MQTT基本原理
在MQTT协议通讯中，有两个最为重要的角色。它们分别是服务端和客户端。 首先我们来初步了解一下它们。
MQTT服务端
MQTT服务端通常是一台服务器。它是MQTT信息传输的枢纽，负责将MQTT客户端发送来的信息传递给MQTT客户端。MQTT服务端还负责管理MQTT客户端。确保客户端之间的通讯顺畅，保证MQTT消息得以正确接收和准确投递。
MQTT客户端
MQTT客户端可以向服务端发布信息，也可以从服务端收取信息。我们把客户端发送信息的行为成为“发布”信息。而客户端要想从服务端收取信息，则首先要向服务端“订阅”信息。“订阅”信息这一操作很像我们在视频网站订阅某一部电视剧。当这部电视剧上新后，视频网站会向订阅了该剧的用户发送信息，告诉他们有新剧上线了。
MQTT主题
刚刚我们在讲解MQTT客户端订阅信息时，使用了用户在视频网站订阅电视剧这个例子。在MQTT通讯中，客户端所订阅的肯定不是一部部电视剧，而是一个个“主题”。MQTT服务端在管理MQTT信息通讯时，就是使用“主题”来控制的。
为了便于您更好理解服务端是如何通过主题来控制客户端之间的信息通讯，我们来看看下图实例：
MQTT通讯实例-1
在以上图示中一共有三个MQTT客户端。它们分别是汽车，手机和电脑。MQTT服务端在管理MQTT通讯时使用了“主题”来对信息进行管理的。比如上图所示，假设我们需要利用手机和电脑获取汽车的速度，那么我们首先要利用电脑和手机向MQTT服务器订阅主题“汽车速度”。接下来，当汽车客户端向服务端的“汽车速度”主题发布信息后，服务端就会首先检查以下都有哪些客户端订阅了“汽车速度”这一主题的信息。当它发现订阅了该主题的客户端有一个手机和一个电脑，于是服务端就会将刚刚收到的“汽车速度”信息转发给订阅了该主题的手机和电脑客户端。
在以上实例中，汽车是“汽车速度”主题的发布者，而手机和电脑则是该主题的订阅者。
值得注意的是，MQTT客户端在通讯时，往往角色不是单一的。它既可以作为信息发布者也可以同时作为信息订阅者。如下图所示：
MQTT通讯实例-2
上图中的所有客户端都是围绕“空调温度”这一主题进行通讯的。对于“空调温度”这一主题，手机和电脑客户端成为了MQTT信息的发布者而汽车则成为了MQTT信息的订阅者（接收者）。
可以看到，针对不同的主题，MQTT客户端可以切换自己的角色。它们可能对主题A来说是信息发布者，但是对于主题B就成了信息订阅者。
MQTT 发布/订阅 特性
从以上实例我们可以看到，MQTT通讯的核心枢纽是MQTT服务端。有了服务端对MQTT信息的接收、储存、处理和发送，客户端在发布和订阅信息时，可以相互独立，且在空间上可以分离，时间上可以异步。这里所说的相互独立、空间和时间分离具体指的是什么呢？
- 相互可独立：MQTT客户端是一个个独立的个体。它们无需了解彼此的存在，依然可以实现信息交流。比如以上实例中汽车客户端在发布“汽车速度”信息时，汽车客户端本身可以完全不知道有多少个MQTT客户端订阅了“汽车速度”这一主题。而订阅了“汽车速度”主题的手机和电脑客户端也完全不知道彼此的存在。大家只要订阅了“汽车速度”主题，MQTT服务端就会在每次收到新信息时，将信息发送给订阅了“汽车速度”主题的客户端。
- 空间可分离：空间分离相对容易理解，MQTT客户端在通讯必要条件是连接到了同一个MQTT通讯网络。这个网络可以是互联网或者局域网。只要客户端联网，无论他们远在天边还是近在眼前，都可以实现彼此间的通讯交流。
- 时间可异步：MQTT客户端在发送和接收信息时无需同步。这一特点对物联网设备尤为重要。有时物联网设备会发生意外离线的情况。我们使用以上实例二的场景来作为示例。当我们的汽车在行驶过程中，可能会突然进入隧道，这时汽车可能会断开与MQTT服务端的连接。假设在此时我们的手机客户端向汽车客户端所订阅的“空调温度”主题发布了信息，而汽车恰恰不在线。这时，MQTT服务端可以将“空调温度”主题的新信息保存，待汽车再次上线后，服务端再将“空调温度”信息推送给汽车。
以上几点概括了MQTT通讯时客户端的相互关系以及服务端在其中所起的作用。讲到这里请您注意：以上总结的几个特点中都有一个“可”字。这个“可”字意味着客户端彼此之间可以独立，空间可以分离，时间可以异步。在我们实际应用中，客户端之间的关系既可以独立也可以相互依存。在空间上，既可以相距甚远，也可以彼此相邻。在时间上，既可以异步也可以同步。这个“可”字所体现的是MQTT通讯的灵活性。
可能有些朋友看过以上文字后感觉有些抽象。毕竟这些都是纯理论知识，在后面的教程里，我们将通过实例向您讲解MQTT的应用，届时相信您会对MQTT有深切的认识。到这里，请您务必留意MQTT通讯的三个特点，彼此可独立，空间可分离、时间可异步。
MQTT客户端之间要想实现通讯，必须要通过MQTT服务端。因此MQTT客户端无论是发布消息还是订阅消息，首先都要连接MQTT服务端。下面我们看一下MQTT客户端连接服务端的详细过程。
MQTT客户端连接服务端一共有两步。
-
首先MQTT客户端将会向服务端发送连接请求。该请求实际上是一个包含有连接请求信息的数据包。这个数据包的官方名称为
CONNECT
-
MQTT服务端收到客户端连接请求后，会向客户端发送连接确认。同样的，该确认也是一个数据包。这个数据包官方名称为
CONNACK
以上就是MQTT客户端在连接服务端的两步操作。接下来，我们一起来了解一下客户端在连接服务端时所发送的CONNECT报文内容。
CONNECT – 连接服务端
在上面的描述中我们看到。MQTT客户端要想连接服务端，首先要向服务端发送CONNECT报文。如果此CONNECT报文的格式或内容不符合MQTT规范，则服务器会拒绝客户端的连接请求。
下图是CONNECT报文所包含的信息内容。
在接下来的课程讲解中我们将会频繁接触到两个概念。第一个概念是报文，第二个概念是信息。
所谓报文就是一个MQTT数据包。这个数据包中可能包含有多个信息。比如以上图片就是描绘了一个CONNECT报文（数据包）的详细内容。
在这个CONNECT报文（数据包）中包含有多个信息。上图左侧栏中的内容是CONNECT报文所包含的信息名称。右侧是信息的具体内容。如上图示例中，此CONNECT报文包含有名称为clientId的信息，该信息的内容是”client-1″。当然，上图只是一个示例，不是所有的CONNECT报文中的clientId信息内容都是”client-1″。
另外也请注意，上图中有些信息名称旁边标注了“可选”字样，而有些则没有。那些没有标注“可选”字样的信息是必须包含在CONNECT报文中的。而对于标注了“可选”字样的信息，CONNECT报文既可以包含它们也可以没有它们。
考虑到我们刚刚开始接触MQTT协议，目前我们先从最基础的内容开始学起。那么在本节课程里，我们只讲解未标注“可选”字样的信息以及它们的功能。在后续的课程里，我们会详细讲解标有“可选”字样的信息。
clientId – 客户端ID
ClientId是MQTT客户端的标识。MQTT服务端用该标识来识别客户端。因此ClientId必须是独立的。如果两个MQTT客户端使用相同ClientId标识，服务端会把它们当成同一个客户端来处理。通常ClientId是由一串字符所构成的，如上图所示，此示例中的clientID是“client-1”。
cleanSession – 清除会话
所谓“清除会话”这一翻译源自MQTT官方文档中文版。要说明cleanSession的具体含义，首先要从MQTT网络环境讲起。
MQTT客户端与服务端的连接可能不是非常稳定，在不稳定的网络环境下，要想保证所有信息传输都能够做到准确无误，这是非常困难的。因此，我们就要根据客户端对系统运行的重要性来区别对待。
有些MQTT客户端对整个系统运行起着关键作用，这些客户端一定要准确无误的收到服务端发来的报文。比如一辆自动驾驶汽车的导航系统。假如这个导航系统错过了服务端发来的报文，可能会导致交通事故甚至人员伤亡。因此，即使网络不是非常稳定，我们仍然要求汽车导航系统一定要准确无误的收到服务端所发来的报文。
但是有些MQTT客户端对整个系统运行并不是很重要。比如同样是这辆自动驾驶汽车。它的音乐播放系统如果没有及时收到服务端发来的音乐播放报文，这对驾驶系统来说影响不大。
以上所举的两个例子说明，MQTT通讯中有些客户端必须准确无误的收到报文，有些则不需要。
为了保证重要的MQTT报文可以被客户端准确无误的收到。在服务端向客户端发送报文后，客户端会向服务端返回一个确认报文。如果服务端没有收到客户端返回的确认报文，那么服务端就会认为刚刚发送给客户端的报文没有被准确无误的送达。在这种情况下，服务端将会执行以下两个操作：
操作1：将尚未被客户端确认的报文保存起来
操作2：再次尝试向客户端发送报文，并且再次等待客户端发来确认信息。
讲到这里就要看看cleanSession的作用了。
如果cleanSession 被设置为“true”。那么服务端不需要客户端确认收到报文，也不会保存任何报文。在这种情况下，即使客户端错过了服务端发来的报文，也没办法让服务端再次发送报文。其实我们从字面上也很容易理解。cleanSession 的第一个词是clean。这个词的意思是clean（干净）的。服务端一旦发送完报文，就会把报文忘得“干干净净”了。
反过来，如果我们将cleanSession 设置为”false”。那么服务端就知道，后续通讯中，客户端可能会要求我保存没有收到的报文。
从以上的描述不难看出，如果某个客户端用于收发非常重要的信息（比如前文示例中汽车自动驾驶系统），那么该客户端在连接服务端时，应该将cleanSession设置为”false”。这样才能让服务端保存那些没有得到客户端接收确认的信息。以便服务端再次尝试将这些重要信息再次发送给客户端。
相反的，如果某个客户端用于收发不重要的信息（比如前文示例中车载音乐系统）那么该客户端在连接服务端时，应该将cleanSession设置为”true”。
请注意，如果需要服务端保存重要报文，光设置cleanSession 为false是不够的，还需要传递的MQTT信息QoS级别大于0。
关于QoS的概念，我们会在本教程后续课程中详细讲解。到目前请您务必牢记，如果想让服务器记住重要报文，那么客户端在连接服务端时，需要把cleanSession中设置为false。这一点非常关键，请务必牢记。
keepAlive – 心跳时间间隔
MQTT服务端运行过程中，当有客户端因为某种原因断开了与服务端的连接，服务端需要实时了解这一情况。KeepAlive （心跳时间间隔）正是用于服务端了解客户端连接情况的。不过关于KeepAlive （心跳时间间隔）目前讲解还为时过早，我们会在后续的课程中给您做详细介绍。目前您只需要记住，KeepAlive用于服务端实时了解客户端是否与其保持连接的情况。
以上就是CONNECT报文的主要内容。关于CONNECT报文中的其它内容，我们会在接下来的课程里给大家讲解。下面我们再看看MQTT服务端接收到客户端发来的连接请求后所回复的CONNACK报文详细内容。
CONNACK – 确认连接请求
下图是CONNACK报文所包含的信息内容。
CONNACK报文包括两个信息。一个是returnCode(连接返回码)，另一个是sessionPresent (当前会话)。以下是这两个信息的说明：
returnCode – 连接返回码
当服务端收到了客户端的连接请求后，会向客户端发送returnCode(连接返回码)，用以说明连接情况。如果客户端与服务端成功连接，则返回数字“0”。如果未能成功连接，连接返回码将会是一个非零的数值，具体这个数值的含义，请见下表：
| 返回码 | 返回码描述 |
|---|---|
| 0 | 成功连接 |
| 1 | 连接被服务端拒绝，原因是不支持客户端的MQTT协议版本 |
| 2 | 连接被服务端拒绝，原因是不支持客户端标识符的编码。 可能造成此原因的是客户端标识符编码是UTF-8，但是服务端不允许使用此编码。 |
| 3 | 连接被服务端拒绝，原因是服务端不可用。 即，网络连接已经建立，但MQTT服务不可用。 |
| 4 | 连接被服务端拒绝，原因是用户名或密码无效。 |
| 5 | 连接被服务端拒绝，原因是客户端未被授权连接到此服务端。 |
sessionPresent – 当前会话
要说明sessionPresent，首先我们要回顾一下CONNECT报文中的cleanSession – 清除会话。
我们还用自动驾驶汽车为例。对于自动驾驶汽车来说，自动导航系统属于非常重要的MQTT客户端。服务端发送给导航系统的报文必须要准确无误的送达。相反，音乐播放系统就不那么重要了。即使音乐播放系统错过服务端发送的报文也没有关系。
对于不重要的MQTT客户端，它们在向服务器发送连接请求时，CONNECT报文中的cleanSession通常设置为true。原因是这类不重要的MQTT客户端即使丢失信息也不会影响整体系统运行。因此服务端在看到客户端的cleanSession为true时，就不会保存发送给它们的信息。
然而对于汽车导航系统这类重要的MQTT客户端来说。当它在连接服务端时，cleanSession肯定时设置为false。原因是重要客户端需要服务端确保信息发送准确无误。如果服务端发现发送给重要客户端的信息没有得到确认，会将报文进行保存。
当重要客户端连接服务端时，服务端可能保存着没有得到确认的报文。如果是这样的话，那么客户端在连接服务端时，就会通过sessionPresent来了解服务端是否有之前未能确认的信息。
下面我们分几种情况来讲述sessionPresent的作用。
首先，当客户端发送的CONNECT报文中的cleanSession设置为true。在这种情况下，客户端是不需要服务端保存任何报文的。那么服务端发送的确认连接CONNACK报文中，sessionPresent肯定是false，也就是说，服务端没有保存任何报文。
当客户端发送的CONNECT报文中的cleanSession设置为false时，客户端是要求服务端保存报文的。在这种情况下，如果服务端的确保存了没有收到客户端接收确认的报文信息，那么cleanSession为true，否则为false。
简言之，CONNACK报文的sessionPresent与CONNECT报文的cleanSession相互配合。其作用是客户端发送连接请求时，服务端告知客户端有没有保存报文信息。这个被服务端保存的报文信息是来自于上一次客户端连接时，服务端曾经发送此报文给客户端，但是发送后没有收到客户端接收确认。
