MQTT, XMPP, WebSockets还是AMQP?泛谈实时通信协议选型 good

Wolfram Hempel 是 deepstreamIO 的联合创始人。deepstreamIO 是一家位于德国的技术创业公司,为移动客户端、及物联网设备提供高性能、安全和可扩展的实时通信服务。文本由魏佳翻译,转载译文请注明来自高可用架构。

想要向服务器发送请求并获得响应?直接使用 HTTP 吧!非常简单。但是当需要通过持久的双向连接来通信时,如 WebSockets,当然你也有其它的选择。

这篇文章会简单扼要的解释 MQTT,XMPP,STOMP,AMQP,WAMP 和其它替代品。这里常被引用的 XKCD 漫画[1]之一:

等等,其实没有“实时协议”这种东西!

确实如此,但这里我将该术语(Realtime Protocol)当作一堆协议的代称,这类协议都是设计用于分发消息,同步数据和通过持久双向的连接来进行请求/响应。

我们先来根据它们各自的目的进行分类:

纯消息

底层协议(例如 TCP)是被设计用来将一个消息从一个发送者(sender)传递给一个接收者(receiver)。他们并不关系消息本身应该如何构建,也不关系消息的请求、获取、存储以及如何保证安全可靠。

像 WebSockets 这样在 TCP 之上的协议,添加了一些额外的功能,例如使用头部(header)传输元数据,通过多个数据包分割较大的消息,简单的身份验证,以及路由/重定向相关信息。本质上它们仍然是点对点交换数据的方式。

当涉及到构建更大,更复杂的系统时,你需要一个更高层次的通信范式:

发布-订阅

发布-订阅模式是在大规模系统中被广泛使用的通信方式,用于多对多无状态消息传递。“订阅者”(Subscribers)可以订阅“消息主题”(topics,channels,events,namespaces), “发布者”(Publishers)可以将消息发布到“消息主题”,通过路由,所有的订阅者都将收到。

这种范式是非常灵活,高效和可扩展。它将发送者与接收者隔离开,允许订阅者自由得订阅主题或取消订阅。这和我们日常订阅报纸是一样的。

有许多支持发布-订阅的协议:MQTT,STOMP,WAMP 等等。那么我们应该如何选择呢?

MQTT

MQTT(Message Queue Telemerty Transport)[2]是一种二进制协议,主要用于服务器和那些低功耗的物联网设备(IoT)之间的通信。
它位于 TCP 协议的上层,除了提供发布-订阅这一基本功能外,也提供一些其它特性:不同的消息投递保障(delivery guarantee),“至少一次”和“最多一次”。通过存储最后一个被确认接受的消息来实现重连后的消息恢复。

它非常轻量级,并且从设计和实现层面都适合用于不稳定的网络环境中。

什么时候应使用它?

物联网(IoT)场景中更适合,支持几乎所有语言进行开发,并且浏览器也可通过 WebSocket 来发送和接收 MQTT 消息。

同时,对于MQTT Broker,也有很多选择,如 Mosquitto[3] 或 VerneMQ[4] 以及基于云的 MQTT 平台,如 HiveMQ[5] 或 CloudMQTT[6]。

STOMP

面向流文本的消息传输协议(STOMP,Streaming Text Oriented Messaging Protocol)[7],是 WebSocket 通信标准。在通常的发布-订阅语义之上,它通过 begin/publish/commit 序列以及 acknowledgement 机制来提供消息可靠投递。

由于协议简单且易于实现,几乎所有的编程语言都有 STOMP 的客户端实现。但是在消息大小和处理速度方面并无优势。

什么时候会使用它?

当与 Apache Apollo[8] 这样的多协议代理(multi-protocol broker)中间件结合使用时,可以做许多有趣的集成。比如在浏览器的图表中不断更新 IoT 设备的数据。

选择二进制还是基于文本?

