MQTT 协议的中心是 MQTT 服务器或代理 (broker) ,支持发布程序和订阅程序进行访问,如下图所示
MQTT拥有14种不同的消息类型:
MQTT是通过主题对消息进行分类的,本质上就是一个UTF-8的字符串,不过可以通过反斜杠表示多个层级关系。主题并不需要创建,直接使用就是了。
主题还可以通过通配符进行过滤。其中,+可以过滤一个层级,而#只能出现在主题最后表示过滤任意级别的层级。
举个例子:
building-b/floor-5:代表B楼5层的设备。
+/floor-5:代表任何一个楼的5层的设备。
building-b/#:代表B楼所有的设备。
注意,MQTT允许使用通配符订阅主题,但是并不允许使用通配符广播。
WILL主题也叫遗嘱消息,是一个特殊的主题。
客户端连接Broker的时候,附带一个will主题和will主题对应的内容。
当客户端与Broker断开连接时,Broker将该WILL主题的内容发送给相关的订阅者的遗嘱消息,这样订阅者就知道该客户端已经离线了。
以下情况下会发送 Will Message:
注:在客户端正常调用 disconnect 方法之后并不会被发送。
为了满足不同的场景,MQTT支持三种不同级别的服务质量(Quality of Service,QoS)为不同场景提供消息可靠性:
级别2所提供的不重不丢很多情况下是最理想的,不过往返多次的确认一定对并发和延迟带来影响。
级别1提供的至少一次语义在日志处理这种场景下是完全OK的,所以像Kafka这类的系统利用这一特点减少确认从而大大提高了并发。
级别0适合鸡肋数据场景,基本就没怎么用了。
客户端在连接的时候可以设置clean session,如果设置成true说明在设备离线后broker不保存,设置成false说明在设备离线后broker保存消息,等上线的时候就发送给他。
客户端在连接Broker的时候,会指定心跳的时候。连接成功之后,客户端就按照这个心跳时间定时发送心跳数据给Broker,如果Broker在15T时间内没有收到客户端的心跳数据,则判定改设备已经离线,发送WILL主题广播告诉别人该设备已离线。
MQTT可以使用SSL加密方式传输,设备的认证有单向认证和双向认证两种:
MQTT除了有SSL加密之外,对于连接也有账号密码的授权,只要账号密码正确的才可以连接成功。
MQTT 协议和mosquitto: >
MQTT跟WebSocket关系不大。他们不是在一个层级的。
WebSocket 很多网站使用轮询实现推送技术。轮询是在特定的的时间间隔(比如1秒),由浏览器对服务器发出>
Comet使用了AJAX改进了轮询,可以实现双向通信。但是Comet依然需要发出请求,而且在Comet中,普遍采用了长链接,这也会大量消耗服务器带宽和资源。
于是,WebSocket协议应运而生。 浏览器通过 JavaScript 向服务器发出建立 WebSocket 连接的请求,连接建立以后,客户端和服务器通过 TCP 连接直接交换数据。WebSocket 连接本质上是一个 TCP 连接。
WebSocket在数据传输的稳定性和数据传输量的大小方面,具有很大的性能优势。Websocketorg 比较了轮询和WebSocket的性能优势:
>
Use Case A: 1,000个客户端每秒接受一个message,网络吞吐量 (21,000)=2,000 bytes = 16,000 每秒bits
Use Case B: 10,000个客户端每秒接受一个message,网络吞吐量 (210,000)=20,000 bytes = 160,000 每秒bits
Use Case C: 100,000个客户端每秒接受一个message,网络吞吐量 (2100,000)=200,000 bytes = 1,600,000 每秒bits
MQTT 协议是为大量计算能力有限,且工作在低带宽、不可靠的网络的远程传感器和控制设备通讯而设计的协议,它具有以下主要的几项特性:
非常小的通信开销(最小的消息大小为 2 字节),小型传输,开销很小(固定长度的头部是 2 字节),协议交换最小化,以降低网络流量。
支持各种流行编程语言(包括 C,Java,Ruby,Python 等等)且易于使用的客户端;
使用发布 / 订阅消息模式,提供一对多的消息发布,解除应用程序耦合。
对负载内容屏蔽的消息传输。
使用 TCP/IP 提供网络连接。
有三种消息发布服务质量,让消息能按需到达目的地,适应在不稳定工作的网络传输需求 :
"至多一次",消息发布完全依赖底层 TCP/IP 网络。会发生消息丢失或重复。这一级别可用于如下情况,环境传感器数据,丢失一次读记录无所谓,因为不久后还会有第二次发送。
"至少一次",确保消息到达,但消息重复可能会发生。
"只有一次",确保消息到达一次。这一级别可用于如下情况,在计费系统中,消息重复或丢失会导致不正确的结果。
以原生支持“MQTT协议”切入物联网战场原生支持MQTT协议成为百度开放云推出的物联网服务一大特点。首先需要解读的是,为什么百度开放云会选择“MQTT协议”?
百度开放云支持的MQTT(Message Queuing Telemetry Transport)是国际物联网标准协议,旨在为低带宽和不稳定的网络环境中的物联网设备提供可靠的网络服务,可以适应各种物联网应用场景。
相对于其它标准协议,MQTT属于轻量级双向消息传输协议,主要优势是开源、可靠、轻巧、简单。MQTT的传输格式非常精小,最小的数据包只有2个比特,且无应用消息头。MQTT可以保证消息的可靠性,它包括三种不同的服务质量(最多只传一次、最少被传一次、一次且只传一次),如果客户端意外掉线,可以使用“遗愿”发布一条消息,同时支持持久订阅。
MQTT在物联网应用中的主要优势有:一,可靠传输。MQTT可以保证消息可靠安全的传输,并可以与企业应用简易集成;二,消息推送。支持消息实时通知、丰富的推送内容、灵活的Pub-Sub以及消息存储和过滤。三,低带宽、低耗能、低成本。占用移动应用程序带宽小,并且带宽利用率高,耗电量较少。
MQTT的优势还表现在安全性。安全设计对于物联网项目而言,是需要非常重视的问题,但是却常常容易被工程师所轻视。今年央视315晚会,揭秘了无人机、智能摄像头、智能POS机、智能汽车、洗衣机、电烤箱、智能插座等智能家居存在的三大安全隐患——泄露隐私、财产损失、甚至危及生命安全。而MQTT协议则可以提供多层次的安全特性,在传输层上可以使用TLS加密;在应用层提供了客户标识(Client Identifier)以及用户名密码,不但传输的内容是二进制字节,而且还受惠于传输层的TLS加密。
MQTT开放协议已有17年历史,先期在2014年被国际标准化组织定义为物联网的推荐协议。在应用层传输协议这个领域,它已经走在了其它协议的前面。正因为MQTT的综合优势非常突显,业界不少专家认为,MQTT非常适合各种物联网场景,有望是未来最主流的物联网标准协议。
原生支持“MQTT协议”背后旨在推动物联网标准化
接下来的问题是,那么为什么百度开放云要在国内率先成为原生支持MQTT协议的公有云服务商?
在笔者看来,首先,这和百度开放云在物联网行业的核心目标有着紧密的关系。在去年的“百度世界2015”开放云论坛上,百度开放云高层曾对物联网的发展战略做出阐述,指出:打破行业与行业之间的界限,以“连接人与服务”为核MQTT服务器。物联网指的是将无处不在的末端设备和设施,物联网的前端核心设备是MQTT服务器,使用MQTT协议进行数据通讯可以免去常规CS架构中服务器搭建较为复杂的问题。物联网是指通过信息传感设备,按约定的协议,将任何物体与网络相连接,物体通过信息传播媒介进行信息交换和通信,以实现智能化识别、定位、跟踪、监管等功能。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)