MQTT是基于TCP/IP协议栈构建的异步通信消息协议，是一种轻量级的分发、订阅信息传输协议。 MQTT正在成为IoT领域最受欢迎的协议，也是国内外各物联网平台最主流的传输协议，是Alibaba云IoT物联网平台的众多本文将详细介绍MQTT协议的历史发展，以及阿里巴巴云IoT物联网平台在MQTT协议层实践中的重要设计和思考。
本文主要包括以下内容。
总结分析了MQTT协议演进的历史和协议特点、MQTT协议族的优缺点，分析总结了为什么MQTT比其他协议更适合IoT等。
阿里巴巴云IoT MQTT3和5协议实践中的几点重要设计与思考。 包括连接复用、状态一致性、扩展增值设计等。
一、MQTT协议
1.1 MQTT协议演进MQTT最初由IBM发明于20世纪90年代，最初用于石油管道传感器与卫星之间的数据传输。 MQTT v3.1.1于2014.10月正式发布，同时v3.1.1成为OASIS协议标准(即3.1.1升级为国际物联网标准)。 正如HTTP为人们在web上共享信息铺平了道路，MQTT标准化可以将数十亿低成本的IoT设备连接到网络。 毫无疑问，MQTT是当今主流、增长最快的IoT APP应用层传输协议，目前Alibaba云(AlibabaCloud ) IOT平台上的许多在线设备都通过MQTT进行访问。
MQTT v5.0于2018.5月正式发布，2019年3月，v5.0成为新的OASIS标准。 v5.0基于v3.1.1进行了较大的更改，不向后兼容。 显然引入了很多新东西，所有现有的实现都将重新实现。 http://www.Sina.com/Alibaba云(IoT )平台从2020.12月开始支持MQTT5.0。
此次通过的v5.0是自2014年的v3.1.1以来最重要的协议升级，新协议能适应近年来行业发展的新需求，同时也为未来物联网行业发展的做了协议上的准备每个协议都是特定上下文、约束条件下的折中设计，没有完美的协议。 MQTT经过几十年的发展，已经发展成为针对不同场景比较成熟的多版本协议。
MQTT v3 MQTT v3协议是一种基于TCP的APP应用层协议，专为在低带宽、不可靠的网络上运行的传感器而设计，适用于IoT场景。 它具有使用发布/订阅消息模型支持一对多消息传递和断开设备与业务的耦合的重要功能。 消息传递格式设计简单，适用于小型数据传输和资源有限的IoT设备。 固定标头为2字节，开销小，支持三种消息QoS:QoS 0、QoS1和QoS2。
1.2 MQTT协议族主要是客户端id的优化、broker支持为设备分配客户端id以及客户端id的最大长度的增加。 优化ack响应、在connect ack上引入session Present徽标等。
MQTT3.1.1在MQTTv3基础上引入了一些新特性， :1)误码设计不充分，设备难以完全感知broker的处理异常； 2 )不支持设备和中介之间的能力发现/协商，中介不能提供可选能力等。 3 )协议设计过于简化，扩展空间不够，不能直接在协议层扩展，协议能力比较简陋。 4 )一些高级能力支持不够，如协议层缺乏流量控制、优先级、报头压缩等功能。 5 ) MQTT3是基于TCP的APP应用层协议，并且MQTT也有一些TCP特定的缺点。
传感器网络(mqtt-snmqtt-sn )是mqtt协议的传感器网络版本，最先用于zigBee无线网络，主要面临电池电源、有限的处理器能力和存储能力的设备只有内存和CPU很小，TCP对这些设备来说非常奢侈，甚至不能允许TCP协议栈。 在一些网络(如zigBee )中，消息的长度不超过几百字节，并且不能承载太大的分组。 MQTT-SN具有主要特征。 1 ) MQTT-SN支持在链路层、IP和UDP上运行。 2 ) QOS增加-1级，仅用于传输，尽力而为，无保证。 3 )更丰富、成本更低的主题类型。 4 )网络架构增加了SN网关。
MQTT v5 MQTT 5.0在协议层提供了更大的自定义扩展空间，平台基于扩展点支持更丰富的协议功能。 在v3.1版本中，只能通过overlay方式为业务层提供可扩展性。 MQTT5.0的主要设计目标包括：提高错误反馈能力、可扩展性、提高系统可扩展性、限制资源和优化小型客户端访问，以及将典型模式下沉到协议层。 目前主流的MQTT Broker开源社区基本支持v5.0，开源SDK也初步支持v5.0。 同时，国内的IoT云制造商还不支持v5.0，但未来将会到来。
MQTTv3/v3.1.1 在实际应用中存在以下不足
二、MQTT协议层实践主要分为六个模块：
包括2.1 MQTT应用架构多版本协议编解码器、多协议端口复用、会话管理、心跳检测、连接管理等。
基础接入模块：
包括基于自定义协议扩展，实现的一系列扩展功能，包括通道解压缩、低功耗免ping等。增值消息服务：包括Rrpc、广播、时钟同步、脚本前置解析等。
业务埋点模块：设备行为统计、在线时长聚合、网络延时诊断等。
安全防御模块：包括黑名单机制、入口流控等。
高可用模块：包括流量分组调度、容灾降级等。
运维管控模块：主要包括流量分组调度、限流管理、连接诊断
2.2 协议层设计挑战设备状态一致性策略设计，包括session管理机制、心跳检测机制、异地登陆问题、状态最终一致性策略。
在MQTT发布/订阅异步分发模型上，如何满足多样的业务场景。例如同步调用、广播等。
如何同时满足不同场景下设备对MQTT接入需求，单应用上如何同时支持两个版本MQTT协议
MQTTv3协议过于精简，业务从MQTT3切换到v5的过渡时间，如何扩展协议层能力，提高客户接入体验。
2.3 MQTT关键策略设计 设备在线状态协议层本地有session管理器来对本地会话进行管理，通过心跳检测、会话自检来保证跟设备之间的连接状态一致性，当前平台单设备不支持同时同设备多端登陆，基于分布式会话，协议层通过分布式会话识别异地登陆，将异常连接踢下线。
设备状态一致性策略：设备到MQTT协议接入层之间是tcp长连接，通过心跳机制保证心跳周期内设备状态的最终一致性。同时通过分布式会话版本号，保证分布式会话并发更新安全，通过上行消息/心跳定时触发会话自检机制，解决异常情况下本地/分布式会话状态不一致的问题。
消息推送模式MQTT协议是基于PUB/SUB的异步通信模式，针对单设备纬度实现基础的发布/订阅推送外，还支持了复杂的消息推送方式：RRpc和在线广播。
在传统的基于PUB/SUB通信模式的中间件中， 消息的Producer/Consumer只负责生产和消费，彼此之间不会直接通讯。而在某些业务场景不仅仅是将消息投递至订阅方，订阅方收到消息后可能还会执行一些操作并返回结果，PUB/SUB模式下实现这种请求/响应模式会非常繁琐，在MQTT中通信双方需要事先协商请求和响应topic。
针对这一痛点，协议层在发布订阅模式之上构建了一套Rpc通讯模式，解决开发者痛点。Rrpc模式允许Producer发出消息后，以同步形式等待Consumer消费这条消息并返回响应，达到类似Rpc的调用效果。Rrpc模式使得MQTT应用具备了同步调用的能力，扩展了使用场景，使其具备更多的可能性
通过topic中包含的messageId匹配请求与响应，对业务数据零侵入
messageId的生成与匹配、超时控制等逻辑，调用方无感知
简化了业务方调用逻辑，扩展了MQTT使用场景。
多种类接入方式MQTT协议层针对不同场景支持多种MQTT接入方式，同时支持tcp直连、tls、ws、wss等方式接入，用于满足不同场景接入需求。为了实现更好的网络穿透性，协议层实现了多协议端口复用，也就是一个端口同时支持多种协议。
边解析边判断，处理效率高；
节约常用端口，实现更好的网络穿透性
内部能力扩展对设备侧无感知
针对MQTT协议5和3，通过协议解析也实现了同时兼容。
自定义协议扩展MQTTv3在实际应用中存在一些缺点，而MQTTv5生态的繁荣推广还需要很长时间的推进， 在MQTT3到5的过渡时间，我们在v3.1.1基础上通过overlay的方式，提供了扩展套件来解决客户痛点，丰富接入增值能力，提高接入体验。思路：没有什么问题不是封一层解决不了的，如果有那就再封一层
通过在建连clientId中扩展ext参数，实现端云之间能力协商
通过扩展消息topic格式，实现支持自定义属性
定义一套ext异常推送topic规范
三、展望未来
当前阿里云IoT平台协议层已支持了MQTT主流协议，并支持了多种协议接入方式，但还存在一些会进一步优化的地方：1）更丰富的消息质量模型，例如支持QoS2，支持消息优先级等；2）完善低功耗领域的网关侧支持，可以跟SDK/边缘网关合作，支持MQTT-SN协议等
扫码免费参加AIoT训练营
往期推荐
1、HarmonyOS 到底是不是Android套壳？
2、5G将是一个彻底失败的通信技术吗？
3、AWS IoT 物联网平台 MQTT 通讯模式
4、IoT平台如何实现 100万/秒消息广播？
5、无GPS模块，IoT设备如何定位？
6、 IoT物联网 4 本好书推荐