江苏龙网

  1. 首页 > 人文 > >

物联网|物联网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指令是比较方便的 。


推荐阅读


上一篇：手机淘宝|淘宝取消差评机制：这样对用户真的好吗？

下一篇：索尼|智障验证码发展简史