前言

最近工作中有用到 MQTT 协定，在此做一个钻研学习总结和采坑指南。如果你在工作中也有用到，欢送交换。文中如有不足之处，欢送斧正。

1. 什么是 MQTT

MQTT（Message Queuing Telemetry Transport，音讯队列遥测传输协定），是一种基于公布 / 订阅（publish/subscribe）模式的轻量级协定，该协定构建于 TCP/IP 协定之上，MQTT 最大长处在于，能够以极少的代码和无限的带宽，为连贯近程设施提供实时牢靠的音讯服务。作为一种低开销、低带宽占用的即时通讯协定，使其在物联网、小型设施、挪动利用等方面有较宽泛的利用。

MQTT 是一个基于客户端 - 服务器的音讯公布 / 订阅传输协定。MQTT 协定是轻量、简略、凋谢和易于实现的，这些特点使它适用范围十分宽泛。在很多状况下，包含受限的环境中，如：机器与机器（M2M）通信和物联网（IoT）。其在，通过卫星链路通信传感器、偶然拨号的医疗设施、智能家居、及一些小型化设施中已宽泛应用。

小结 ：MQTT 曾经成为物联网零碎事实上的网络协议规范。如果你想从事物联网开发，就肯定要把握 MQTT。

2. 感触 MQTT 的应用

装置 MQTT，能够间接找到 hbmqtt（python 语言）这样的我的项目拿来用。它的背地有 Eclipse 基金会的反对。

相似的 MQTT Broker 软件，你还能够抉择基于 C 语言的 Mosquitto，基于 Erlang 语言的 VerneMQ 等。

至于 MQTT 的客户端（Client）实现，也有成熟的 Python、C、Java 和 JavaScript 等各种编程语言的开源实现，供你参考、应用，比方 Eclipse Paho 我的项目。

而且，还有很多商业公司在继续经营性能更丰盛、反对更齐备的商业版 Broker 实现，比方提供高并发能力的集群个性、不便拓展的插件机制等。这些会大大提高咱们技术开发者的工作效率。比方中国一个团队开发、保护的 EMQ X，它曾经残缺地反对 MQTT5.0 协定。

测试工具举荐 ：MQTT X 能够在线测试或下载本地客户端进行 mqtt 连贯测试和事件的主题订阅、音讯发送等。

有助于定位问题，强烈推荐。

另外，生态欠缺还有一个益处，那就是作为开发者，当你遇到难题时，能够很不便地找到很多相干的材料；就算材料解决不了问题，你还能够去社区中发问，寻求高手的帮忙。这在理论工作中十分有用。顺便提一下，除了老牌的 Stack Overflow，你还能够关注一下 GitHub 的 Issues 模块，因为在那里能够找到很多专家。

小结：做为 Android 开发者，我曾经找出了泛滥开源我的项目的官网开源地址，如想疾速体验，请移步：

Android Service

在采坑中发现，有些问题是存在的，比方 Andorid Q 之后的前台服务等问题，有些 fork 分支解决了局部问题，如果你在我的项目中也遇到了类似问题，先看看 issus 中的解决方案，甚至能够间接应用 fork 分支上的开源我的项目。

小结：mqttt 应用上手是十分快的，测试和工具应用能够很快感觉 mqtt 的流程，体验后能够依据我的项目的技术指标在钻研下第三方如阿里云 mqtt 本人搭建服务器时性能指标。而后再依据业务需要，抉择第三方平台和本人搭建服务器。

3. MQTT 的生态绝对欠缺

当然，阿里云、华为云、腾讯云和微软 Azure 这些大厂，之所以不谋而合地抉择 MQTT 协定作为物联网设施的“第一语言”，不仅是因为 MQTT 的生态欠缺，MQTT 协定自身的优良设计也是重要的因素。

它在设计上的长处体现在哪呢？我想次要有五个方面：

1. 符合物联网大部分利用场景的公布 – 订阅模式。
2. 可能满足物联网中资源受限设施须要的轻量级个性。
3. 时刻关注物联网设施低功耗需要的优化设计。
4. 针对物联网中多变的网络环境提供的多种服务质量等级。
5. 反对在物联网利用中越来越被器重的数据安全。

