MQTT分析.docx

MQTT分析 1. 协议详解 1.1. 概述MQ遥测传输（MQTT）是轻量级的、基于代理的发布/订阅消息传输协议，此协议的设计开放、简单、轻量、易于实现。这些特点使得此协议非常适用于受限环境。例如，但不仅限于此：网络代价昂贵，带宽低、不可靠。在嵌入设备中运行，处理器和内存资源有限。该协议的特点包括：n 1 使用发布/订阅消息模式，提供一对多的消息分发，解除了应用程序之间的耦合。n 2 对负载内容屏蔽的消息传输。n 3 使用TCP/IP提供基础的网络连接。n 4 有三种消息传递服务质量： “At most once”“至多一次”，消息发布完全依赖于底层的TCP/IP网络，会发生消息丢失或重复。这一级别可用于如下情况，如环境传感器数据，这种情况下，丢失一次读记录无所谓，因为第二个数据的发布紧跟其后。 At lease once“至少一次”，确保消息到达，但可能发生消息重复。 Exactly once“只有一次”，确保消息只到达一次。这一级别可用于如下情况，如计费系统中，消息重复或丢失会导致不正确的收费问题。n 5 小型传输，开销很小（固定长度的头部是2字节），协议交换最小化，以降低网络流量。n 6 提供一种机制，使得客户端异常中断时，能够使用LastWill和Testament特性通知有关各方。1.2. 消息格式每个MQTT命令消息的消息头都包含一个固定的报头。有些消息需要一个可变的报头和一个payload。1.1.1 固定报头每个MQTT命令消息的消息头都包含一个固定的报头。下表显示了固定的报头格式：Byte 1包含Message Type（消息类型）和Flags（DUP，QoS级别，RETAIN）字段Byte 2（至少一个字节）包含Remaining Length（剩余长度）字段。这些字段将会在以下各部分说明。所有数据值都是按照bigi-endian顺序：高端字节跟在低端字节之前。一个16位的字按照如下顺序：最高有效位（MSB）在前，最低有效位（LSB）在后。详见MQTT V 可变报文头1.1.3 Payload1.3. Command messages1.1.4 CONNECT- 客户端向服务器请求建立连接当客户端向服务器建立一个TCP/IP连接时，协议层会话必须使用一个CONNECT flow建立。1.1.5 CONNACK 连接请求的确认CONNACK message是服务器为了响应来自客户端的CONNECT请求而发送的消息.1.1.6 PUBLISH-发布消息为向感兴趣的订阅者分发消息，客户端向服务器发布了一条PUBLISH消息。每一条PUBLISH消息都与一个主题名相关联（主题名又称Subject或Channel）。这是一个分层的名称空间，定义了一个信息源分类，订阅者可以注册一个兴趣。一个发布到某个特定主题名的消息会被传递给订阅了该主题的在线订阅者。 如果客户端订阅了一个或多个主题，任何发布到这些主题上的消息都会作为PUBLISH消息被服务器发送给客户端。1.1.7 PUBACK-发布确认PUBACK消息是对QoS级别为1的PUBLISH消息的响应。一个PUBACK消息可以是服务器为了响应来自发布客户端的PUBLISH消息而发送，也可以是订阅者为了响应来自服务器的PUBLISH消息而发送的。1.1.8 PUBREC确保发布被收到PUBREC消息是用来响应QoS级别为2的PUBLISH消息的。这是QoS级别为2的protocol flow（协议流）的第二个消息。PUBREC消息由服务器发送以响应发布客户端的PUBLISH消息，或者由订阅者发送以响应来自服务器的PUBLISH消息。 （QoS级别为2时，当客户端发布一条消息，服务端收到后要给出PUBREC响应；订阅者收到发布的消息也要给出PUBREC响应，确保发布过程的各个环节）1.1.9 PUBREL-Assured Publish ReleasePUBREL消息是QoS级别为2的协议流的第3个消息。 PUBREL消息用用来响应PUBREC消息的，可以是发布者对来自服务器的PUBREC的响应，也可以是服务器对来自订阅者的PUBREC的响应。 （双方互相确认，确保发布的消息到了server，也到了各个订阅者）1.1.10 PUBCOMP-确保发布完成这是QoS基本为2的协议流的第4个，也是最后一个消息。这个消息是对PUBREL消息的响应。1.1.11 SUBSCRIBE-订阅主题（可多个）客户端用SUBSCRIBE消息可以向服务器注册一个或多个感兴趣的主题名。向这些主题发布的消息会被服务器以PUBLISH消息的形式传递给订阅者。SUBSCRIBE消息还指定了QoS的级别，以指导订阅者接收发布的消息。1.1.12 SUBACK 订阅确认 服务器给客户端发送一个SUBACK，以证明已经收到了SUBSCRIBE消息。 SUBACK消息包含一系列的授权QoS级别，SUBACK消息中的授权QoS级别的顺序与相应的SUBSCRIBE消息中的主题名的排列顺序是一致的。1.1.13 UNSUBSCRIBE 从主题名上取消订阅UNSUBSCRIBE消息是由客户端向服务端发送，用于从主题名上取消订阅。1.1.14 UNSUBACK-取消订阅确认服务器发送UNSUBACK消息用以确认已经收到了UNSUBSCRIBE消息.1.1.15 PINGREQ-PING 请求 PINGREQ消息是一个从客户端发送到服务器的“are you alive?”消息。（类似心跳包） 更多详细情况参看 Keep Alive timer。1.1.16 PINGRESP PING响应PINGRESP消息是从服务器发送给PINGREQ消息的响应，意思是“yes ，I am alive”。 更多细节参看Keep Alive timer1.1.17 DISCONNECT-断开连接通知DISCONNECT消息是从客户端发送到服务器，以表明它即将关闭TCP/IP连接。这种考虑到了clean disconnection（干净的断开），而不仅仅是拔掉网线。 如果客户端连接时使用了clean session标志，那么这个客户端之前所维护的信息将会被丢弃。（类似非持久） 服务端收到DISCONNECT后，不应该依赖客户端来关闭TCP/IP连接。1.4. Flows协议流 1.1.18 Quality of Service levels and flowsMQTT是根据定义在QoS中的等级传递消息的。等级描述如下：1 QoS level 0: At most once delivery（最多一次）(类似无需应答的发送) 消息的传递完全依赖底层的TCP/IP网络，协议里没有定义应答和重试。消息要么只会到达服务端一次，要么根本没有到达。2. QoS level 1: At least once delivery（至少传递一次）服务器的消息接收由PUBACK消息进行确认。如果通信链路异常、发送设备异常，或者指定时间内没有收到确认消息，发送端会重发这条在消息头中设置DUP位的消息。消息到达服务器至少一次。SUBSCRIBE和UNSUBSCRIBE消息使用QoS级别1。QoS级别为1的消息的消息头中都有一个Message ID。3. QoS level 2: Exactly once delivery（只传递一次）在QoS level 1之上的附加协议流能够确保重复的消息不会被传递给正在接收的应用程序。当不允许出现重复消息时，这就是最高级别的传递。这会增加网络流量，但是通常来讲是可接受的，因为消息内容很重要。1.1.19 Message delivery retry尽管TCP通常能够保证数据包的传递，在某些特定场景下，MQTT消息可能会收不到。可能无法接收MQTT消息。在这种场景下，MQTT消息会期望有一个响应（QoS0 PUBLISH, PUBREL, SUBSCRIBE, UNSUBSCRIBE），如果响应在特定时间内没有收到，发送者可以重试发送。发送者应该在消息上设置DUP标识。重试的次数应该是一个可配置的选项。然而，应该保证消息在发送过程中不会超时，例如，在一个网速很慢的网上发送一个大消息所花费的时间自然会比在快速网络上发送一个小消息所花费的时间长。多次重试发送一个超时的消息经常会使事情变得更糟，所以，在多次重试的情况下，应当采用增加超时时间值的策略。当客户端重连，如果没有被标记为干净会话（clean session），那么客户端和服务端都应该重传任何之前正在传递（in-flight）中的消息。除了 “重连”这种重试行为，客户并没有被要求重传消息。然而，broker应该重试任何未确认的消息。1.1.20 Message orderingMessage顺序受到很多因素的影响，包括：客户端允许同时运行多少in-flight PUBLISH流，客户端的是单线程还是多线程。为了讨论的目的，假设客户端的某个数据包“MQTT V3.1 Protocol Specification”在向网络上写和从网络上读的时间点上是单线程的，为了保证消息的顺序，必须保证每个消息传递流的存储都是按照想要的顺序。2. 推送方案2.1. C2DM（Cloud toDeviceMessaging）AndroidCloudtoDeviceMessaging(C2DM)是一个用来帮助开发者从服务器向Android应用程序发送数据的服务。该服务提供了一个简单的、轻量级的机制，允许服务器可以通知移动应用程序直接与服务器进行通信，以便于从服务器获取应用程序更新和用户数据。C2DM服务负责处理诸如消息排队等事务并向运行于目标设备上的应用程序分发这些消息。但这个服务存在很大的问题：1）C2DM内置于Android的2.2系统上，无法兼容老的1.6到2.1系统; 2）C2DM需要依赖于Google官方提供的C2DM服务器，由于国内的网络环境，这个服务经常不可用，如果想要很好的使用，我们的AppServer必须也在国外，这个恐怕不是每个开发者都能够实现的;3）C2DM要求用户拥有Gmail账号，而Gmail在国内并不普及有了上述三个使用及普及上的制约，我们最终放弃了这个方案，而采用MQTT协议或XMPP协议实现Android推送。2.2. XMPPXMPP(可扩展通讯和表示协议)是基于可扩展标记语言（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网址：/projects/androidpn/ 解压两个包，Eclipse导入client，配置好目标平台，打开raw/perties文件，apiKey=1234567890xmppHost=xmppPort=5222如果是模拟器来运行客户端程序,把xmppHost配置成 (模拟器把认为是所在主机的地址，是模拟器本身的回环地址).xmppPort=5222 是服务器的xmpp服务监听端口运行androidpn-server-0.5.0binrun.bat启动服务器，从浏览器访问:7070/index.do (androidPN Server有个轻量级的web服务器，在7070端口监听请求，接受用户输入的文本消息)运行客户端，客户端会向服务器发起连接请求，注册成功后，服务器能识别客户端，并维护和客户端的IP长连接进入Notifications界面，输入消息发送模拟器客户端接受到server推送的消息2.3. MQTTMQTT是一个轻量级的消息发布/订阅协议，它是实现基于手机客户端的消息推送服务器的理想解决方案。附件中ReallySmallMessageBroker(RSMB)是一个简单的MQTT代理，由IBM提供。缺省打开1883端口，应用程序当中，它负责接收来自服务器的消息并将其转发给指定的移动设备。1MQTT机制2 MQTT优缺点使用LastWill和Testament特性通知有关各方客户端异常中断的机制。小型传输，开销很小（固定长度的头部是2字节），协议交换最小化，以降低网络流量。MQTT应用的是短连接利用MQTT协议，broker属于小型代理服务，连接数有上限（暂不明确具体上线），到了一定程度后就无法连接了，这将导致消息很难发送出去。3 长连接和短连接的选择长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况。每个TCP连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作那么处理速度会降低很多，所以每个操作完后都不断开，下次处理时直接发送数据包就OK了，不用建立TCP连接。例如：数据库的连接用长连接，如