[TCCS]OpenHarmony啃论文计划--一文遍历主要的物联网通信协议（MQTT、XMPP、AMQP、DDS、HTTP、CoAP）

​
万字长文预警！一文了解主要的物联网通信协议（MQTT、XMPP、AMQP、DDS、HTTP、CoAP）

虽然我看不懂，但我大受震撼。

我来自OpenHarmony开发者成长计划：啃论文小队，我们在欧建深教练的带领下啃论文。我们是TCCS团队，全意为The Child Collecting Shells。本篇绪论主要作者为TCCS团队的张君豪，欢迎大家对文章提出建设性的意见或者批评！

“我并不知道我在世人眼中是什么模样，对我来说，我似乎只像是一个在海边玩耍的男孩，不时找一颗平滑的卵石，或是比较美丽的贝壳来取悦自己，而真理的大海则横陈在我面前，一无发现。”——牛顿

本文一万多字，这主要归功于原文献作者的综述论文质量非常高，在这里也分享给大家，只凭一篇文章想搞懂这么多协议其实是远远不够的，但是能让大家对协议有一个初步的框架了解。

上一篇文章中分布式软总线关键技术普适计算初探,我挖了一个关于物联网通信协议的坑，现在终于自己来把这个坑填上了。我这次参考的论文是《A Survey of Communication Protocols for Internet of Things and Related Challenges of Fog and Cloud Computing Integration》，翻译过来就是物联网通信协议综述及雾云计算融合相关挑战，我将读完整篇文章并从一个小白提炼的角度来带着大家搞懂这篇论文，也希望通过这篇论文能让大家（包括我）对物联网通信协议有一个更清楚、更宏观的了解，从知道是什么，到为什么，至于怎么用我想在这里看到这篇文章的读者老爷们肯定都比我更会，怎么用我就不卖弄了。好下面进入正题

1.全文综述

由于原文献质量非常高，包括各个协议都写得很清楚，我只是将其初步的加工理解了一下，也带着大家一起学习，本文带着大家首先构建对物联网通信协议的一个基础框架的了解，知道为什么和是什么，至于怎么样，我们下篇再说（毕竟这一篇已经破万字了），在下一篇我带着大家继续解读文献来从几个方面对比这几个协议，着急的老爷也可以先行下载文献自行阅读，文末有我已经上传的文献资源可供大家下载，如果大家喜欢记得点赞哦！当然如果有批评指正也欢迎大家提出来！我也会虚心接受并且积极改正！

---

以下是文章中经常出现的缩写：

IETF：互联网工程任务组，成立于1985年底，是全球互联网最具权威的技术标准化组织，主要任务是负责互联网相关技术规范的研发和制定，当前绝大多数国际互联网技术标准出自IETF。

2.为什么？

2.1为什么需要这么多协议？

首先我们应该都知道协议是什么东西，啊？这都不知道？叉出去

网络协议为计算机网络中进行数据交换而建立的规则、标准或约定的集合。

举个栗子，你可以把网络协议理解为计算机之间相互交流的语言，只有两台通信的主机在使用相同的协议时他们才能有效通信，假如协议不同就好比下图。。。。

而互联网中的主机大部分都使用的是TCP/IP协议（使用TCP/IP相互交流），那这个TCP/IP和我们常常听到的什么HTTP是什么关系呢？

他们分别属于网络不同的层次，如上图可以简单的理解为HTTP是建立在TCP协议的基础之上的。当浏览器需要从服务器获取网页数据的时候，会发出一次http请求。Http通过TCP建立起一个到服务器的通道。可以先简单的这么大致了解一下，因为如果展开说那么。。。。你懂

---

那我们都知道，任何事物既然存在，那么就必然有其存在的道理，那为什么HTTP协议已经应用这么流行和广泛了，还要搞出来这么多不同的协议?

因为物联网需要涵盖不同要求和领域，并且将传感器、执行器和计算能力的功能与安全性、连接性和无数其他功能相结合（总之就是要求很多很复杂），因此对于参考架构或采用的通信协议没有统一的标准协议，因此系统工程师的一大挑战之一就是为其特定的物联网系统要求选择合适的协议。

（也欢迎各位老爷在评论区以开发的视角分享为什么还需要这么多通信）