到目前为止,我们已经讲了两个协议:一个二进制、另一个基于文本。让我们快速比较一下差异:
通过控制线缆中光或电的打开或关闭(逻辑开关),或控制 WiFi 信号的波峰或波谷来实现计算机之间的信息交换。从原理上来说,这是基于二进制的形式。因此,从这个层面来说所有协议都是二进制协议
信息一旦发送,接收方有两个选择:它可以将 0/1 流分组成字节序列,进而获取(解析)信息;或者可以执行额外的步骤,将其转换为文本,然后再解析此文本。
前一种方法称为(基于)二进制的。它节省了一些昂贵的操作,同时是传输任何非文本信息的标准形式。
例如,图像,音频,视频或文件。当然它也可用于发送文本信息。
例如,通过向每个消息增加几个字节来表达元信息,比如描述该消息的长度或类型,这样就只需将实际的消息数据转换为文本。
然而,由于在许多发布-订阅式的架构中,信息交换是基于文本的,所以许多协议选择简单地将整个信息转化为文本,从而降低复杂性并提高了可读性,当然带来的代价就是需要再消息接受后执行额外的计算任务

WAMP

Web 应用消息协议(WAMP,Web Application Messaging Protocol)[9],它尝试开发一种开放的、基于文本的协议标准,并且结合了基于发布-订阅的请求/响应编程模型,同时具备强大的路由和消息投递策略。目前它被广泛用于集成 crossbar.io[10] 路由器和 autobahn 的高速缓存客户端[11]。

Pusher / PubNub&Co

那些实时通信平台即服务(Realtime platform-as-a-service)的产品,例如 Pusher 或 PubNub,通常使用它们自己的专有协议。Pusher 已经公开了它们研发的基于 JSON 协议的详细规范[12],并且鼓励第三方或社区帮助构建不同语言的客户端。Pubnub 虽然更封闭一些,但它们目前支持一系列其它开放协议进行交互,如 MQTT。

队列

有些场景下,简单的发布-订阅模式还不够。这就是队列存在的场合:它支持多种不同的消息和存储的模式。

通过获取/确认策略,消费者接收到队列的一些消息,确认他们的“消费”,处理它们,然后取下一批消息。这是一个强大同时常用的方式。

想象一下,你正在构建一个类似 Instagram 的产品,它允许用户上传图片并添加各种滤镜。应用滤镜的过程是一个计算密集型的操作。因此,不能在上传时直接进行操作,所以接收图像的服务器只是记录下在文件系统中的位置,接着将“什么图像需要使用什么样的滤镜”这个任务添加到任务队列中。

另一台专门用于处理滤镜的机器可以从任务队列中获取这个任务,读取原始图像文件,应用滤镜,并确认这个任务已经消费(完成)。之后为了水平扩展图像处理的能力,只需要添加更多的消费者(处理滤镜的机器)来处理任务队列即可。

这种模式非常易于扩展,可以添加复杂的路由策略,任务分配策略等。

AMQP

高级消息队列协议(AMQP,Advanced Message Queuing Protocol)[13]是各种消息队列协议中的佼佼者。RabbitMQ[14] 和 HornetQ[15] 都是实现该协议的流行中间件。

什么时候会使用它?

当简单的发布-订阅模型不能满足使用要求。AMQP 十分可靠且功能强大。当然它及它的实现并不是足够轻量级。如果你需要一个更轻量级的选择,那接下来的内容可能会更好:

ZeroMQ

ZeroMQ[16] 既是一个协议,也是一套协议实现的组件。提供比 AMQP 更高速同时去中心化的替代方案。

什么时候会使用它?

当你需要海量吞吐以及无单点故障风险的消息队列支撑你的复杂工作流,那么 ZeroMQ 是个不错的选择,当然,你需要对陡峭的学习曲线做好准备。

JMS

Java 消息服务(JMS,Java Messaging Service)[17],是协议同时也是 Java 消息服务规范的标准实现,同时也是 Java 企业版(JEE)规范的一部分。

什么时候应使用它?

当你使用 Java 栈,同时也为 Java Enterprise Platform 付费了,那 JMS 是最佳选择。如果没有,那就优先考虑上述那些方案。

请求/响应

