IoTShare

MQTT初探

MQTT从本科开始就已经早有耳闻,一直没有去研究它,最近想自己搭一套开源的物联网云平台,于是仔细研究起来。

MQTT是一个订阅/发布机制的轻量级的协议,最初是由IBM设计的,现在已经逐渐成为物联网主流的通信协议。就我接触的,阿里云用MQTT设计了消息队列,百度云则用来做了天工物联系统。

基本架构

这里有几个概念需要进行区分,MQTT协议MQTT客户端,以及服务端broker(也被称为代理服务器等)。事实上,我们常说的MQTT只是一个协议标准,类似于HTTP,只是来告诉通信的双方数据应该如何组织,如何解析,比如规定0代表成功,-1代表失败。既然有了协议,那么就像HTTP一样,需要有能够解析MQTT的软件,这样的软件24小时不休息,运行在公网上,也就是我们俗称的服务器。MQTT的服务器其实只是一个代理,我们发送的数据需要先发往这个代理,然后这个代理需做相应的处理(例如持久化、统计、检测客户端是否在线等等),然后再发往相应的客户端。其实按道理说我们可以直接可以客户端与客户端1对1或者1对多通信(哈哈,就像BLE或者ZigBee),但是这样做的弊端有很多,客户端不可能像服务端一样一直在线,而且一般情况下客户端不能主动去访问另外一个客户端(移动通信的机制决定的)。所以设置一个服务端是非常必要的,它就像一个邮局一样,所有的客户端都通过TCP连接到服务端,然后我向邮局订阅我感兴趣的消息,当客户端发布消息时这个消息会先发到邮局,邮局再发布到订阅者手里。

举个栗子

下面这个是官网的例子。比如我现在有三个客户端,客户端A会发布温度数据,客户端B、C订阅了该消息。
febarticle2.1.png

当客户端A发布数据时,它首先会把数据发向代理服务器,然后代理服务器将这个温度消息发给订阅者B和C。
febarticle2.2.png

关于topic

MQTT将每个订阅称为主题,即topic,例如上文中的温度数据。那么这个topic在协议中是如何匹配的呢?

MQTT的主题采用的类似分层的方式,比如 kitchen/oven/temperature,用/分割一层topic。如果我要订阅temperature,那么我需要填写的topic是kitchen/oven/temperature。除此之外,MQTT支持通配符的方式进行一类topic的订阅。#可以代表这一层以及向下的所有层,比如kitchen/#订阅的是kitchen主题这一层下的所有主题,不支持放在中间进行匹配,如kitchen/#/temperature。而+仅表示当前一层,比如kitchen/+表示以kitchen开头的下一层的主题,可以放在中间进行某一层的通配,例如kitchen/+/temperature是合法的,可以订阅到kitchen/oven/temperature这个topic,但不能订阅到kitchen/oven/next/temperature

本原创文章未经允许不得转载 | 当前页面:IoTShare » MQTT初探

评论