---

2.2协议的大致如何分类？

一般来说，根据通信协议交互模型的不同，我们可以把通信协议分为request-reply（请求-应答） 和 publish-subscribe（发布-订阅）模型。请求-应答通信模型是最基本的通信模型之一。它代表了一种在客户端/服务器架构中特别常见的消息交换模式。它允许客户端向服务器请求信息，服务器接收请求消息，对其进行处理并返回响应消息。这种信息通常是集中管理和交换的。基于请求/回复模型的两个最知名的协议是 REST HTTP 和 CoAP。图一显示了HTTP三个不同版本（v.1.0、v.1.1、v.2.0）以及CoAP的不同客户端/服务器交互的例子。
​

（图中：SYN：同步标志，FIN：结束标志，即一次会话的建立与结束的标志）

在 HTTP 1.0 中，TCP 连接在单个 HTTP 请求/回复对之后关闭。在 HTTP 1.1 中，引入了 keep-alive 机制，可以重用 TCP 连接来向服务器发送多个请求，而无需等待响应（流水线）。一旦请求全部发送完毕，浏览器就会开始监听响应，同时 HTTP 1.1 规范要求服务器必须按照接收请求的顺序回复对这些请求的响应。新的 HTTP 2.0 引入了一种多路复用方法，通过该方法可以发送多个 HTTP 请求，并且可以通过单个 TCP 连接异步接收响应。图中第四个交互是针对 CoAP 的，与其他交互不同，它不依赖于底层可靠的 TCP 连接来在客户端和服务器之间交换请求/回复消息。另一方面，发布-订阅模型的出现是为了在发送端和目的地之间提供分布式、异步、松散耦合的通信。该解决方案今天以众多发布-订阅的面向消息的中间件 (MoM) 的形式出现，并且最近已成为众多研究工作的主题。

​ 而发布-订阅模型作为传统的请求-回复（客户端-服务器）模型的替代方案，它由三方组成，如图2所示

在这种模型中，具有订阅者角色的客户端不必向服务器请求信息。有兴趣接收消息的客户端将订阅系统内的特定事件（主题）而不是发送请求。代理作为该架构中的中心点，负责过滤所有传入的消息并在发布者和订阅者之间相应地引导它们。第三方是作为信息提供者的发布者。当某个主题的事件发生时，它会将其发布给代理，代理将请求主题的数据发送给订阅者。由于这些原因，发布订阅交互模型可以描述为基于事件的架构 。这种交互模型能够通过支持动态、多对多和异步通信来提供可扩展性并简化不同设备之间的互连。

​ 比较两种基本模型，即请求-回复和发布-订阅，我们可以发现发布-订阅模型具有许多优点：

(1)发布者和订阅者不需要知道彼此的存在；

(2)一个订阅者可以从许多不同的发布者接收信息，并且一个发布者可以向许多不同的订阅者发送数据(支持多对多通信)；

(3)发布者和订阅者不需要同时处于活动状态来交换信息，因为代理(作为一种排队系统工作)可以为当前未连接的客户端存储消息。

目前有许多标准化的消息传递协议都实现了发布/订阅交互模型，最著名的是MQTT、AMQP和DDS。但是请求-应答模型也有一些优势。在服务器端处理多个客户端请求不是问题的情况下，可靠的请求-回复交互更有意义。因此，模型的选择取决于它将用于的应用场景。最后，一些协议同时支持请求-回复和发布-订阅交互模型。这包括XMPP协议和新版本的HTTP HTTP2.0，它支持服务器推送选项。IETF还发布了一份草案，描述了其他的协议的发布-订阅协议，例如CoAP。在尝试解决消息交换的过程中，随着时间的推移，也出现了一些其他解决方案，例如WebSockets协议或使用Quic(Quick UDP Internet Connections)协议的HTTP。在WebSocket的情况下，尽管它用于将数据从服务器实时推送到Web客户端，并实现同时双向通信的持久连接，但它不是为资源受限的设备设计的。作为一种新的传输协议，Quic也创造了一波新的研究。但由于Quic尚未标准化，现在预测其在基于物联网的解决方案中的可能应用和影响可能还为时过早。出于这些原因，尽管WebSockets和Quic很新颖，但它们不在本次研究的范围内。