3.1 公布 – 订阅模式

mqtt 采纳了公布 – 订阅模式，MQTT 协定具备很多长处，比方能让一个传感器数据触发一系列动作；网络不稳固造成的长期离线不会影响工作；不便依据需要动静调整零碎规模等。这使得它能满足绝大部分物联网场景的需要。

3.2 轻量级协定：缩小传输数据量

MQTT 是一个轻量级的网络协议，这一点也是它在物联网零碎中风行的重要起因。毕竟物联网中大量的都是计算资源无限、网络带宽低的设施。

这种“轻量级”体现在两个方面。一方面，MQTT 音讯采纳二进制的编码格局，而不是 HTTP 协定那样的文本的表述形式。

这有什么益处呢？那就是能够充分利用字节位，协定头能够很紧凑，从而尽量减少须要通过网络传输的数据量。

比方，咱们剖析 HTTP 的一个申请抓包，它的音讯内容是上面这样的（留神：空格和回车、换行符都是音讯的组成部分）：

GET /account HTTP/1.1    <-- 正文：HTTP 申请行
Host: time.geekbang.com  <-- 正文：以下为 HTTP 申请头部
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:81.0) Gecko/20100101 Firefox/81.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, sdch
Accept-Language: zh-CN,zh;q=0.8,en;q=0.6
                         <-- 正文：这个空行是必须的，即便上面的申请体是空的 

在 HTTP 协定传输的这段文本中，每个字符都要占用 1 个字节。而如果应用 MQTT 协定，一个字节就能够示意很多内容。上面的图片展现了 MQTT 的固定头的格局，这个固定头只有 2 个字节：

你能够看到，第一个字节分成了高 4 位（4～7）和低 4 位（0～3）；低 4 位是数据包标识位，其中的每一比特位又能够示意不同的含意；高 4 位是不同数据包类型的标识位。

第二个字节示意数据包头部和音讯体的字节共个数，其中最高位示意有没有第三字节存在，来和第二个字节一起示意字节共个数。

如果有第三个字节，那它的最高位示意是否有第四个字节，来和第二个字节、第三个字节一起示意字节总个数。依此类推，还可能有第四个字节、第五个字节，不过这个示意可变头部和音讯体的字节个数的局部，最多也只能到第五个字节，所以能够示意的最大数据包长度有 256MB。

比方，一个申请建设连贯的 CONNECT 类型数据包，头部须要 14 个字节；公布音讯的 PUBLISH 类型数据包头部只有 2～4 个字节。

轻量级的另一方面，体现在音讯的具体交互流程设计非常简单，所以 MQTT 的交互音讯类型也非常少。为了不便前面的解说，我在这里整顿了一个表格，总结了 MQTT 不同的数据包类型的性能和发消息的流向。

从表格能够看出，MQTT 3.1.1 版本一共定义了 14 种数据包的类型，在第一个字节的高 4 位中别离对应从 1 到 14 的数值。

3.3 低功耗优化：节约电量和网络资源

除了让协定足够轻量，MQTT 协定还很重视低功耗的优化设计，这次要体现在对能耗和通信次数的优化。

比方，MQTT 协定有一个 Keepalive 机制。它的作用是，在 Client 和 Broker 的连贯中断时，让单方能及时发现，并从新建设 MQTT 连贯，保障主题音讯的牢靠传输。

这个机制工作的原理是：Client 和 Broker 都基于 Keepalive 确定的工夫长度，来判断一段时间内是否有音讯在单方之间传输。这个 Keepalive 工夫长度是在 Client 建设连贯时设置的，如果超出这个工夫长度，单方没有收到新的数据包，那么就断定连贯断开。

尽管 Keepalive 要求一段时间内必须有数据包传输，但理论状况是，Client 和 Broker 不可能时时刻刻都在传输主题音讯，这要怎么办呢？

MQTT 协定的解决方案是，定义了 PINGREQ 和 PINGRESP 这两种音讯类型。它们都没有可变头部和音讯体，也就是说都只有 2 个字节大小。Client 和 Broker 通过别离发送 PINGREQ 和 PINGRESP 音讯，就可能满足 Keepalive 机制的要求。

