MQTT IOT物联网协议 入门
MQTT - IOT 通讯
简介
MQTT是一个基于客户端-服务器的消息发布/订阅传输协议。MQTT协议是轻量、简单、开放和易于实现的，这些特点使它适用范围非常广泛。在很多情况下，包括受限的环境中，如：机器与机器（M2M）通信和物联网。
对比其余发布/订阅模式的中间件，例如RabbitMQ、RocketMQ等等，其最大的 优点 是可以以极低的网络宽带占比以及少量的发布、订阅代码，为远程连接提供实时可靠的连接通讯。
使用背景
在与远程设备、无线通讯、非有线进行通讯交互的场景中，由于物联网环境的网络不稳定、硬件网络设备不足、信号弱等等原因。我们无法使用HTTP【灵活但一次通信占用大量带宽以及频繁断开/连接】、其余MQ【RabbitMQ，需维护在一个稳定的网络通信下】。
在非传统的物联网环境下，MQTT的使用显得尤为特殊：
- 发布/订阅
- 低带宽、低通信、高延迟
- 处理海量客户端连接
- 理解、并高效转发客户端通信数据
- 消息体灵活性
- 基于客户端Topic主题维护服务端消息群
- .......
简而言之，MQTT在知晓 客户端与服务端通信不稳定、高交互少数据、海量连接等业务场景下，被设计推出的物联网主流通信协议。
版本
目前MQTT流行的主流版本分别是 MQTT3.3.1、MQTT5，前者在2014年10月发布，后者诞生于2019。迭代至今，两者也可互相兼容。
除了上者的TCP版本，因离线业务下，需支持UDP连接，所以后续诞生出UDP版本连接的MQTT-SN；
两者版本的优缺点，由于连接方式的不同而大同小异。
区别
对比其余 发布/订阅 模式的三方中间件，MQTT的出发点与接入场景在消息队列模式中有着明显差异；
- 对比通道MQ，后者常见在服务端与服务端之间的消息交互中，在非传统HTTP的无线、硬件通讯中无法保证可靠稳定的传输协议
- 对比通道MQ，MQTT重在在海量客户端连接，轻数据消息体，管理主题与传输上。
- MQTT并非消息队列，他属于一种通信协议，最简单的来说就是我们可以使用 RabbitMq搭建一个MQTT服务器 https://www.rabbitmq.com/mqtt.html
- ...
在我的使用角度上，MQTT与RabbitMQ是没有任何差异的，因为都是基于 发布订阅 模式，所以都是通过客户端订阅主题，发布主题消息进行与目标方通讯的模式。
但是RabbitMQ这种消息通道在使用过程中可以发现其信息堆积、客户端高连接量、网络断开等等等所带来的的服务端与服务端通讯时造成的消息丢失，内存溢满等等问题。
在MQTT的使用角度上，我比如成，
我打开电视【MQTT服务器】看电视剧【消息体】，在这个过程中，如果我离开了【网络断开】，但是电视机还是开着【保持会话】，电视剧还在播放【其他客户端还是可接收】；等到我回来【重新连接】，重新看电视剧【离线信息保留】。突然，我晕了【离线状态】，电视机播放下一集【时间异步】，我醒了后直接看下一集【异步推送】
...
大致是这样
实现
在 发布/订阅 模式的三者身份中， 发布者 、代理 、订阅者，MQTT的代理服务器，可用RabbitMQ实现的MQTT服务器插件，或是使用EMQ、阿里云MQTT服务器等。
代理服务器
消息传输的中间管理商，管理所有客户端的连接【记录ClientId、IP、QoS、心跳机制等】，确保客户端之间的低能通讯，保证MQTT消息得到正确投递。其生命周期在以下状态中维续：
- 接受客户端连接，存储连接信息【ClientId】
- 处理客户端的主题订阅与退订请求
- 接受客户端的主题消息
- 转发客户端请求的主题消息
发布者与订阅者
与MQTT建立TCP连接，建立在服务端上唯一的clientId。
发布与订阅主题的动作，由各自主动和监听逻辑完成，并且根据建立连接的Qos完成消息的回执。
模型
后台应用、APP、WEB在MQTT服务器上订阅了速度主题；
当小车进行速度上报后，三者可同时接到主题内的消息并进行对应操作
反之
也可各自对速度主题进行推送。
上面可见，MQTT通讯的核心与其余MQ一样，都是基于服务端/通道为轴进行接收与发布的。
且在MQTT通讯中，各自客户端保持了各自的空间、时间独立。
在上述我的 “电视机” 举例中，
时间独立：小车下线，客户端主题消息堆积在服务器上，等小车上线，根据到达时间排序陆续处理主题发送信息。空间独立：各客户端仅在自己的网络环境下发布自己的主题信息，以及接受订阅主题信息。
保持会话：从小车上线开始，与服务端进行连接，订阅主题。这是一次会话动作。小车下线，会话未过期重新与服务端建立连接，可直接从会话中取订阅的主题，无需重复订阅动作。
Qos：Qos是MQTT特有的消息确认机制，和MQ的ACK机制一样，他可手动去确保消息的到达率。
在于服务端建立连接时设置本次会话的Qos：
Qos 0 ，客户端只发送一次主题消息，不检查是否到达，在低带宽下有丢失消息的风险。适用与网络稳定但需带宽占用少的应用中。
Qos 1和2，通过一次类握手的机制，来回确认报文的方式，前者确保消息至少发一次，后者确保消息收到一次。前者会出现网络断开时，重复发送消息的情况。后者基于过多的校验工序，保证了消息的安全传输。
心跳机制
客户端与服务端连接时，可通过报文的方式向服务端 一个心跳包的时间内发送keepAlive报文。
如果服务端在一个KeepAlive的1.5倍时间后未收到客户端发送过来的活动包，则判断客户端死亡。
死亡动作
客户端可设置死亡时向客户端发送一条遗嘱主题
总结
使用百度百科的一句话作为终句，
MQTT(消息队列遥测传输)是ISO 标准(ISO/IEC PRF 20922)下基于发布/订阅范式的消息协议。它工作在 TCP/IP协议族上，是为硬件性能低下的远程设备以及网络状况糟糕的情况下而设计的发布/订阅型消息协议，为此，它需要一个消息中间件 。
**为此，它需要一个消息中间件 **
MQTT是一个传输协议，他制定了一套低带宽，高效处理连接、转发的发布订阅TCP协议。
而我们常说的MQ，是消息队列，是一个存储消息数据的数据库，消息中间件。