有时我们只需要发送单个请求,并等待收到一个响应,这完全可以使用HTTP请求完成 / 。 但是既然你已经建立了一个与服务器的持久连接 ,那为什么不利用它呢?

这种通过持久连接进行的请求/响应模式的通信过程,通常被称为远程过程调用(RPC,Remote Procedure Calls)或远程方法调用(RMI,Remote Method Invocation)。AMQP 或 ZeroMQ 可以通过响应队列(response-queue)来实现这种模式,JMS 可以直接支持 Java RMI。

DataSync

DataSync 是实现实时通信的最新可选方案。

DataSync 将数据存储中的数据同步给客户端。客户端对数据的变更都将同步给所有的订阅者。DataSync 隐藏了实时通信类应用中维护数据状态的细节,降低了复杂性,并极大加快了开发速度,但它目前仍然是一种没有开放的协议标准。

目前 DataSync 已可以在几个 PaaS 平台上使用,如 deepstreamHub[18],Firebase[19] 或 Realm[20]。

总结一下

利用 deepstream[21] 的分布式实时协议(DRP,Distributed Realtime Protocol),我们有信心找到一种方法,将所有上述概念组合成一个协议,同时确保消息大小,可扩展性和互操作性方面的效率最大化。

参考

  1. https://xkcd.com/
  2. http://mqtt.org/
  3. https://mosquitto.org/
  4. https://vernemq.com/
  5. http://www.hivemq.com/
  6. https://www.cloudmqtt.com/
  7. https://stomp.github.io/
  8. https://activemq.apache.org/apollo/
  9. http://wamp-proto.org/
  10. http://crossbar.io/
  11. http://crossbar.io/autobahn/
  12. https://pusher.com/docs/pusher_protocol
  13. https://www.amqp.org/
  14. https://www.rabbitmq.com/
  15. http://hornetq.jboss.org/
  16. http://zeromq.org/
  17. http://docs.oracle.com/javaee/6/tutorial/doc/bncdq.html
  18. https://deepstreamhub.com/
  19. https://firebase.google.com/
  20. https://realm.io/
  21. https://deepstream.io/

推荐阅读

https://mp.weixin.qq.com/s/IyvKMTQY3Nzt719Bs09uyg

时间: 2024-09-30 02:00:22

MQTT, XMPP, WebSockets还是AMQP?泛谈实时通信协议选型 good的相关文章

物联网通信协议——比较-MQTT、 DDS、 AMQP、XMPP、 JMS、 REST、 CoAP