嵌入式设施的运算能力和带宽都绝对单薄，应用这种协定来传递音讯再适宜不过了。

我猜你也想到了，如果要始终这样“傻傻地”定期发送音讯，那也太节约电量和网络资源了。所以，如果在 Keepalive 工夫长度内，Client 和 Broker 之间有数据传输，那么 Keepalive 机制也会将其计算在内，这样就不须要再通过发送 PINGREQ 和 PINGRESP 音讯来判断了。

除了 Keepalive 机制，MQTT 5.0 中的反复主题个性也能帮忙咱们节俭网络资源。

Client 在反复发送一个主题的音讯时，能够从第二次开始，将主题名长度设置为 0，这样 Broker 会主动依照上次的主题来解决音讯。这种状况对传感器设施来说非常常见，所以这个个性在工作中很有实际意义。

举例说明：比方产生是主题是“/xxx/iot”，第一次须要在信息体中蕴含这个主题的字符，第二次就能够省掉这个主题名字了。

3.4 三 种 QoS 级别：牢靠通信

除了计算资源无限、网络带宽低，物联网设施还常常遇到网络环境不稳固的问题，尤其是在挪动通信、卫星通信这样的场景下。比方共享单车，如果用户曾经锁车的这个音讯，不能牢靠地上传到服务器，那么计费就会呈现谬误，后果引起用户的埋怨。这样怎么应答呢？

这个问题产生的背景就是不稳固的通信条件，所以 MQTT 协定设计了 3 种不同的 QoS（Quality of Service，服务质量）级别。你能够依据场景灵便抉择，在不同环境下保障通信是牢靠的。

这 3 种级别别离是：

• QoS 0，示意音讯最多收到一次，即音讯可能失落，然而不会反复。

  （留神：网络有很多博客说可能会反复，这里能够抓包确认，有疑难的请务必去测试验证。这里我了解不只管发，不论收，所以会失落，然而不会反复）

• QoS 1，示意音讯至多收到一次，即音讯保障送达，然而可能反复。
• QoS 2，示意音讯只会收到一次，即音讯有且只有一次。

图片中展现了 qos 各自的特点。能够看到，QoS 0 和 QoS 1 的流程绝对比较简单；而 QoS 2 为了保障有且只有一次的牢靠传输，流程绝对简单些。

失常状况下，QoS 2 有 PUBLISH、PUBREC、PUBREL 和 PUBCOMP 4 次交互。

至于“不失常的状况”，发送方就须要反复发送音讯。比方一段时间内没有收到 PUBREC 音讯，就须要再次发送 PUBLISH 音讯。不过要留神，这时要把音讯中的“反复”标识设置为 1，以便接管方能正确处理。同样地，如果没有收到 PUBCOMP 音讯，发送方就须要再次发送 PUBREL 音讯。

分析到这里，MQTT 协定自身的次要个性我就介绍完了，咱们曾经为在实战篇编写 MQTT 的相干通信代码做好了筹备。然而，我还想跟你补充一个跟生产环境无关的知识点，那就是数据安全传输。

3.5 平安传输

说到平安传输，首先咱们须要验证 Client 是否有权限接入 MQTT Broker。为了管制 Client 的接入，MQTT 提供了用户名 / 明码的机制。在建设连贯过程中，它能够通过判断用户名和明码的正确性，来筛选无效连贯申请。

然而光靠这个机制，还不能保障网络通信过程中的数据安全。因为在明文传输的形式下，不止设施数据，甚至用户名和明码都可能被其他人从网络上截获而导致透露，于是其他人就能够伪装成非法的设施发送数据。所以，咱们还须要通信加密技术的反对。

MQTT 协定反对 SSL/TLS 加密通信形式。采纳 SSL/TLS 加密之后，MQTT 将转换为 MQTTS。这有点相似于 HTTP 和 HTTPS 的关系。

小结：

总结一下，在这一讲中，我带你体验了应用 MQTT 协定的通信过程，同时也为你介绍了 MQTT 协定的几个特点。

