【干货分享】MQTT协议二三事

MQTT（Message Queuing Telemetry Transport），说人话的意思就是消息队列遥测传输。早些年的PC端盛行的时候，很多工程师压根就没有听过个绕口的名词，但是随着物联网（IoT）技术的逐步发展，这个协议越来越频繁的出现在各大工程师的眼前。这也就造成了很多工程师只知其名不知其意，甚至很多人都还以为这是一种随着IoT发展而被开发出来的协议。其实不然，MQTT协议最早在二十几年前就被发明出来，到了1999年IBM公司的安迪·斯坦福-克拉克及Cirrus Link公司的阿兰·尼普撰写了该协议的第一个版本。后来这个协议也被国际标准化了，成为了ISO 标准(ISO/IEC PRF )下基于发布/订阅方式的消息协议。IBM公司在2013年就向结构化资讯标准促进组织提交了 MQTT 3.1 版规范，并附有相关章程，以确保只能对规范进行少量更改，此后MQTT协议一直在一些小众领域中使用。而到了物联网技术基础设施架构完成之后，这种古老的协议开始焕发出它的第一个春天。

网络的传输层和应用层

众所周知，物联网至今的高速发展离开不了通讯网络的基础建设，你现在可以在全世界的任何一个角落控制家里某个房间灯光的开关，或者做工业控制的时候，你也可以远程操控某个机器人的运动，这种技术的成熟都是基于网络通讯为基础的。而目前网络技术的主要技术就是OSI七层模型，当然实际应用中其实使用的是TCP/IP四层网络模型。

TCP/IP四层网络模型的第三层传输层就是大名鼎鼎的TCP/IP协议了，这一层协议的主要目的是用来将网络上一台计算机发出的通信数据传输到指定IP地址的另一台机器上面，比如一个IP地址为\"\"的机器要发给IP地址为\"\"的机器16字节的二进制数据包，那么使用TCP/IP协议传输即可以。而是用TCP传输数据时，我们常用的方式就是用socket。

但当IP地址为\"\"的机器发送数据给\"\"的机器时，这一包TCP数据包里面的数据究竟是代表什么意思，接收端的IP地址为\"\"的机器该如何其解析这一个包的数据，这个问题就是交由传输层上面一层的协议来解决了，这就是应用层协议。当然，如果你的协议不想给普通的网络上的计算机解析时，你也可以自己去制定一些应用层的协议，这个无关紧要，传输层的目的只是把数据传达到目标机器上面就可以了。

我们日常的工作，娱乐中常常会碰到各种各样的应用层协议，比如当你打开一个网页时，这个图片显示在那个位置，这个按钮点下去是实现什么功能，这种都是由HTML超文本传输协议(英文:HyperTextTransferProtocol,缩写:HTTP)所约定的。这就保证了你网站中某个网页被任何一台设备请求时，这台设备可以正常的显示出来。除了HTTP，应用层协议还有很多，如DNS，FTP等，而我们今天的主角MQTT协议也是其中的一员。

为何物联网倾向于MQTT

既然我们既有的应用中已经有了那么多优秀的应用层协议，为何在物联网领域中偏偏MQTT大放异彩。其实选择MQTT协议也不是毫无根据的，MQTT 是一种轻量级的、灵活的网络协议，致力于为 IoT 开发人员实现适当的平衡：

这个轻量级协议可在严重受限的设备硬件和高延迟/带宽有限的网络上实现。

它的灵活性使得为 IoT 设备和服务的多样化应用场景提供支持成为可能。

大多数开发人员已经熟悉 HTTP Web 服务。那么为什么不让 IoT 设备连接到 Web 服务？设备可采用 HTTP 请求的形式发送其数据，并采用 HTTP 响应的形式从系统接收更新。这种请求和响应模式存在一些严重的局限性：

HTTP 是一种同步协议。客户端需要等待服务器响应。Web 浏览器具有这样的要求，但它的代价是牺牲了可伸缩性。在 IoT 领域，大量设备以及很可能不可靠或高延迟的网络使得同步通信成为问题。异步消息协议更适合 IoT 应用程序。传感器发送读数，让网络确定将其传送到目标设备和服务的最佳路线和时间。

HTTP 是单向的。客户端必须发起连接。在 IoT 应用程序中，设备或传感器通常是客户端，这意味着它们无法被动地接收来自网络的命令。

HTTP 是一种一对一的协议。客户端发出请求，服务器进行响应。将消息传送到网络上的所有设备上，不但很困难，而且成本很高，而这是 IoT 应用程序中的一种常见使用情况。

文章来源：《物联网技术》 网址: http://www.wlwjszz.cn/zonghexinwen/2020/0924/908.html