3.是什么

3.1 各协议总体对比

（Req-Rep：请求-回复模型；Pub-Sub：发布-订阅模型；Standard：标准；Transport：传输；QoS：服务质量；Security：安全机制）

如果一开始看不太懂，可以边看下面详细介绍边看或者看完下面再看这幅图

3.2各协议介绍

3.1.1 HTTP协议

​ 该协议是用于Web的基本客户端-服务器模型协议，也是目前Web开发人员日常使用的与现有网络基础设施最兼容的协议。目前该协议最广泛接受的版本是HTTP/1.1。客户端和服务器之间的通信通过请求/响应消息进行，其中客户端发送HTTP请求消息，然后服务器返回响应消息，这其中包含了在请求被接受的情况下所请求的资源。

最近，HTTP已经与REST联系在一起，REST是一种基于特定架构风格开发Web服务的指南，目的是定义不同组件之间的交互。是目前最流行的一种互联网软件架构。它结构清晰、符合标准、易于理解、扩展方便， 所以正得到越来越多网站的采用。

图中展示的是基于REST与HTTP的交互模型的一个示例。通过HTTP协议与REST的结合，设备可以通过标准化的方式来创建、读取、更新和删除数据(所谓的CRUD操作)，从而使它们的状态信息很容易获得。根据该映射，创建、更新、读取和删除资源的操作分别对应于HTTP POST、GET、PUT和DELETE方法。对于开发人员来说，REST建立了这些CRUD操作与HTTP方法的映射，意味着他们可以轻松地为不同的物联网设备构建REST模型。

HTTP传输的数据的类型是任意的，最常见的是JSON和XML。在大多数情况下，物联网通过HTTP围绕JSON进行标准化。REST HTTP客户端的首要目的之一是想要在服务器端添加资源。为此，有必要在POST方法的标头中指定要添加的资源的*/resources*、HTTP版本、Content-type(在本例中是表示特定资源的JSON文件)，最后指定JSON对象本身。来自服务器的响应通过指定HTTP标准状态代码(例如，201，resource created)来指定请求是否成功。对于要获得这个新资源的第二个客户端，必须使用特定的URI(例如*/Resources/1*)指定GET方法，该URI包含资源的根和资源本身的ID。服务器将返回表示资源的JSON对象。值得一提的是，除了REST HTTP提供的简单通信外，它还拥有丰富的支持和可用的框架，使其成为默认的Web通信方式，几乎所有的服务器和客户端驱动程序都支持它。

​ 关于使用的传输协议，HTTP使用TCP协议传输。使用TCP提供了大量数据的可靠传输，这在没有严格延迟要求的连接中是一个优势，但是它在资源受限的环境中就有待商榷了。其中一个主要问题是，受约束的节点大多数时候会零星地发送少量数据，但建立一个TCP连接需要花费时间并产生不必要的开销。对于QoS（服务质量），HTTP不提供其他选择，而是依赖于TCP，只要TCP连接不中断，就能保证成功传递。

​ 关于安全机制，HTTP使用非常著名的TLS来启用安全加密通信通道，从而产生安全版本的HTTP，也称为HTTPS。保护客户端-服务器数据交换的第一部分是TLS握手，它被实现为“客户端问候”和“服务器问候”消息的交换，其中它们必须就密m套件达成一致，该密m套件是它们将用来确保安全设置的算法的组合。之后，客户端和服务器端根据约定的密钥交换算法进行密钥交换。其结果是使用共享密钥加密的消息交换。数据被加密，以防止任何人窃t和了解内容。当前的TLS实现(TLS版本1.2)通过其握手过程向每个连接建立增加了额外的流量，这可能会耗尽这些设备的计算能力。正在努力开发新的TLS 1.3版，使TLS握手更快、更轻，对物联网来说更方便。