1. MQTT 协定的生态很好。比方，MQTT 协定的代码实现十分丰盛，C 语言的有 Mosquitto，Python 语言有 Eclipse hbmqtt，而且有商业公司在经营相干软件解决方案。这表明 MQTT 协定很成熟。
2. MQTT 协定采纳了适宜物联网利用场景的公布 – 订阅模式。当然，我也提到了 MQTT 5.0 中同样减少了申请 – 响应模式，便于局部场景中的开发应用。
3. MQTT 协定采纳二进制的音讯内容编码格局，协定很精简，协定交互也简略，这些特点保障了网络传输流量很小。所以客户端（包含发布者和订阅者角色）的代码实现能够短小精悍，比方 C 语言的实现大略只占 30KB 的存储空间，Java 语言也只须要 100KB 左右大小的代码体积。
4. MQTT 协定在设计上思考了很多物联网设施的低功耗需要，比方 Keepalive 机制中精简的 PINGREQ 和 PINGRESP 这两种音讯类型，还有 MQTT 5.0 中新减少的反复主题个性。这也再次印证了 MQTT 的定位十分明确，那就是专一于物联网场景。
5. MQTT 在音讯的牢靠传输和安全性上，也有残缺的反对，能够说“简洁而不简略”。

4. 实现形式

MQTT 协定中，须要两个端，别离是服务端和客户端；有三个身份，别离是发布者（Publish），代理（Broker）、订阅者（Subscribe）。

  在 MQTT 协定中，客户端不能间接对客户端履行端到端的收发音讯，必须通过服务端治理调配，所以服务端要运行一个代理服务，也就是三个身份之一的代理身份。音讯的发送方称为发布者，该音讯的须要接收者称之为订阅者。发布者把音讯发送给代理，代理负责查看都谁须要接管这个音讯（这个就是订阅），须要的就转发给它。因为要辨认不同的音讯，所以 MQTT 协定制订了主题规范，也就是给音讯加上了标签。发布者发送的音讯总是要带上标签的，代理依据谁订阅了这个标签来决定转发给谁，这个标签就称之为主题（Topic），标签携带咱们须要传输的信息内容称之为负载（Payload）。

  为了实现异常中断告诉机制，所以在客户端与服务端首次连贯的时候，就要携带一条绝对非凡的主题，主题内容是如果本人掉线了，心愿告知须要晓得本人掉线一方一些信息，这就是遗嘱音讯（Will Message）。这个主题本人在线时，代理不会做任何转发，当本人掉线达到肯定工夫（即心跳距离 Keep Alive timer），代理会查看谁订阅了这个主题，就转发给谁（当然能够多人订阅），这就实现了异常中断（掉线）告诉。

  上面持续深刻了解一下 MQTT 协定的工作过程。

发布者、订阅者、代理与主题公布与订阅间的关系：

5. 实现 Demo

Talk is cheap,show me code.

依据调研的状况，实现了阿里云 mqtt 和能用的 mqttDemo. 解决了参考其余 demo 会呈现这样或那样的问题，同时实现了 mqtt 性能的收发数据工夫测试性能，最近会始终保护，欢送 star。

github 开源地址：https://github.com/june5753/m…

6. FAQ

1. 连贯失败问题

   请查看 ClientID 中是否是惟一的，个别以工夫戳或 uuid 做为连贯的 clientID

2. 音讯反复或失落

   • 请查看 qos 的设置值。默认值为 0，依据业务请查看。
   • 连贯参数的属性设置，比方
3. 连贯胜利，订阅时失败

   请查看 connect 连贯的接口是否抉择正确，开发中遇到，Android connect 中的接口有好几个, 留神不要抉择错了。

4. 其余问题，待欠缺~

最初，如果你也在应用 Mqtt，遇到了什么问题，欢送留言交换，我看到了肯定及时回复。

参考：

MQTT 介绍与应用

物联网相干开源我的项目整顿

极客工夫 MQTT：在实践中把握一个通信协议

转战物联网·根底篇 05- 艰深了解 MQTT 协定的实现原理和异步形式

扩大浏览：

能够理解一下 sdk 的调用及欠缺，同时在接入 mqtt 时，能够考虑一下如何封住成 sdk，不便复用。

Android Mqtt 音讯推送应用

阿里云音讯队列 MQTT 踩坑之路（阿里云 MQTT Android 客户端 )

Android 应用 Mqtt 协定链接 ActiveMQ 服务器实现推送