为何物联网倾向于MQTT？

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

网络的传输层和应用层

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

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

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

我们日常的工作，娱乐中常常会碰到各种各样的应用层协议，比如当你打开一个网页时，这个图片显示在那个位置，这个按钮点下去是实现什么功能，这种都是由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 是一种有许多标头和规则的重量级协议。它不适合受限的网络。

出于上述原因，大部分高性能、可扩展的系统都使用异步消息总线来进行内部数据交换，而不使用 Web 服务。

订阅/发布模型

有意思的是，这种MQTT协议的服务器，其实是比web服务器设计还要简单地多，因为它追求的是一种高效性的服务。MQTT主要进行消息收发的机制有点类似于我们公众号和各位读者之间的关系。

在现实的世界中，我和大家一样都类似于一个有一个的MQTT设备挂接在统一的一个服务器上面，大家出于对我们公众号的兴趣或者某种感情订阅了我们，而当每天我发文推送的时候，大家的手机里就会出现我推送的消息了，这个过程中，你获取我信息的方式被称为“订阅”，而我向这个公众号发布消息的行为就是“发布”。而大家可到我文章的时候，可以随意地向我留言，这个行为就是大家地“发布”行为，而我无时无刻守在某一篇推送面前看大家的留言，这就是一种“订阅”行为。在这个过程中，外部的所有信息都与我们无关，我们只是简单地以两个方向的信息流沟通着。MQTT中的消息传递机制也是基于“发布（Publish）”-“订阅（Subscribe）”的模型的。

MQTT具体的操作步骤为：

第一步：使用先获得一个MQTT服务器，然后新建一个MQTT通讯产品。

第二步：接着去连接这个服务器，连接服务器的两个重要的参数就是主机号（域名或者IP地址）和端口号。

第三步：如果使用的是第三方云服务器平台，它可能需要你使用产品ID和鉴权信息去登录这个设备，这两个在设备云的后台都能找到。

这三个步骤做完之后，你就可以对对应的主题订阅或者发布消息了。

我后面会专门整理一个文档来给大家演示一下如何来“白嫖”一个中国移动的设备云开放接入平台。

这三个步骤既适用于应用软件开发，也适用于单片机开发。在单片机开发时，如果你用AT指令和外部的WIFI模块通讯，那么一般模块都可以自带AT＋MQTT命令，这是最好的办法，可以极大地减少单片机的压力。或者你也可以直接获取TCP/IP传输层的数据，然后自己去解析这个MQTT，这就需要用户对MQTT协议要有一个很深的理解还要自己去解析Json数据，所以一般在做嵌入式设备时，一般推荐大家直接用现成带MQTT协议的模块，直接解析AT指令是比较方便的。

案例分析：

远程控制灯和获取当前房间温度。

关于这个案例，其实是MQTT最简单的一个应用，首先房间的嵌入式控制板主要通过WIFI连接到服务器，它既可以控制灯的开关，也可以采集温度。远在天边的终端设备是一台手机。

要保持通信正常，首先它们需要接入同一个MQTT服务器。

设备端的温度信息，是设备采集的，因此需要将采集来的数据发布到“温度”主题，而手机是获取这个温度信息的，因此需要来订阅这个“温度”主题。一旦设备端发送温度信息到“温度主题”，这个主题就会被手机所接收。

设备端的灯控，是设备执行的，因此需要订阅“灯开关”主题，而手机是控制灯的开关的，因此需要来对这个“灯开关”主题发布控制信息。一旦手机发送开灯信息到“灯开”关主题，这个主题就会被终端所接收，再去执行开灯命令。
责任编辑:pj