​ 虽然一般来说HTTP是最稳定的协议选择之一，但由于HTTP的复杂性，仍有一些问题导致了人们对替代协议解决方案的探索，比如HTTP报头字段较长，功耗较高。此外，HTTP使用的请求/回复模式不适合推送通知，因为在推送通知中，服务器要在没有客户端请求的情况下将通知传递给客户端。此外，在物联网体系结构中的简单计算节点的情况下，TCP协议开销可能太大(三次握手)。HTTP没有明确定义服务质量级别，因此需要对其提供额外支持。这导致了对HTTP的修改和扩展，最显著的是HTTP/2.0的形式，其引入了许多改进，其中一些与物联网环境强相关。2.0通过引入压缩报头、使用非常高效和低内存压缩格式以及允许在同一连接上进行多个并发交换，HTTP/2.0能够更有效地利用网络资源并减少延迟。对于物联网来说，这些功能特别有用，因为它意味着数据包大小要小得多，这使其成为了受限设备更合适的选择。此外，它还引入了所谓的服务器推送，这意味着服务器可以不需要等待客户端的请求即向客户端发送内容。这个版本的协议在基于物联网的系统中的缺点尚不清楚，据我们所知，截至目前，还没有文献中报告的实施和测试的解决方案。然而，其中一个缺点很可能与HTTP1.1中的相同，即使用TLS协议作为安全机制。

3.1.2 CoAP协议

该协议由 IETF的受限 RESTful 环境 (CoRE) 工作组设计，用于处理能力有限的受限设备。与 HTTP 类似，其最具代表性的特征之一是使用经过测试且广为接受的 REST 架构。借助此功能，CoAP 支持请求/响应实例，就像 REST HTTP 一样，尤其适用于受限环境。 CoAP 被认为是一种轻量级协议，因此标头、方法和状态码都是二进制编码的，与许多协议相比，减少了协议开销。它还运行在不太复杂的 UDP 传输协议 上，进一步减少了开销。当 CoAP 客户端向服务器发送一个或多个 CoAP 请求并获得响应时，此响应不会通过先前建立的连接发送，而是通过 CoAP 消息异步交换。这种减少付出的代价是可靠性。此外，由于使用 UDP 时已知的可靠性特性降低，IETF 创建了一个额外的标准文档，开启了 CoAP 在 TCP 上运行的可能。但是，目前此功能仍处于早期阶段。

CoAP 依赖于一种结构，该结构分为两个逻辑上不同的层。其中一层，即所谓的请求/响应层，实现了 RESTful 范式，并允许 CoAP 客户端在发送请求时使用类似 HTTP 的方法。换句话说，客户端可以使用 GET、PUT、POST 或 DELETE 方法来管理网络中 URI 标识的资源。就像在 HTTP 中一样，对于从服务器获取数据的请求，例如在获取传感器值时，客户端将使用带有服务器 URL 的方法 GET，并且作为回复将接收包含该数据的数据包。请求和响应通过令牌进行匹配；响应中的令牌必须与请求中定义的令牌相同。客户端也可以使用 POST 方法将数据（例如，更新的传感器数据）推送到设备的 URL。正如我们所看到的，在这一层中，CoAP 使用与 REST HTTP 相同的方法。 COAP 与 HTTP 的不同之处在于第二层。由于 UDP 不能确保可靠的连接，CoAP 依靠其第二个结构层来确保可靠性，称为消息层，旨在重新传输丢失的数据包。该层定义了四种类型的消息：CON（Confirmable）、NON（non-confirmable）、ACK（Acknowledgment）和RST（reset）。 CON 消息用于确保可靠通信，它们要求接收方通过 ACK 消息进行确认。尽管方式有限，但正是这个标记消息是否需要确认的特性使得 CoAP 中的 QoS 差异化成为可能。

CoAP 有一个可选功能，可以通过向 GET 请求添加观察选项，允许客户端继续从服务器接收对请求资源的更改，从而改进请求/响应模型。使用此功能，服务器将客户端添加到特定资源的观察者列表中，这将允许客户端在资源状态更改时接收通知。与其依靠重复轮询来检查资源状态的变化，不如在 CoAP 客户端的 GET 请求中设置观察标志，从而允许与服务器在发生变化时提醒客户端，这种交互更接近于发布-订阅模式。为了更接近发布/订阅范式，IETF 最近发布了发布-订阅代理草案，该草案扩展了 CoAP 的功能，以支持连接和/或正常运行时间较长中断的节点，初步性能评估显示出有希望的结果。