物联网通信协议--比较-MQTT. DDS. AMQP.XMPP. JMS. REST. CoAP AMQP & MQTT & DDS (https://www.youtube.com/watch?v=GTK94zZJbGQ) 物联网通信协议详解及选择建议(资料来源:http://www.elecfans.com/iot/419545.html) 物联网协议的选择 发布/订阅服务更适合物联网环境下通信 DDS.MQTT.AMQP和JMS都是基于发布/订阅模式,发布/订阅框架具有服务自发现.

Android推送方案分析(MQTT/XMPP/GCM)

本文主旨在于,对目前Android平台上最主流的几种消息推送方案进行分析和对比,比较客观地反映出这些推送方案的优缺点,帮助大家选择最合适的实施方案. 方案1.使用GCM服务(Google Cloud Messaging)简介:Google推出的云消息服务,即第二代的C2DM.优点:Google提供的服务.原生.简单,无需实现和部署服务端.缺点:Android版本限制(必须大于2.2版本),该服务在国内不够稳定.需要用户绑定Google帐号,受限于Google. 方案2.使用XMPP协议(Open

[转]Android推送方案分析(MQTT/XMPP/GCM)

转自:http://m.oschina.net/blog/82059 本文主旨在于,对目前Android平台上最主流的几种消息推送方案进行分析和对比,比较客观地反映出这些推送方案的优缺点,帮助大家选择最合适的实施方案. 方案1. 使用GCM服务(Google Cloud Messaging) 简介:Google推出的云消息服务,即第二代的G2DM. 优点:Google提供的服务.原生.简单,无需实现和部署服务端. 缺点:Android版本限制(必须大于2.2版本),该服务在国内不够稳定.需要用户

翻译:实时通信协议UDP-RT——Michael Pan

介绍UDP-RT协议,用于实时系统中高效.可靠的通信. 介绍 几乎所有现代的应用程序都要求快速和可靠的通信,但实时通信的要求更加极致,需要网络实时响应.某些情况下,要求特别高以至于需要特殊的硬件,来实现所需的性能.在过去的十年中,出现了新的技术以支持增长的需求,但是成本很高而可用性不强.因为,大多数系统仍在使用基于以太网为骨干的TCP/IP协议栈.甚至,大多数程序员还在使用同步的socket API进行开发.这篇文章探索了实时系统中主流技术的使用,展示了在系统中如何设计和开发通信.特别的是,它推

实时数据库系统选型

北京华恒信远拥有丰富国外各种主流实时数据库软件实施经验,根据系统集成商的项目实际要求,提供实时数据库选型咨询,目前国内外实时数据库分为四种类型:一种是国外传统实时数据库.国外组态软件供应商实时数据库.国内传统实时数据库和国内组态软件供应商实时数据库,下面分别介绍以上四种类型的实时数据库: (1)国外传统实时数据库包括:a. OSI公司的PI( Plant Information System )b. Aspen公司的IP21( InfoPlus.21 )c. Honeywell公司的PHD( P

物联网的七大通信协议

背景 通信对物联网来说十分常用且关键,无论是近距离无线传输技术还是移动通信技术,都影响着物联网的发展.而在通信中,通信协议尤其重要,是指双方实体完成通信或服务所必须遵循的规则和约定.那么物联网都有哪些通信协议呢? 我们将物联网协议分为两大类,一类是传输协议,一类是通信协议.传输协议一般负责子网内设备间的组网及通信,之前我们已经为大家做了一次的科普,文章<物联网常见的无线传输协议类型>有详细介绍.通信协议则主要是运行在传统互联网TCP/IP协议之上的设备通讯协议,负责设备通过互联网进行数据交换及

iOS开发拓展篇-XMPP简单介绍

iOS开发拓展篇-XMPP简单介绍 一.即时通讯简单介绍 1.简单说明 即时通讯技术(IM)支持用户在线实时交谈.如果要发送一条信息,用户需要打开一个小窗口,以便让用户及其朋友在其中输入信息并让交谈双方都看到交谈的内容 有许多的IM系统,如AOL IM.Yahoo IM. MSN以及QQ,它们最大的区别在于各自通讯协议的实现,所以即时通讯技术的核心在于它的传输协议 协议用来说明信息在网络上如何传输,如果有了统一的传输协议,那么应当可以实现各个IM之间的直接通讯,为了创建即时通讯的统一标准,目前已

iOS开发之XMPP

iOS开发拓展篇-XMPP简单介绍 一.即时通讯简单介绍 1.简单说明 即时通讯技术(IM)支持用户在线实时交谈.如果要发送一条信息,用户需要打开一个小窗口,以便让用户及其朋友在其中输入信息并让交谈双方都看到交谈的内容 有许多的IM系统,如AOL IM.Yahoo IM. MSN以及QQ,它们最大的区别在于各自通讯协议的实现,所以即时通讯技术的核心在于它的传输协议 协议用来说明信息在网络上如何传输,如果有了统一的传输协议,那么应当可以实现各个IM之间的直接通讯,为了创建即时通讯的统一标准,目前已

android openfire 和 xmpp

关于xmpp协议可以参考:http://www.jabbercn.org 什么是OpenFire Openfire 采用Java开发,开源的实时协作(RTC)服务器基于XMPP(Jabber)协议. 您可以使用它轻易的构建高效率的即时通信服务器.Openfire安装和使用都非常简单,并利用Web进行管理.单台服务器可支持上万并发用户. 由于是采用开放的XMPP协议,您可以使用各种支持XMPP协议的IM客户端软件登陆服务. XMPP(Jabber)协议 1. 介绍 XMPP是一种基于XML的协议,