developerWorks 社区
本文介绍了如何通过 WebSphere MQ Telemetry，使用 MQTT 协议，并基于 WebSocket JavaScript API 开发实现移动终端之间，以及后端系统到移动终端之间的数据交互应用，从而最终实现移动领域的推送服务。由于使用了 WebSocket JavaScript API，使得此移动推送解决方案具有了很好的移动平台移植性。
, 高级软件工程师, IBM
向荣，IBM 中国开发中心 WebSphere MQTT/ MessageSight 高级软件工程师，之前，从事 WebSphere Adapter for Oracle E-Business Suite 的开发和测试工作。专注于 Oracle EBS 的各种接口的企业信息系统间的业务整合。目前，从事 WebSphere MQ Telemetry 的开发和测试工作。撰写过多篇技术文档和 IBM 红皮书。专注于物联网（IOT）连通解决方案，移动推送服务解决方案。
, 高级软件工程师, IBM
张超，IBM 中国开发中心 WebSphere MQ LLM 高级软件工程师。之前多年一直从事云计算方面的技术工作 . 目前，从事 WebSphere MQ Low Latency Messaging 的开发和测试工作 , 专注于低延时高性能交易技术，曾参与香港交易所，深圳证券交易所，大连商品交易所、郑州商品交易所，台湾交易所等重要客户的有关项目的技术支持。他撰写了一本 IBM MQ LLM 产品红皮书 . 现关注移动互联领域方面的新技术。
, 软件开发经理, IBM
金千里，现任 IBM 中国开发中心 WebSphere Connectivity 开发经理， 主要关注云计算集成，消息中间件 MQ，物联网的互联，以及 SOA 企业服务总线等领域。
WebSphere MQ Telemetry Transport 简介WebSphere MQ Telemetry Transport (MQTT) 是一项异步消息传输协议，是 IBM 在分析了他们的客户在其业务中使用 WebSphere MQ 消息传递的情况（包括通过它传递数据）之后专门为物联网所定制的重要的轻量级消息传输协议。IBM 发现，数据经常是在企业外部的远程位置生成的，而且数据在从远程位置到达企业之前通常要经历一个复杂的过程。这时往往将数据人工输入计算机，然后只能通过 WebSphere MQ Enterprise 消息传递系统传输。而 MQTT 的开发将 WebSphere MQ 消息传递的应用范围延伸到这些远程位置。WebSphere MQ 遥测传输 (MQTT) 是轻量级基于代理的发布 / 订阅的消息传输协议，设计思想是开放、简单、轻量、易于实现。这些特点使它适用于受限环境。例如，但不仅限于此：网络代价昂贵，带宽低、不可靠。在嵌入设备中运行，处理器和内存资源有限。该协议的特点有：使用发布 / 订阅消息模式，提供一对多的消息发布，解除应用程序耦合。对负载内容屏蔽的消息传输。使用 TCP/IP 提供网络连接。有三种消息发布服务质量：
"至多一次"，消息发布完全依赖底层 TCP/IP 网络。会发生消息丢失或重复。这一级别可用于如下情况，环境传感器数据，丢失一次读记录无所谓，因为不久后还会有第二次发送。"至少一次"，确保消息到达，但消息重复可能会发生。"只有一次"，确保消息到达一次。这一级别可用于如下情况，在计费系统中，消息重复或丢失会导致不正确的结果。小型传输，开销很小（固定长度的头部是 2 字节），协议交换最小化，以降低网络流量。使用 Last Will 和 Testament 特性通知有关各方客户端异常中断的机制。推送服务推送服务表现为客户端能自动收到服务器发送过来的数据和信息。其目的都是为了给最终客户方便有效地发送最新消息或者数据。而且推送的模式对以前的数据访问方式提供很好的补充和发展。首先，给最终用户带来了很好的使用体验，可以实时的获取自己感兴趣的信息，与此同时，给服务器端的应用商，也提供了更为便捷和主动的数据，服务发布方式，使得应用商能够控制信息发布的频率和时间，从而能更精准的投送的最终用户。推送服务本质上是服务器主动将消息，数据发送到客户端，而不是客户端主动去服务器请求数据。这种推送只需要客户端与服务器连接后，在有数据的情况下，服务器端马上将数据发送到客户端。这里的客户端可以是多种类型的，比如比较常见的浏览器，移动应用等等。推送服务的实现方式大致可分为 Poll 和 Push 模式。Poll 模式Poll 模式，本质上是"伪推送"模式，或者叫短轮询模式。是客户端通过设定固定的时间间隔，然后在时间间隔到达后，客户端主动向服务器发送请求，去更新是否有新数据。这种模式的特点是，客户端需要不停的轮询访问服务器获取信息，其时间间隔设定无法真正体现实时推送，间隔太长容易导致信息不能实时的更新，间隔太短，客户端需要发送很多不必要的连接请求，耗费很多网络流量和服务器开销。比如在移动终端上，此类模式会在设备电能消耗，网络流量使用方面存在很多瓶颈。Push 模式Push 模式，一般意义上使用长连接去建立一个客户端到服务器的双向数据通道，只要在连接建立后，一旦一方有数据更新，就可以马上通过双向的数据通道向对方发送数据，平时在没有数据时，通过一些心跳等机制维持通道连接。Push 模式的特点，简化的客户端的开发，数据能近乎实时的发送到对方。但其在设备资源消耗和网络流量控制方面，根据其使用的不同协议会有很大不同，特别是在移动推送领域，长连接对移动设备电量和网络流量的消耗要求较高。同时，由于需要维护长连接，对服务器在高并发连接的处理能力和性能也有很高要求。移动推送服务推送服务在很多领域都有发展，但特别在移动领域，由于其飞速发展，给推送服务带来了很多新的机遇和挑战。首先，移动市场规模越来越大，终端种类和数量越来越多，使得推送服务的的重要性越来越凸显；其次，传统的"伪推送"模式已越来越不能满足其需要，需要发展新的推送的技术，这促使了很多新的协议和框架的出现；但是，由于移动领域的终端设备和网络情况的特点，对推送的协议和框架又提出了新的挑战，比如：移动终端的计算和存储资源的限制，移动终端的电量消耗的限制，移动网络流量和成本的控制等等。主流的移动推送解决方案如下：SMS 短信作为传统的消息通讯，在新型移动环境下，在网络成本方面的考量使其地位有逐渐边缘化的趋势。HTTP 轮询使用定时的 HTTP 轮询方式，及客户端在一定的时间间隔里去重复向服务器请求数据更新，属于"伪推送"，由于其协议复杂冗余，轮询间隔的不准确，耗费了不必要的流量，增加了终端用户网络成本等因素，现有的这种方式已经不适合做移动推送服务。XMPPXMPP 是基于 XML 的通讯协议，此协议已基本上完成了标准化，成熟，强大，可扩展性强。但正是由于其协议复杂，冗余的设计，成为其在移动设备上短板，比如协议的复杂带来其协议栈的耗电增加，冗余的设计使得网络流量偏大，用户成本增加。私有厂商协议和平台私有厂商推出的推送服务，由于其协议私有，其传输效率和质量上无法量化和考证，而且还往往无法实现跨平台推送。同时，有些厂商提供的消息服务器不具备公开性，导致在用户数据安全性特别是服务器掌控方面存在担心。IBM 基于 WebSocket 的 MQTT 跨平台推送服务方案IBM 通过对现有移动推送平台比较之后，对其中存在的问题和缺陷做了很好的分析。这些问题集中体现在如下方面：在网络方面
如何适应现有网络的不可靠，很好的保障数据发送可靠性如何降低网络流量，从而节省网络成本在移动设备方面
如何降低对设备能力的要求，特别是适应计算和存储弱的设备如何降低对设备电量的消耗，满足设备电源能力的不足如何降低平台依赖性，真正实现跨移动设备平台在数据方面
缺少对数据安全性的保障，特别是对服务器的掌控缺少对大量数据的监测，优化IBM 针对上面问题，结合 MQTT 和 WebSocket，提出了更智慧的移动推送服务解决方案。图 1. IBM 移动推送服务解决方案方案中，服务器端使用 WebSphere MQ 作为 MQTT 的 Server，在移动设备中嵌入 MQTT 的客户端，并通过客户端建立到服务器的双向数据通道，然后在后台来自不同应用的数据通过 WebSphere MQ 推送到移动终端。那么，这样的解决方案，会有什么特点能够很好的解决和优化上面关于业界移动推送服务解决方案中存在的普遍问题，或者说此方案有什么自身的优势。移动设备
能在 8bit 位处理器上很好的运行 C /JavaScript/Java 的 client 库分别只有 30/75/100KB在移动设备上耗电率低，大约只需要 HTTP 的一半通过使用基于 WebSocket 的 MQTT 客户端 JavaScript API，符合 Hybrid 开发潮流，只要设备的浏览器支持 WebSocket，就能很轻松实现多移动平台的跨越很好的适应各种复杂网络，特别是受限网络
预期并适应频繁的网络中断，能应对低速、低质量的网络压缩优化过后的协议，可以有效降低网络流量，从而节约网络成本完成同样的数据通信，MQTT 只需要 HTTP 约 1/4 得数据流量发布 - 订阅的消息通信协议，允许一条消息只发布一次，便可被多个消费端（应用程序 / 设备）所接收
实现系统间松耦合，简化开发，方便扩展，整合。提供灵活便捷的系统整合能力
使用 MQ，MB 提供可靠系统内系统整合和通信Cast Iron 强大的系统间整合带来巨大的灵活性提供丰富的安全性
使用 SSL 提供的认证和加密来保证传输安全性通过 JAAS 接口提供的身份认证OAM 用于资源层面的授权强大的性能提高系统的高可靠性
高连接数下系统低计算资源使用高连接数下系统高信息处理速度提供多种消息服务质量，满足不同场景需求
0 ：消息最多被传递一次，比如一般类广告，通知1 ：消息会被传递但可能会重复传递，比如账户余额通知2 ：消息保证传递且仅有一次传递，比如交易支付批复通知应用场景本文是通过介绍使用 WebSphere MQ Telemetry 以及其 SDK 组件中自带的 MQTT 基本客户端（WebSocket API）实现一个 iOS 设备的推送应用场景，来使读者对使用基于 MQTT 协议的 WebSphere MQ Telemetry 来构建物移动推送服务解决方案有进一步的理解，并能够自己动手开发相应的解决方案。该方案通过 WebSphere MQ Telemetry 自带的 MQTT 基本客户机 WebSocket JavaScript API 来实现客户端到服务器的连通。实现的场景如下：Mobile 用户相互通讯（文本，语音，图片）后台应用向 Mobile 用户推送相关信息（广告，通知等等）图 2. 移动推送服务场景开发步骤及流程整个开发会涉及到移动端开发和服务器端配置，以下将会分别介绍。Note：开发工具使用 Worklight，Xcode，WebSphere MQ Explorer。客户端开发Worklight 平台为开发基于 Web 技术的手机客户端 App 提供了一套完整的解决方案，从开发、部署、测试到发布均可在这个平台上完成。App 用 HTML，CSS 和 Javascript 写成，之后被扩展成桌面的（Windows，Mac，Linux），互联网的（Facebook 等），本地移动设备上的（iOS，Android，RIM 和 Windows Phone）应用程序。开发者还能把一些流行的 Javascript 构架如 jQuery Mobile，Sencha 和 Dojo 整合到 Worklight 中。而且 App 的本地运行时也能用本地代码来编写和修改。MQTT WebSocket JavaScript API 的功能描述如下：Connect 连接
MQTT 客户端负责向 MQTT 服务器发起连接操作，并开始计时，在超时期里接收到正确连接响应，则连接成功，负责连接超时。任何数据的发送或者收到，都将启动新的超时计时，在整个超时完成后没有数据的发送或者接收时，发送心跳以维持连接状态。DisConnect 断开连接
MQTT 客户端或者服务器发起连接断开命令。在发出连接断开命令后，开始超时计时，在超时内成功收到断开响应，双方设置其相应连接状态为断开；超时后尚未成功接收响应，则开始重发连接命令，直到重发次数到达系统设置上限。否则，设置对应原因。Subscribe 订购
在双方连接建立后，MQTT 客户端发送订购消息，来订购主题，并设置相应质量服务级别，在接收到订购确认后，自动接收在此主题上的任何消息。UnSubscribe 取消订购
在双方连接建立后，MQTT 客户端发送取消订购消息，来取消订购主题，在接收到取消订购确认后，在原来主题上的任何消息将不再推送到此客户端。Publish 发布
在双方连接建立后，MQTT 客户端将业务数据放入发布消息的消息体中，通过发布消息，发布在某主题上，此消息按照不同的消息服务质量级别，发布到不同的订购者客户端。Will 主题和消息在 MQTT 客户端连接时设置，设定在自己连接中断后，自动往 Will 主题上发送的通知消息。在 Worklight Studio 中新建 Worklight Project，在工程名中填入 WebSocketMQTT，然后选择 Hybrid Application，点击下一步，在应用名中填入 WebSocketMQTTApp，点击完成。
图 3. WorkLight 工程在工程上单击右键，选择新建 Worklight Environment。Project 选择刚生成的 WebSocketMQTT，Application 选择刚生成的 WebSocketMQTTApp，然后在 Mobile 中选择"iPad"选项框。最后点击完成。
图 4. 新建 Worklight Environment然后在工程中就生成的为 iPad 开发的模板。图 5. iPad 开发模板将 MQTT 的基于 WebSocket 的 Client API 拷贝到 iPad 下的 js 文件夹。
图 6. 拷贝 MQTT Client 的 JS 库文件从本文附件中导入并替代展现页面 WebSocketMQTTApp.html 到 common 文件夹。
图 7. 替换原有展现页面然后在 application：WebSocketMQTTApp 上右键，选择 Run As -& Build All and Deploy在 iPad 模板图标上右键，选择 Run As -& Xcode project。
图 8. 打开 Xcode Project在 Xcode 里，在 Build 成功后，选择配置过的 iOS 设备安装。服务器开发和配置安装 WebSphere MQ 7.5.0.1 版本，在安装过程中选择 Telemetry 组件，安装完后打开 WebSphere MQ 管理界面 WebSphere MQ Explorer。打开 WebSphere MQ Explorer
图 9. WebSphere MQ Explorer在 Queue Managers 上右键，选择新建 Queue Manager，输入 Queue Manager 名称，然后 Next 直到 Finish。
展开新创建的 Queue Manager，点击 Telemetry 并在右边的窗口中，选择 Define sample configuration...图 10. 定义 Telemetry 服务图 11. 配置 Telemetry在配置部署后，会在 Services 中创建并启动服务：SYSTEM.MQXR.SERVICE 同时展开 Telemetry 后在 Channels 里创建了一个接受 MQTT 连接的 PlainText 通道，端口默认是 1883。
图 12. 支持 MQTT 连接的通道
最后为了测试数据的收发，可以打开 WebSphere MQ 自带的测试工具：MQTT Client Utility。
图 13. MQTT Client Utility 工具服务器端的配置就完成了。部署和验证本文将通过模拟移动推送服务中的 2 个基本场景来验证。两个 iPad 设备通讯模拟 Mobile 用户相互通讯MQTT Client Utility 向 iPad 发送消息模拟后台应用向 Mobile 用户推送相关信息在两台 iPad 上安装我们刚刚开发的 App，并配置如下参数：
Server：WebSphere MQ 的安装机器的 IPPort：在 WebSphere MQ 里配置的 MQTT 的通道的端口号，默认是 1883Client ID：页面会生成一个默认的，也可以自定义Topic Name：用于发布或者订购的主题，模拟通讯时，每个客户端有固定的主题，比如：iPad A 主题为 iPadA，iPad B 的主题为 iPadB。在通讯时每个客户端订购自己的主题接收别的客户端发送来的消息，同时给别的客户端的主题发送消息。QoS：质量服务等级启动 App 后，在填写 Server，port 和 Client Id 后，点击连接（Connect），然后分别在订阅的 Topic Name 中填写自己要监听的主题：iPadA 或者 iPadB。最后，在发布 Publish 的 Topic 中填入要对话的对方的主题：iPadB 或者 iPadA，输入想发送的信息后，点击发送就可以开始两个 iPad 之间的通讯了。这里只是简单展现，除了文本通讯还可以实现语音，文件，照片通讯分享等。图 14. iPadA图 15. iPadB通过以上两个截图，验证了两个 iPad 通过基于 WebSocket 的 MQTT 协议，实现了通讯，相互给对方发送了消息。Note: 在 App 部署到 iPad 上后，如果 WorkLight 的服务器更换了，修改应用的 WorkLight Server 地址如下图 16. 应用的 WorkLight 服务器地址为了模拟服务器端应用向移动终端推送消息，采用 JMS 模式通过 WebSphere MQ 向终端推送一条数据。
Topic Name：iPadPushMessage：This is message from backend system application.后端采用 JMS 方式发送数据 import javax.jms.C
import javax.jms.JMSE
import javax.jms.M
import javax.jms.MessageP
import javax.jms.S
import com.ibm.mq.jms.MQConnectionF
public class JMSSender {
private MessageP
public static void main(String[] args) {
JMSSender jmsSender = new JMSSender();
jmsSender.createSender();
jmsSender.closeSender();
private void closeSender() {
sender.close();
sess.close();
conn.close();
System.out.println("JMS Sender closed");
} catch (JMSException e) {
e.printStackTrace();
if (e.getLinkedException() != null) {
e.getLinkedException().printStackTrace();
private void createSender() {
MQConnectionFactory connFact = new MQConnectionFactory();
// We are connecting to queue manager using client mode
connFact.setQueueManager("XRNEW");
connFact.setHostName("localhost");
connFact.setPort(1414);
System.out.println("Model"+connFact.getTransportType());
//connFact.setTransportType(1);
System.out.println("Model"+connFact.getTransportType());
conn = connFact.createConnection();
sess = conn.createSession(false, Session.AUTO_ACKNOWLEDGE);
sender = sess.createProducer(sess
.createQueue("queue://iPadA/iPadPush"));
Message msg = sess.createTextMessage(
"This is message from backend system application.");
msg.setJMSExpiration(10000);
sender.setTimeToLive(10000);
sender.send(msg);
System.out
.println("JMS Sender started and published message to topic iPadPush");
} catch (JMSException e) {
e.printStackTrace();
if (e.getLinkedException() != null) {
e.getLinkedException().printStackTrace();
}图 17. 终端接收后端推送的消息结束语本文通过介绍使用 WebSphere MQ Telemetry 以及其 SDK 组件中自带的 MQTT 基本客户机的 WebSocket JavaScript API 开发一个 App，并通过实现通用的移动推送服务应用场景来使读者对使用基于 MQTT 协议的 WebSocket JavaScript API 来构建移动推送服务解决方案有进一步的理解，并能够自己动手开发相应的推送解决方案。
参考文章“”：
：为使用 WebSphere 产品的开发人员准备的技术信息和资料。这里提供产品下载、how-to 信息、支持资源以及免费技术库，包含 2000 多份技术文章、教程、最佳实践、IBM Redbook 和在线产品手册。
：免费下载 Worklight 试用版。
：下载关键 WebSphere 产品的免费试用版。
：IBM deveperWorks 最新的软件下载。
: 下载关键 WebSphere 最新的产品工具包。
加入 ，developerWorks 社区是一个面向全球 IT 专业人员，可以提供博客、书签、wiki、群组、联系、共享和协作等社区功能的专业社交网络社区。
加入 ，参与在线交流。
developerWorks: 登录
标有星（*）号的字段是必填字段。
保持登录。
单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件。
在您首次登录 developerWorks 时，会为您创建一份个人概要。您的个人概要中的信息（您的姓名、国家/地区，以及公司名称）是公开显示的，而且会随着您发布的任何内容一起显示，除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。
所有提交的信息确保安全。
选择您的昵称
当您初次登录到 developerWorks 时，将会为您创建一份概要信息，您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。昵称长度在 3 至 31 个字符之间。
您的昵称在 developerWorks 社区中必须是唯一的，并且出于隐私保护的原因，不能是您的电子邮件地址。
标有星（*）号的字段是必填字段。
(昵称长度在 3 至 31 个字符之间)
单击提交则表示您同意developerWorks 的条款和条件。 .
所有提交的信息确保安全。
文章、教程、演示，帮助您构建、部署和管理云应用。
立即加入来自 IBM 的专业 IT 社交网络。
免费下载、试用软件产品，构建应用并提升技能。
static.content.url=/developerworks/js/artrating/SITE_ID=10Zone=WebSphere, 移动开发ArticleID=939535ArticleTitle=基于 WebSocket 的 MQTT 移动推送方案publish-date=按照OSI网络分层模型，IP是网络层协议，TCP是传输层协议，而HTTP和MQTT是应用层的协议。在这三者之间， TCP是HTTP和MQTT底层的协议。大家对HTTP很熟悉，这里简要介绍下MQTT。MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是IBM开发的一个即时通讯协议，有可能成为物联网的重要组成部分。该协议支持所有平台，几乎可以把所有联网物品和外部连接起来，被用来当做传感器的通信协议。
HTTP的不足
HTTP协议经过多年的使用，发现了一些不足，主要是性能方面的，包括：
HTTP的连接问题，HTTP客户端和服务器之间的交互是采用请求/应答模式，在客户端请求时，会建立一个HTTP连接，然后发送请求消息，服务端给出应答消息，然后连接就关闭了。（后来的HTTP1.1支持持久连接）因为TCP连接的建立过程是有开销的，如果使用了SSL/TLS开销就更大。
在浏览器里，一个网页包含许多资源，包括HTML，CSS，JavaScript，图片等等，这样在加载一个网页时要同时打开连接到同一服务器的多个连接。
HTTP消息头问题，现在的客户端会发送大量的HTTP消息头，由于一个网页可能需要50-100个请求，就会有相当大的消息头的数据量。
HTTP通信方式问题，HTTP的请求/应答方式的会话都是客户端发起的，缺乏服务器通知客户端的机制，在需要通知的场景，如聊天室，游戏，客户端应用需要不断地轮询服务器。
而 WebSocket是从不同的角度来解决这些不足中的一部分。还有其他技术也在针对这些不足提出改进。
WebSocketWebSocket则提供使用一个TCP连接进行双向通讯的机制，包括网络协议和API，以取代网页和服务器采用HTTP轮询进行双向通讯的机制。
本质上来说，WebSocket是不限于HTTP协议的，但是由于现存大量的HTTP基础设施，代理，过滤，身份认证等等，WebSocket借用HTTP和HTTPS的端口。由于使用HTTP的端口，因此TCP连接建立后的握手消息是基于HTTP的，由服务器判断这是一个HTTP协议，还是WebSocket协议。 WebSocket连接除了建立和关闭时的握手，数据传输和HTTP没丁点关系了。
历时11年，WebSocket终于被批准成为IETF的建议标准：RFC6455.其前身是WHATWG （Web Hypertext Application Technology Working Group）的工作。而Web Socket的API,是W3C的工作。
WebSocket可以只打开一个到的链接，并且在此链接上信息。其优势在于减少了传统方法的复杂性，提高了可靠性和降低了浏览器和客户端之间的负载。这样做的一个重要原因是，很多屏蔽80以外的端口，迫使越来越多的应用迁移到HTTP上来了。
11年的websocket草案的变迁中，有的浏览器支持的是旧版本的websocket，比如iPhone4上的safari使用的WebSocket是旧版的握手协议,那么就要使用就的握手协议来制做服务器端。如今只有Safari支持旧版本的协议，Chrome和Firefox最新版都已升级至Hybi-10（）。因此，我们再来看一下WebSocket新版协议Hybi-10。这次协议变更非常大，主要集中在握手协议和数据传输的格式上。
我们先来看一下大致的区别：
最老的websocket草案标准中是没有安全key，草案7.5、7.6中有两个安全key，而现在的草案10中只有一个安全key，即将 7.5、7.6中http头中的"Sec-WebSocket-Key1&P与"Sec-WebSocket-Key2&P合并为了一个"Sec- WebSocket-Key"
把http头中Upgrade的值由"WebSocket"修改为了"websocket"；http头中的"-Origin"修改为了"Sec-WebSocket-Origin";
增加了http头"Sec-WebSocket-Accept"，用来返回原来草案7.5、7.6服务器返回给客户端的握手验证，原来是以内容的形式返回，现在是放到了http头中；另外服务器返回客户端的验证方式也有变化。
服务器生成验证的方式变化较大，我们来做一介绍。
1 GET / HTTP/1.12 Upgrade: WebSocket3 Connection: Upgrade4 Host: 127.0.0.1:13375 Origin: http://127.0.0.1:80006 Cookie: sessionid= calView= dayCurrentDate=07 Sec-WebSocket-Key1: cV`p1* 42#7& ^9}_ 647& 08{8 Sec-WebSocket-Key2: O8 415 8x37R A8&& 49 ;"######
旧版生成Token的方法如下：
取出Sec-WebSocket-Key1中的所有数字字符形成一个数值，这里是，然后除以Key1中的空格数目，得到一个数值，保留该数值整数位，得到数值N1；对Sec-WebSocket-Key2采取同样的算法，得到第二个整数N2；把N1和N2按照Big- Endian字符序列连接起来，然后再与另外一个Key3连接，得到一个原始序列ser_key。Key3是指在握手请求最后，有一个8字节的奇怪的字符串";"######"，这个就是Key3。然后对ser_key进行一次md5运算得出一个16字节长的digest，这就是老版本协议需要的 token，然后将这个token附在握手消息的最后发送回Client，即可完成握手。
1 GET / HTTP/1.12 Upgrade: websocket3 Connection: Upgrade4 Host: 127.0.0.1:13375 Sec-WebSocket-Origin: http://127.0.0.1:80006 Sec-WebSocket-Key: erWJbDVAlYnHvHNulgrW8Q==7 Sec-WebSocket-Version: 88 Cookie: csrftoken= sessionid=xxxxx
新版生成Token的方法如下：
首先服务器将key（长度24）截取出来，如4tAjitqO9So2Wu8lkrsq3w==，用它和自定义的一个字符串（长度 36）258EAFA5-E914-47DA-95CA-C5AB0DC85B11连接起来，然后把这一字符串进行SHA-1算法加密，得到长度为20字节的二进制数据，再将这些数据经过Base64编码，最终得到服务端的密钥，也就是ser_key。服务器将ser_key附在返回值Sec- WebSocket-Accept后，至此握手成功。
WebSocket也有自己一套帧协议。数据报文格式如下：
&&&&&&0&&&&&&&&&&&&&&&&&& 1&&&&&&&&&&&&&&&&&& 2&&&&&&&&&&&&&&&&&& 3
&&&& +-+-+-+-+-------+-+-------------+-------------------------------+
&&&& |F|R|R|R|opcode|M|Payload len|&&&&Extended payload length&&&&|
&&&& |I|S|S|S|&&(4)&&|A|&&&& (7)&&&& |&&&&&&&&&&&& (16/63)&&&&&&&&&& |
&&&& |N|V|V|V|&&&&&& |S|&&&&&&&&&&&& |&& (ifpayload len==126/127)&& |
&&&& ||1|2|3|&&&&&& |K|&&&&&&&&&&&& |&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& |
&&&& +-+-+-+-+-------+-+-------------+---------------+
&&&& |&&&& Extended payload length continued,ifpayload len==127&&|
&&&& +---------------+-------------------------------+
&&&& |&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& |Masking-key,ifMASK set to1&&|
&&&& +-------------------------------+-------------------------------+
&&&& |Masking-key(continued)&&&&&& |&&&&&&&&&&Payload Data&&&&&&&& |
&&&& +-----------------------------------------------+
&&&& :&&&&&&&&&&&&&&&&&&&& Payload Data continued...&&&&&&&&&&&&&&&&:
&&&& +-------------------------------+
&&&& |&&&&&&&&&&&&&&&&&&&& Payload Data continued...&&&&&&&&&&&&&&&&|
&&&& +---------------------------------------------------------------+
FIN：1位，用来表明这是一个消息的最后的消息片断，当然第一个消息片断也可能是最后的一个消息片断；
RSV1, RSV2, RSV3:
分别都是1位，如果双方之间没有约定自定义协议，那么这几位的值都必须为0,否则必须断掉WebSocket连接；
Opcode:4位操作码，定义有效负载数据，如果收到了一个未知的操作码，连接也必须断掉，以下是定义的操作码：
%x0 表示连续消息片断
%x1 表示文本消息片断
%x2 表未二进制消息片断
%x3-7 为将来的非控制消息片断保留的操作码
%x8 表示连接关闭
%x9 表示心跳检查的ping
%xA 表示心跳检查的pong
%xB-F 为将来的控制消息片断的保留操作码
Mask:1位，定义传输的数据是否有加掩码,如果设置为1,掩码键必须放在masking-key区域，客户端发送给服务端的所有消息，此位的值都是1；
Payload length: 传输数据的长度，以字节的形式表示：7位、7+16位、或者7+64位。如果这个值以字节表示是0-125这个范围，那这个值就表示传输数据的长度；如果这个值是126，则随后的两个字节表示的是一个16进制无符号数，用来表示传输数据的长度；如果这个值是127,则随后的是8个字节表示的一个64位无符合数，这个数用来表示传输数据的长度。多字节长度的数量是以网络字节的顺序表示。负载数据的长度为扩展数据及应用数据之和，扩展数据的长度可能为0,因而此时负载数据的长度就为应用数据的长度。
Masking-key:0或4个字节，客户端发送给服务端的数据，都是通过内嵌的一个32位值作为掩码的；掩码键只有在掩码位设置为1的时候存在。Payload data: &(x+y)位，负载数据为扩展数据及应用数据长度之和。Extension data:x位，如果客户端与服务端之间没有特殊约定，那么扩展数据的长度始终为0，任何的扩展都必须指定扩展数据的长度，或者长度的计算方式，以及在握手时如何确定正确的握手方式。如果存在扩展数据，则扩展数据就会包括在负载数据的长度之内。Application data:y位，任意的应用数据，放在扩展数据之后，应用数据的长度=负载数据的长度-扩展数据的长度。
三、 MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是轻量级基于代理的发布/订阅的消息传输协议，设计思想是开放、简单、轻量、易于实现。这些特点使它适用于受限环境。例如，但不仅限于此：
网络代价昂贵，带宽低、不可靠。
在嵌入设备中运行，处理器和内存资源有限。
该协议的特点有：
使用发布/订阅消息模式，提供一对多的消息发布，解除应用程序耦合。
对负载内容屏蔽的消息传输。
使用 TCP/IP 提供网络连接。
有三种消息发布服务质量：
"至多一次"，消息发布完全依赖底层 TCP/IP 网络。会发生消息丢失或重复。这一级别可用于如下情况，环境传感器数据，丢失一次读记录无所谓，因为不久后还会有第二次发送。
"至少一次"，确保消息到达，但消息重复可能会发生。
"只有一次"，确保消息到达一次。这一级别可用于如下情况，在计费系统中，消息重复或丢失会导致不正确的结果。
小型传输，开销很小（固定长度的头部是 2 字节），协议交换最小化，以降低网络流量。
使用 Last Will 和 Testament 特性通知有关各方客户端异常中断的机制。
早在1999年，IBM的Andy Stanford-Clark博士以及Arcom公司ArlenNipper博士发明了MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）技术。BM和St. Jude医疗中心通过MQTT开发了一套Merlin系统，该系统使用了用于家庭保健的传感器。St. Jude医疗中心设计了一个叫做Merlin@home的心脏装置，这种无限发射器可以用来监控那些已经植入复律-除颤器和起搏器（两者都是基本的传感器）的心脏病人。
该产品利用MQTT把病人的即时更新信息传给医生/医院，然后医院进行保存。这样的话，病人就不用亲自去医院检查心脏仪器了，医生可以随时查看病人的数据，给出建议，病人在家里就可以自行检查。
IBM称该发射器包括一个大型触摸屏，一个嵌入式键盘平台，以及一个Linux操作系统。
在未来几年，MQTT的应用会越来越广，值得关注。
通过MQTT协议，目前已经扩展出了数十个MQTT服务器端程序，可以通过PHP，JAVA，Python，C，C#等系统语言来向MQTT发送相关消息。
此外，国内很多企业都广泛使用MQTT作为Android手机客户端与服务器端推送消息的协议。其中Sohu，Cmstop手机客户端中均有使用到MQTT作为消息推送消息。据Cmstop主要负责消息推送的高级研发工程师李文凯称，随着移动互联网的发展，MQTT由于开放源代码，耗电量小等特点，将会在移动消息推送领域会有更多的贡献，在物联网领域，传感器与服务器的通信，信息的收集，MQTT都可以作为考虑的方案之一。在未来MQTT会进入到我们生活的各各方面。
如果需要下载MQTT服务器端，可以直接去MQTT官方网站点击software进行下载MQTT协议衍生出来的各个不同版本。
MQTT和TCP、WebSocket的关系可以用下图一目了然:
MQTT协议专注于网络、资源受限环境，建立之初不曾考虑WEB环境。HTML5 Websocket是建立在TCP基础上的双通道通信，和TCP通信方式很类似，适用于WEB浏览器环境。虽然MQTT基因层面选择了TCP作为通信通道，但我们添加个编解码方式，MQTT over Websocket也可以的。这样做的好处，MQTT的使用范畴被扩展到HTML5、桌面端浏览器、移动端WebApp、Hybrid等，多了一些想像空间。这样看来，无论是移动端，还是WEB端，MQTT都会有自己的使用空间。
MQ 遥测传输 (MQTT) V3.1 协议规范基于WebSocket 的MQTT
移动推送方案
&&&&&&&&&&&&&&&&&&&&&&&&&
阅读(...) 评论()}