关于安全机制，CoAP 在其 UDP 传输协议之上使用 DTLS。它基于 TLS 协议，并进行了必要的更改以在不可靠的连接上运行。结果是一个安全的 CoAPS 协议版本。与 TLS 相比，大多数修改都包括在丢失或乱序数据包的情况下停止连接终止的功能。例如，有可能重传握手消息。握手过程与 TLS 中的握手过程非常相似，交换客户端和服务器“hello”消息，但服务器还可以发送验证查询以确保客户端正在发送其“hello”消息来自真实的源地址。此机制有助于防止拒绝服务攻j。通过这些消息，客户端和服务器还交换支持的密m组和密钥，并同意双方支持的，这将进一步用于通信过程中的数据交换保护。

由于 DTLS 最初不是为物联网和受限设备设计的，因此最近出现了针对轻量级设备优化的新版本 。一些旨在使其更轻量级的 DTLS 优化机制包括 IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) 报头压缩机制，以压缩 DTLS 报头。由于其局限性，为物联网优化 DTLS 仍然是一个悬而未决的问题。

3.1.3 MQTT协议

MQTT 是遵循发布-订阅范式的轻量级消息传递协议之一，这使得它非常适合资源受限的设备和非理想的网络连接条件，例如低带宽和高延迟。 MQTT 由 IBM 发布，其最新版本 MQTT v3.1 被 OASIS 用于物联网。由于其简单性和与其他消息传递协议相比非常小的消息头，它通常被推荐为物联网中的首选通信解决方案。 MQTT 运行在 TCP 传输协议之上，确保了其可靠性。与 HTTP 等其他可靠协议相比，由于其更轻的标头，MQTT 具有更低的功耗要求，使其成为受限环境中最突出的协议解决方案之一。

MQTT 架构中有两个通信方，它们通常扮演发布者和订阅者的角色——客户端和服务器/代理。客户端是可以发布消息、订阅接收消息或两者兼有的设备。客户端必须知道它连接到的代理，并且对于它的订阅者角色，它必须知道它正在订阅的主题。客户端订阅特定主题，以便接收相应的消息。但是，其他客户端也可以订阅相同的主题，并在新消息到达时从代理获取更新。 Broker 作为一个中心组件，接受客户端发布的消息，并在主题和过滤的帮助下，将它们传递给订阅的客户端。

在 MQTT 中，可以使用发布-订阅交互模型，如图 5 所示。通信发生在代理和两个 MQTT 客户端（发布者和订阅者）之间。对于具有代理角色的设备，必须安装 MQTT 代理库，例如 Mosquitto 代理，它是最著名的开源 MQTT 代理之一。应该注意的是，还有各种其他 MQTT 协议代理可供使用，它们在 MQTT 协议的实现方式上有所不同。比如 Emqttd 、ActiveMQ、HiveMQ 、IBM MessageSight 、JoramMQ 、RabbitMQ 和 VerneMQ。客户端是通过安装 MQTT 客户端库实现的。发布者将标签主题创建到代理中，如图 5 所示。MQTT 中的主题被视为层次结构，字符串由斜线分隔，表示主题级别。一个 MQTT 发布者可以将消息发布到一组定义的主题。在这种情况下，客户端将发布主题：topic/1。此信息将发布到代理，代理可以将其临时存储在本地数据库中。对此主题感兴趣的订阅者向代理发送订阅消息，指定相同的主题。

对于 QoS，MQTT 定义了三个 QoS 级别：QoS 0、1 和 2。级别的选择可以在发布和订阅消息体中定义。 QoS 0 尽最大努力交付，无需确认消息接收。在某些传感器在较长时间内收集遥测信息并且传感器值没有明显变化的情况下，这是一种选择。如果有时消息丢失是可以接受的，因为大多数消息更新已被接收，所以一般传感器值仍然是已知的。下一级保证是 QoS 1，它保证消息将到达，因此消息确认是必要的。这意味着接收者必须发送一个确认，如果它没有在定义的时间段内到达，发布者将再次发送一个发布消息。第三个选项 QoS 2 保证消息将只传递一次而不会重复。处理 MQTT 数据包所需的资源量随着选择的 QoS 级别的增加而增加，因此根据特定的网络条件调整 QoS 选择非常重要。

