MQTT分析.docx
- 文档编号:231336
- 上传时间:2022-10-07
- 格式:DOCX
- 页数:9
- 大小:316.59KB
MQTT分析.docx
《MQTT分析.docx》由会员分享,可在线阅读,更多相关《MQTT分析.docx(9页珍藏版)》请在冰豆网上搜索。
MQTT分析
1.协议详解
1.1.概述
MQ遥测传输(MQTT)是轻量级的、基于代理的发布/订阅消息传输协议,此协议的设计开放、简单、轻量、易于实现。
这些特点使得此协议非常适用于受限环境。
例如,但不仅限于此:
网络代价昂贵,带宽低、不可靠。
在嵌入设备中运行,处理器和内存资源有限。
该协议的特点包括:
n1使用发布/订阅消息模式,提供一对多的消息分发,解除了应用程序之间的耦合。
n2对负载内容屏蔽的消息传输。
n3使用TCP/IP提供基础的网络连接。
n4有三种消息传递服务质量:
²“Atmostonce”“至多一次”,消息发布完全依赖于底层的TCP/IP网络,会发生消息丢失或重复。
这一级别可用于如下情况,如环境传感器数据,这种情况下,丢失一次读记录无所谓,因为第二个数据的发布紧跟其后。
²Atleaseonce“至少一次”,确保消息到达,但可能发生消息重复。
²Exactlyonce“只有一次”,确保消息只到达一次。
这一级别可用于如下情况,如计费系统中,消息重复或丢失会导致不正确的收费问题。
n5小型传输,开销很小(固定长度的头部是2字节),协议交换最小化,以降低网络流量。
n6提供一种机制,使得客户端异常中断时,能够使用LastWill和Testament特性通知有关各方。
1.2.消息格式
每个MQTT命令消息的消息头都包含一个固定的报头。
有些消息需要一个可变的报头和一个payload。
1.1.1固定报头
每个MQTT命令消息的消息头都包含一个固定的报头。
下表显示了固定的报头格式:
Byte1
包含MessageType(消息类型)和Flags(DUP,QoS级别,RETAIN)字段
Byte2
(至少一个字节)包含RemainingLength(剩余长度)字段。
这些字段将会在以下各部分说明。
所有数据值都是按照bigi-endian顺序:
高端字节跟在低端字节之前。
一个16位的字按照如下顺序:
最高有效位(MSB)在前,最低有效位(LSB)在后。
详见MQTTV3.1
1.1.2可变报文头
1.1.3Payload
1.3.Commandmessages
1.1.4CONNECT-客户端向服务器请求建立连接
当客户端向服务器建立一个TCP/IP连接时,协议层会话必须使用一个CONNECTflow建立。
1.1.5CONNACK–连接请求的确认
CONNACKmessage是服务器为了响应来自客户端的CONNECT请求而发送的消息.
1.1.6PUBLISH-发布消息
为向感兴趣的订阅者分发消息,客户端向服务器发布了一条PUBLISH消息。
每一条PUBLISH消息都与一个主题名相关联(主题名又称Subject或Channel)。
这是一个分层的名称空间,定义了一个信息源分类,订阅者可以注册一个兴趣。
一个发布到某个特定主题名的消息会被传递给订阅了该主题的在线订阅者。
如果客户端订阅了一个或多个主题,任何发布到这些主题上的消息都会作为PUBLISH消息被服务器发送给客户端。
1.1.7PUBACK-发布确认
PUBACK消息是对QoS级别为1的PUBLISH消息的响应。
一个PUBACK消息可以是服务器为了响应来自发布客户端的PUBLISH消息而发送,也可以是订阅者为了响应来自服务器的PUBLISH消息而发送的。
1.1.8PUBREC–确保发布被收到
PUBREC消息是用来响应QoS级别为2的PUBLISH消息的。
这是QoS级别为2的protocolflow(协议流)的第二个消息。
PUBREC消息由服务器发送以响应发布客户端的PUBLISH消息,或者由订阅者发送以响应来自服务器的PUBLISH消息。
(QoS级别为2时,当客户端发布一条消息,服务端收到后要给出PUBREC响应;订阅者收到发布的消息也要给出PUBREC响应,确保发布过程的各个环节)
1.1.9PUBREL-AssuredPublishRelease
PUBREL消息是QoS级别为2的协议流的第3个消息。
PUBREL消息用用来响应PUBREC消息的,可以是发布者对来自服务器的PUBREC的响应,也可以是服务器对来自订阅者的PUBREC的响应。
(双方互相确认,确保发布的消息到了server,也到了各个订阅者)
1.1.10PUBCOMP-确保发布完成
这是QoS基本为2的协议流的第4个,也是最后一个消息。
这个消息是对PUBREL消息的响应。
1.1.11SUBSCRIBE-订阅主题(可多个)
客户端用SUBSCRIBE消息可以向服务器注册一个或多个感兴趣的主题名。
向这些主题发布的消息会被服务器以PUBLISH消息的形式传递给订阅者。
SUBSCRIBE消息还指定了QoS的级别,以指导订阅者接收发布的消息。
1.1.12SUBACK–订阅确认
服务器给客户端发送一个SUBACK,以证明已经收到了SUBSCRIBE消息。
SUBACK消息包含一系列的授权QoS级别,SUBACK消息中的授权QoS级别的顺序与相应的SUBSCRIBE消息中的主题名的排列顺序是一致的。
1.1.13UNSUBSCRIBE–从主题名上取消订阅
UNSUBSCRIBE消息是由客户端向服务端发送,用于从主题名上取消订阅。
1.1.14UNSUBACK-取消订阅确认
服务器发送UNSUBACK消息用以确认已经收到了UNSUBSCRIBE消息.
1.1.15PINGREQ-PING请求
PINGREQ消息是一个从客户端发送到服务器的“areyoualive?
”消息。
(类似心跳包)更多详细情况参看KeepAlivetimer。
1.1.16PINGRESP–PING响应
PINGRESP消息是从服务器发送给PINGREQ消息的响应,意思是“yes,Iamalive”。
更多细节参看KeepAlivetimer
1.1.17DISCONNECT-断开连接通知
DISCONNECT消息是从客户端发送到服务器,以表明它即将关闭TCP/IP连接。
这种考虑到了cleandisconnection(干净的断开),而不仅仅是拔掉网线。
如果客户端连接时使用了cleansession标志,那么这个客户端之前所维护的信息将会被丢弃。
(类似非持久)
服务端收到DISCONNECT后,不应该依赖客户端来关闭TCP/IP连接。
1.4.Flows协议流
1.1.18QualityofServicelevelsandflows
MQTT是根据定义在QoS中的等级传递消息的。
等级描述如下:
1QoSlevel0:
Atmostoncedelivery(最多一次)
(类似无需应答的发送)消息的传递完全依赖底层的TCP/IP网络,协议里没有定义应答和重试。
消息要么只会到达服务端一次,要么根本没有到达。
2.QoSlevel1:
Atleastoncedelivery(至少传递一次)
服务器的消息接收由PUBACK消息进行确认。
如果通信链路异常、发送设备异常,或者指定时间内没有收到确认消息,发送端会重发这条在消息头中设置DUP位的消息。
消息到达服务器至少一次。
SUBSCRIBE和UNSUBSCRIBE消息使用QoS级别1。
QoS级别为1的消息的消息头中都有一个MessageID。
3.QoSlevel2:
Exactlyoncedelivery(只传递一次)
在QoSlevel1之上的附加协议流能够确保重复的消息不会被传递给正在接收的应用程序。
当不允许出现重复消息时,这就是最高级别的传递。
这会增加网络流量,但是通常来讲是可接受的,因为消息内容很重要。
1.1.19Messagedeliveryretry
尽管TCP通常能够保证数据包的传递,在某些特定场景下,MQTT消息可能会收不到。
可能无法接收MQTT消息。
在这种场景下,MQTT消息会期望有一个响应(QoS>0PUBLISH,PUBREL,SUBSCRIBE,UNSUBSCRIBE),如果响应在特定时间内没有收到,发送者可以重试发送。
发送者应该在消息上设置DUP标识。
重试的次数应该是一个可配置的选项。
然而,应该保证消息在发送过程中不会超时,例如,在一个网速很慢的网上发送一个大消息所花费的时间自然会比在快速网络上发送一个小消息所花费的时间长。
多次重试发送一个超时的消息经常会使事情变得更糟,所以,在多次重试的情况下,应当采用增加超时时间值的策略。
当客户端重连,如果没有被标记为干净会话(cleansession),那么客户端和服务端都应该重传任何之前正在传递(in-flight)中的消息。
除了“重连”这种重试行为,客户并没有被要求重传消息。
然而,broker应该重试任何未确认的消息。
1.1.20Messageordering
Message顺序受到很多因素的影响,包括:
客户端允许同时运行多少in-flightPUBLISH流,客户端的是单线程还是多线程。
为了讨论的目的,假设客户端的某个数据包“MQTTV3.1ProtocolSpecification”在向网络上写和从网络上读的时间点上是单线程的,为了保证消息的顺序,必须保证每个消息传递流的存储都是按照想要的顺序。
2.推送方案
2.1.C2DM(Cloudto Device Messaging)
Android Cloud to Device Messaging (C2DM)是一个用来帮助开发者从服务器向Android应用程序发送数据的服务。
该服务提供了一个简单的、轻量级的机制,允许服务器可以通知移动应用程序直接与服务器进行通信,以便于从服务器获取应用程序更新和用户数据。
C2DM服务负责处理诸如消息排队等事务并向运行于目标设备上的应用程序分发这些消息。
但这个服务存在很大的问题:
1)C2DM内置于Android的2.2系统上,无法兼容老的1.6到2.1系统;
2)C2DM需要依赖于Google官方提供的C2DM服务器,由于国内的网络环境,这个服务经常不可用,如果想要很好的使用,我们的App Server必须也在国外,这个恐怕不是每个开发者都能够实现的;
3)C2DM要求用户拥有Gmail账号,而Gmail在国内并不普及
有了上述三个使用及普及上的制约,我们最终放弃了这个方案,而采用MQTT协议或XMPP协议实现Android推送。
2.2.XMPP
XMPP(可扩展通讯和表示协议)是基于可扩展标记语言(XML)的协议,它用于即时消息(IM)以及在线探测。
这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息。
此Demo有待解决问题:
A、 若server端重启,client怎么实现有效的重连接。
我在项目中利用了AndroidPN,就是server重启,需要重启client,才可以保证push成功。
B、 只是完成Android的Push功能使用XMPP协议感觉很笨重。
XPMM有将近60%的信息冗余量。
C、 目前源码功能Service和Application没有分离,即Application被关闭Service也随之销毁。
D、 XPMM采用的是长连接,若客户端进入休眠状态连接将会断开。
AndroidPN环境
AndroidPN实现了从服务器到android移动平台的文本消息推送。
这里先简单说一下androidPN的安装过程。
下载androidpn-client-0.5.0.zip和androidpn-server-0.5.0-bin.zip
网址:
h
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- MQTT 分析