MQTT解读【全网最易懂】

Bertha 。 2024-02-21 08:39 192阅读 0赞

**目录**

前言

一、MQTT相比于TCP长连接的优势

1、协议更标准

2、MQTT协议制定好了很多利于物联网的功能

3、理解数据内容，用数据产生价值

二、选择MQTT还是TCP长连接透传

1、原始的业务场景

2、端对端M2M场景——无人汽车

3、APP控制设备端场景——智能家居、智能快递柜

4、其他场景

总结

--------------------

## 前言 ##

在接触到MQTT之后，总是会有疑问，为什么用MQTT不用TCP长连接透传？看起来【TCP长连接+私有协议透传】和【MQTT+业务主题】似乎都能达到同样的目的，甚至用MQTT会使得设备端逻辑实现、APP端逻辑实现、云端架构实现更加复杂。那么为什么物联网还要使用MQTT协议呢？

[![36cce3b1511e25aa27e57465ba122d0b.jpeg][]][36cce3b1511e25aa27e57465ba122d0b.jpeg 1]

## 一、MQTT相比于TCP长连接的优势 ##

### 1、协议更标准 ###

MQTT是标准的RFC协议，相比于私有协议而言更加标准。好处在于：

（1）协议非常完整，能够马上用于生产。各端实现同一套协议之后，就能进行通信；私有协议还需要进行大量的验证，看有无缺陷或欠考虑的地方等。

（2）协议的标准化带来大量的开源组件，降低开发难度。随着物联网+5G生态越来越好，开源组件越来越多，可以减少重复编码量。

（3）标准协议利于第三方接入。当第三方设备、平台想要对接的时候，拿出一套标准的MQTT协议拍在他们脸上，再也没人有理由要求改接口了。

### 2、MQTT协议制定好了很多利于物联网的功能 ###

当然TCP自己开发协议也能做到，但MQTT都已经把功能做好了，自己开发协议反而增加难度。有利的功能包括：

（1）心跳机制。不需要自己做业务协议层的心跳了。

（2）遗嘱消息。这对于经常掉线的物联网设备而言非常有用。

（3）QoS质量等级+离线消息。持久会话离线的消息也能接收到，对于网络不稳定但要求必须送达的物联网场景很有用。

（4）异步机制。MQTT将消息以QoS1/2发送出去后，设备端就不需要再管了，一切由云端负责失败重传。

（5）订阅发布机制。一次发布，多个客户端订阅，这对于M2M场景很省电、省流量。

（6）主题和安全。可以用主题来方便地控制客户端权限。

以上的功能基于TCP自己开发也能做到，如果自己都开发了，不就是实现了应用层的MQTT协议了吗

### 3、理解数据内容，用数据产生价值 ###

IoT目前主流设计有两部分：

（1）设备影子价值

微软Azure叫设备孪生（Device Twins），亚马逊AWS叫设备影子（Device Shadow），阿里云叫设备影子（Device Shadow），腾讯云叫设备影子（Device Shadow），百度云叫物影子（Shadow）。为什么这么多大厂都要开发这个概念呢，设备影子包含了设备的状态，不用一个一个透传查询设备，直接在云端访问设备影子就能够得到当前所有设备的状态数据，这蕴含着巨大的利益，比如统计数据用于引导开发新产品和功能、统计数据用于修复bug等等。

（2）规则引擎价值

AWS、阿里云、腾讯云、百度云，都叫规则引擎（Rule Engine）。由于MQTT细分了具体的主题，当业务以主题区别的时候，直接将对应主题的数据通过规则引擎配置的规则自动分发给其他的数据接收者，比如阿里云可以发送给：

*  关系数据库RDS，进行普通存储
 *  时序数据库TSDB，可用于时序分析
 *  存储桶Bucket，当文件存储
 *  消息队列MQ，可以转发给多个其他服务
 *  函数计算，无服务器地处理某项工作
 *  实时流，实时地发送给某些对时间敏感的服务
 *  另一个主题，可以实现M2M通信

这些都可以有很多操作空间，随便举个例子，把所有的天猫精灵的语音数据发送到MQ，然后用后端服务慢慢分析，利用机器学习算法研究出什么样的用户群体喜欢使用什么样的功能，好针对性地卖产品，比如阉割一些功能，卖“青春版”天猫精灵，或者增加一些高端功能，卖“商务版”天猫精灵。

这些都是TCP透传这种云不理解业务数据内容做不到的（不要说TCP也可以解包然后分析业务数据然后转发，这样不就是变相地实现了MQTT了吗？有人想可以直接用MQ，但很多MQ的client/lib并不具备弱网+低功耗的微型设备使用条件，最终还是会演变为实现了类似MQTT的东西）。

## 二、选择MQTT还是TCP长连接透传 ##

这需要看具体的业务场景。

### 1、原始的业务场景 ###

MQTT之所以叫做“消息队列遥测传输”协议，就是因为最开始是用来将无人看管的石油天然气管道数据通过卫星链路上报给数据中心，当时的需求在于：

（1）石油天然气管道大多处于无人区，更不可能有基站了，只能通过偶尔覆盖的卫星来通信。卫星通信极其不稳定，很容易频繁断开连接。

（2）数据采集频率不高，且数据量小。

（3）有的消息很重要，需要有质量保证，比如石油泄漏，即使想发送的时候断网了，也应该在断网后能够传出去，且传出去必须要保证送达。

（4）采集设备都是嵌入式设备，要求低功耗。

这不就是MQTT的“会话机制”、“异步机制”、“QoS机制”等功能的体现吗。

### 2、端对端M2M场景——无人汽车 ###

有的业务是不需要APP的，只有云和设备端，并且消息从一个设备端发到另一个设备端，这个时候用MQTT再合适不过了，因为一个设备如果想要发给多个设备消息，考虑到嵌入式资源有限一次只能保持一条TCP SSL连接，采用TCP透传必然要频繁建立TCP连接，这对低功耗的设备是致命的；而用MQTT，由云端负责转发就非常方便。

### 3、APP控制设备端场景——智能家居、智能快递柜 ###

其实采用TCP透传和MQTT都可以，如果MQTT只订阅一个主题，只发布一个主题，payload填业务数据，不就退化成TCP长连接透传了吗。有的可能已经有私有协议了，如果想要把IoT做大，可以考虑MQTT协议；如果想减少成本尽快上线，用TCP透传也可以。

### 4、其他场景 ###

MQTT还可以用于其他场景，比如APP消息推送（知乎网关），游戏数据长连接，网络聊天等等，都存在真实案例。他们不用TCP长连接的理由会有很多，比如知乎是为了复用同一套长连接系统，解耦业务数据，保证消息质量等。

## 总结 ##

当别人问为什么要用MQTT不用TCP长连接透传的时候，要先体会MQTT的好处，然后结合自己的业务分析是否真的有必要上MQTT（毕竟MQTT整套下来成本比TCP高不少）。当然还有其他协议，比如室外的智能路灯由于只能通过基站上网，因此可以用插SIM卡的CoAP协议；一些总是插电的设备如路由器，甚至可以用HTTP协议。在纠结MQTT协议的时候，这些都是可以考虑的方向。

转自网络，有待考古

[36cce3b1511e25aa27e57465ba122d0b.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/21/3ed96388ab2f4161a33373c973c142cb.png
[36cce3b1511e25aa27e57465ba122d0b.jpeg 1]: https://blog.yanjingang.com/wp-content/uploads/2020/02/ec4efaa51077c62cf1e40d016876cebe-1.jpeg