MQTT 提供的另一个重要特性是可以通过在已发布消息中设置“保留”标志来为新订阅者存储一些消息。如果没有人对发布者发送更新的主题感兴趣，代理将丢弃已发布的消息。但是，在某些情况下，特别是当关注主题的状态不经常变化时，让新订阅者能够接收有关该主题的信息是有用的。在这种默认情况下，新订阅者必须等待状态更改才能接收有关该主题的消息。通过将“保留”标志设置为 true，代理会被告知它应该存储已发布的消息，以便可以将其传递给新的订阅者。

MQTT 使用 TCP，这对于受限设备至关重要。为此已经提出了一种解决方案，即 MQTT for Sensor Networks (MQTT-SN) 版本，它使用 UDP 并支持主题名称索引。该解决方案不依赖于 TCP，而是使用 UDP 作为无线链路上更快、更简单、更高效的传输选择。另一个重要的改进特性是有效载荷的减小。这是通过使用数字主题 id 而不是长主题名称对数据包进行编号来完成的。最大的缺点是目前 MQTT-SN 仅被少数几个平台支持，并且已知只有一种免费的代理实现。

由于它被设计为轻量级，MQTT 不提供加密，而是以纯文本形式交换数据，从安全角度来看，这显然是一个问题。因此，加密需要作为一个单独的功能来实现，例如通过 TLS，另一方面这会增加开销。身份验证由许多 MQTT 代理通过一种 MQTT 控制类型消息包（称为 CONNECT）来实现。 Broker 要求客户端在发送 CONNECT 消息时，应在验证连接之前定义用户名/密m组合，或者在身份验证不成功时拒绝它。总体而言，安全性是 MQTT的一项持续努力，并且可能是最重要的一项，因为 MQTT 是最广泛采用和最成熟的通信协议解决方案之一。与其他可用解决方案相比，解决安全问题将为 MQTT 创造重要且巨大的优势。

3.1.4 DDS协议

DDS 是一种以数据为中心的实时互操作性标准，它使用由对象管理组 (OMG) 定义的发布-订阅交互模型。与其他一些发布订阅协议不同，DDS 是分散的并且基于对等通信，因此不依赖于代理组件。在 DDS 中，发布者和订阅者可以通过数据总线作为对等方进行通信，从而可以根据他们的兴趣进行异步数据交换。没有代理人也降低了系统故障的可能性，因为整个系统没有单点故障，使系统更加可靠。通信双方相互解耦，即使没有感兴趣的订阅者，发布者也可以发布数据。数据使用基本上是匿名的，因为发布者不会询问谁在使用他们的数据。

DDS 协议的显着特点之一是它的可扩展性，这来自于它对动态发现的支持。通过 DDS 内置发现协议实现的发现过程允许订阅者找出存在哪些发布者，并使用定义的所需服务质量指定他们感兴趣的信息，并允许发布者发布他们的数据。 DDS 确保正确的发布和订阅节点将被连接并且数据交换将是实时的。与大多数以消息为中心的协议不同，DDS 的另一个重要且独特的特性是它的数据中心性。对于以数据为中心的特点，最重要的是客户想要访问的数据，因此重点是内容信息本身。因此，DDS 实现了一种架构，其中参与节点以一致的方式理解数据值。在 DDS 中，数据类型和内容定义了通信，而在以消息为中心的协议中，重点在于传递该数据的操作和机制。当系统架构师定义所谓的主题时，可以使用 DDS 的以数据为中心的方法，通过将逻辑上相关的数据项分组在一起，以确保更好的可伸缩性和性能结果。

DDS 架构中的主要实体包括域、域参与者、主题、发布者、订阅者、数据写入器和数据读取器。发布者和订阅者分为域，一个虚拟概念实体，允许隔离具有共同兴趣的节点内的通信。 Domain Participant （域参与者）是特定域中消息交换的入口点，它将发布者和订阅者及其所属的域关联起来。它用于在域内创建发布者、订阅者、数据写入者、数据读取者和主题。 DDS 实现中间件以数据为主要定义交互的方式，定义了数据在抽象数据空间中的结构、更改和访问方式，目标是创建全局共享数据。实现这一点的方法是通过数据空间抽象，所有客户端都可以访问以读取或存储他们的数据，称为全局数据空间 (GDS)。正是在 GDS 中，DDS 动态发现功能通过允许加入 GDS 的发布者和订阅者自动发现他们的共同存在以及他们的兴趣而发挥作用。 GDS中DDS节点之间的交换信息单元是Topic，由名称、数据类型和一组QoS策略定义。发布者和订阅者是数据分发和消费的实体，它们通过 GDS 发布和接收数据，但不能单独完成。相反，发布者使用数据写入器发送数据，订阅者使用数据读取器接收数据，两者通过主题进行匹配；也就是说，为了相互通信，发布者和订阅者必须使用相同的主题（相同的名称、类型和兼容的 QoS）。

DDS 默认使用 UDP，但也可以支持 TCP。 DDS 中的另一个重要协议是实时发布订阅 (RTPS)有线协议，它代表 DDS 互操作性协议，允许在不同供应商实现之间共享数据。使用 DDS 的优点之一是提供了广泛的 QoS 策略（标准定义的超过 20 种 QoS）。发送数据时，每个主题、数据写入者和发布者的 QoS 策略控制数据发送到中间件的方式和时间。另一方面，主题 QoS、数据读取器和订阅者控制接收数据时的行为。这些不同的策略管理着无数的 DDS 功能，例如分布式远程实体的发现、数据传递、数据可用性、时间和资源利用率。

对于安全机制，DDS 实现了各种解决方案。根据选择的传输协议，如果 TCP 是传输协议，则可以使用 TLS，如果使用 UDP，则可以使用 DTLS 协议。同样，对于 TLS，DTLS 在受限环境中也带来了过多的开销，为此已经提出了改进的机制。为此，OMG DDS 安全规范定义了一个广泛的安全模型和服务插件接口 (SPI) 架构，专为适用于物联网系统的 DDS 实现而设计。安全规范的问题目前对于 DDS 来说仍然是一个开放的问题，预计将来会实施新的补充。预期的新增功能之一是能够在具有匹配安全分类的基于 DDS 的应用程序之间建立安全传输流的安全发现机制。

DDS 是基于物联网的环境的重要解决方案，因为它具有分散的发布/订阅架构，并且支持在功能强大的设备和受限设备中实现。 DDS 的一个挑战是它尚未被广泛使用，尽管这可能会随着准备测试的新兴开源 DDS 实现而改变，例如 OpenDDS。

3.1.5 AMQP协议

AMQP 是遵循 OASIS定义的发布-订阅范式的开放标准协议，旨在实现各种不同应用程序和系统之间的互操作性，而不管其内部设计如何。最初它是为商业消息传递而开发的，其想法是提供一种非专有解决方案，可以管理系统中可能在短时间内发生的大量消息交换。这种 AMQP 互操作性特性非常重要，因为它允许以不同语言实现的不同平台交换消息，这在异构系统中可能特别有用。

AMQP 已经在两个非常不同的版本中实现，AMQP 0.9.1 和 AMQP 1.0，每个版本都具有完全不同的消息传递范例。 AMQP 0.9.1 实现了发布-订阅范式，它围绕两个主要的 AMQP 实体，都是 AMQP 代理的一部分：交换和消息队列。交换代表代理的一部分，用于引导从发布者接收到的消息。将消息发布到交换实体是该过程的第一步，然后将消息路由到一个或多个适当的队列中。这取决于是否有更多订阅者对特定消息感兴趣，在这种情况下，代理可以复制消息并将其副本发送到多个队列。消息将保留在队列中，直到被订阅者接收。这个实际连接交换和队列的路由过程依赖于所谓的绑定，它们是消息分发的预定义规则和条件。另一方面，较新版本的 AMQP 协议， AMQP 1.0 不依赖于任何特定的消息传递机制。虽然旧版本的协议专门使用上述发布-订阅方法以及由交换和消息队列组成的架构，但新的 AMQP 实现遵循对等范式，并且可以在没有中间代理的情况下使用。 Broker 仅存在于需要提供存储转发机制的通信中，而在其他情况下，直接消息传递是可能的。这种支持不同拓扑的选项增加了可能的基于 AMQP 的解决方案的灵活性，支持不同的通信模式，例如客户端到客户端、客户端到代理和代理到代理。应该注意的是，大量的基础设施仍然使用旧的 AMQP 0.9 版本。

AMQP 使用 TCP 进行可靠传输，此外它还提供三个不同级别的 QoS，与 MQTT 相同。最后，AMQP 协议提供了互补的安全机制，通过使用 TLS 协议进行加密来保护数据，并通过使用 SASL（简单身份验证和安全层）进行身份验证。

凭借其提供的所有功能，AMQP 具有相对较高的功率、处理和内存相关要求，使其成为一个相当繁重的协议，这一直是其在基于 IoT 的生态系统中的最大劣势。该协议更适合系统中不受带宽和延迟限制的部分，具有更强的处理能力。

3.1.6 XMPP (可扩展消息传递和存在协议)

XMPP 是由 IETF 形式化的开放标准消息传递协议，最初设计用于即时消息传递和应用程序之间的消息交换。它是一个基于文本的协议，基于可扩展标记语言 (XML)，实现客户端-服务器和发布订阅交互，运行在 TCP 上。在物联网解决方案中，除了管理用户的存在外，它还旨在允许用户实时发送消息。 XMPP 允许即时消息传递应用程序实现所有基本功能，包括身份验证、端到端加密以及与其他协议的兼容性。

XMPP 支持客户端-服务器交互模型，但也有新的扩展支持使用通用的发布-订阅模型。这些扩展使 XMPP 实体能够创建主题和发布信息；然后将事件通知广播到已订阅特定节点的所有实体。此功能对于 IoT-fog-cloud 场景非常重要，是需要事件通知的各种应用程序的基础。 XMPP 中的客户端和服务器使用 XML 流相互通信，以 XML 节（语义结构化数据单元）的形式交换数据。定义了三种类型的节：、、n d （信息/查询）。消息节定义消息标题和内容，用于在 XMPP 实体之间发送数据。消息节不会收到接收实体的确认，无论它是客户端还是服务器。存在节显示并通知实体状态更新，在 XMPP 中具有订阅的作用。如果对某个 JID（Jaber ID - XMPP 中的节点地址）的存在感兴趣，则客户端订阅他们的存在，并且每次节点发送存在更新时都会通知客户端。 iq 节将消息发送者和接收者配对。它用于从服务器获取一些信息（例如，有关服务器或其注册客户端的信息），或将一些设置应用于服务器。它的功能类似于 HTTP GET 和 POST 方法。

该协议最重要的特征之一是其安全特性，这使其成为所调查的更安全的消息传递协议之一。与所调查的其他协议（例如 MQTT 和 CoAP）不同，在协议规范中没有内置 TLS 和 DTLS 加密，XMPP 规范已经包含 TLS 机制，它提供了一种可靠的机制来确保机密性和数据完整性。 XMPP 规范的新增内容还包括与安全、身份验证、隐私和访问控制相关的扩展。除了 TLS，XMPP 还实现了 SASL，它通过特定于 XMPP 的配置文件来保证服务器验证。

表 2 概述了为使这些协议与受限环境更兼容的持续努力。

由于 XMPP 最初是为即时消息而设计的，因此存在一些明显的潜在弱点。通过使用 XML，消息的大小使其在带宽受限的网络中变得不方便。另一个缺点是缺乏可靠的 QoS 保证。由于 XMPP 在持久的 TCP 连接之上运行并且缺乏有效的二进制编码，因此在通常与物联网技术相关的有损、低功耗无线网络上使用它并不实用。然而，最近，为了使 XMPP 更适合物联网，人们付出了很多努力。有研究人员针对资源受限的物联网设备提出了一种轻量级 XMPP 发布/订阅方案，从而改进和优化了同一协议的现有版本。

---

本文就先整理到这里主要是肝不动了，其实大部分文字都是直接将论文翻译过来整理了一下，论文作者本身就以一种非常通俗易懂的语言来讲解各个协议，而不是写一大串高深莫测的专有名词来实现“八股文”，这也验证了罗除博士说的工科综述语言都很直白平实容易理解。由于原综述太长了，下一篇再来具体介绍各个协议在各个性能方面的对比。也欢迎大家加入我们啃论文团队！

最后还是请大家批评指正！

​