软件和硬件领域技术的发展、新通信协议的出现导致了物联网（IoT）的扩展。 设备的数量日益增长，并产生大量数据。 因此，需要一种能够处理、存储和传输这些数据的方便的系统架构。
现在云服务用于这些目的。 然而，日益流行的雾计算范式（Fog）可以通过扩展和优化物联网基础设施来补充云解决方案。
云能够满足大多数物联网请求。 例如，提供服务监控、快速处理设备生成的任意数量的数据及其可视化。 雾计算在解决实时问题时更加有效。 它们提供对请求的快速响应和最小的数据处理延迟。 也就是说，Fog 补充了“云”并扩展了其功能。
然而，主要问题是不同的：所有这些应该如何在物联网背景下相互作用？ 在物联网-雾-云组合系统中工作时，哪些通信协议最有效？
尽管 HTTP 占据了明显的主导地位，但物联网、雾和云系统中还使用了大量其他解决方案。 这是因为物联网必须将各种设备传感器的功能与用户的安全性、兼容性和其他要求结合起来。
但关于参考架构和通信标准根本没有单一的想法。 因此，针对特定物联网任务创建新协议或修改现有协议是 IT 社区面临的最重要任务之一。
目前正在使用哪些协议以及它们可以提供什么？ 让我们弄清楚一下。 但首先，让我们讨论一下云、雾和物联网相互作用的生态系统的原理。
物联网雾到云 (F2C) 架构
您可能已经注意到，人们付出了多少努力来探索与物联网、云和雾的智能和协调管理相关的优势和好处。 如果没有，那么这里有三个标准化举措： , и .
如果以前只考虑云和终端设备这两个级别，那么所提出的架构引入了一个新级别——雾计算。 在这种情况下，雾级别可以分为几个子级别，具体取决于资源的具体情况或确定这些子级别中不同设备的使用的一组策略。
这个抽象可能是什么样的？ 这是一个典型的物联网-雾-云生态系统。 物联网设备将数据发送到更快的服务器和计算设备，以解决需要低延迟的问题。 在同一个系统中，云负责解决需要大量计算资源或数据存储空间的问题。
智能手机、智能手表和其他小工具也可以成为物联网的一部分。 但此类设备通常使用大型开发商的专有通信协议。 生成的物联网数据通过 REST HTTP 协议传输到雾层，这在创建 RESTful 服务时提供了灵活性和互操作性。 鉴于需要确保与本地计算机、服务器或服务器集群上运行的现有计算基础设施向后兼容，这一点非常重要。 本地资源（称为“雾节点”）过滤接收到的数据并在本地进行处理或将其发送到云端进行进一步计算。
云支持不同的通信协议，最常见的是 AMQP 和 REST HTTP。 由于 HTTP 众所周知并且是为互联网量身定制的，因此可能会出现这样的问题：“我们不应该使用它来处理物联网和雾吗？” 然而，该协议存在性能问题。 稍后会详细介绍这一点。
一般来说，有2种通信协议模型适合我们需要的系统。 这些是请求-响应和发布-订阅。 第一个模型更广为人知，尤其是在服务器-客户端架构中。 客户端向服务器请求信息，服务器接收请求、处理请求并返回响应消息。 REST HTTP 和 CoAP 协议在此模型上运行。
第二种模型源于在生成数据的源和该数据的接收者之间提供异步、分布式、松散耦合的需要。
该模型假设三个参与者：发布者（数据源）、代理（调度者）和订阅者（接收者）。 这里，充当订阅者的客户端不必向服务器请求信息。 它不发送请求，而是通过代理订阅系统中的某些事件，代理负责过滤所有传入消息并在发布者和订阅者之间路由它们。 当有关某个主题的事件发生时，发布者将其发布到代理，代理将有关所请求主题的数据发送给订阅者。
本质上，该架构是基于事件的。 这种交互模型对于物联网、云、雾中的应用很有趣，因为它能够提供可扩展性并简化不同设备之间的互连，支持动态多对多通信和异步通信。 一些使用发布-订阅模型的最著名的标准化消息传递协议包括 MQTT、AMQP 和 DDS。
显然，发布订阅模式有很多优点：
- 发布者和订阅者不需要知道彼此的存在；
- 一个订阅者可以从多个不同的发布者接收信息，一个发布者可以向多个不同的订阅者发送数据（多对多原则）；
- 发布者和订阅者不必同时处于活动状态才能进行通信，因为代理（作为排队系统工作）将能够为当前未连接到网络的客户端存储消息。
然而，请求-响应模型也有其优点。 如果服务器端处理多个客户端请求的能力不是问题，那么使用经过验证的可靠解决方案是有意义的。
还有支持这两种模型的协议。 例如，XMPP和HTTP 2.0，它们支持“服务器推送”选项。 IETF 还发布了 CoAP。 为了解决消息传递问题，人们还创建了其他几种解决方案，例如 WebSockets 协议或通过 QUIC（快速 UDP 互联网连接）使用 HTTP 协议。
就 WebSocket 而言，尽管它用于从服务器到 Web 客户端实时传输数据并提供持续连接和同步双向通信，但它不适用于计算资源有限的设备。 QUIC 也值得关注，因为新的传输协议提供了很多新的机会。 但由于 QUIC 尚未标准化，因此预测其可能的应用及其对物联网解决方案的影响还为时过早。 因此，我们着眼于未来，牢记 WebSockets 和 QUIC，但现在我们不会更详细地研究它。
谁是世界上最可爱的人：比较协议
现在让我们谈谈协议的优点和缺点。 展望未来，让我们立即做出保留，没有一个明确的领导者。 每个协议都有一些优点/缺点。
响应时间
通信协议最重要的特征之一是响应时间，尤其是与物联网相关的协议。 但在现有协议中，没有明显的赢家能够证明在不同条件下工作时的最低延迟水平。 但对协议功能进行了大量的研究和比较。
Например， 对 IoT 中 HTTP 和 MQTT 的有效性进行比较表明，MQTT 请求的响应时间比 HTTP 短。 什么时候 MQTT 和 CoAP 的往返时间 (RTT) 表明，CoAP 的平均 RTT 比 MQTT 低 20%。
其他 MQTT 和 CoAP 协议的 RTT 在本地网络和物联网网络两种场景中进行。 事实证明，物联网网络中的平均 RTT 高出 2-3 倍。 与 CoAP 相比，具有 QoS0 的 MQTT 显示出较低的结果，而由于应用层和传输层的 ACK，具有 QoS1 的 MQTT 显示了更高的 RTT。 对于不同的 QoS 级别，无拥塞的网络延迟对于 MQTT 为毫秒级，对于 CoAP 为数百微秒级。 然而，值得记住的是，当在不太可靠的网络上工作时，运行在 TCP 之上的 MQTT 将显示完全不同的结果。
通过增加有效负载，AMQP 和 MQTT 协议的响应时间表明，轻负载时，延迟水平几乎相同。 但当传输大量数据时，MQTT 表现出更短的响应时间。 又一个 在机器对机器通信场景中将 CoAP 与 HTTP 进行比较，其中设备部署在配备有气体传感器、天气传感器、位置传感器 (GPS) 和移动网络接口 (GPRS) 的车辆顶部。 通过移动网络传输 CoAP 消息所需的时间几乎比使用 HTTP 消息所需的时间短三倍。
已经进行的研究不是比较两个协议，而是三个协议。 例如， 使用网络模拟器在医疗应用场景中评估物联网协议 MQTT、DDS 和 CoAP 的性能。 在各种较差的网络条件下测试的遥测延迟方面，DDS 的性能优于 MQTT。 基于 UDP 的 CoAP 对于需要快速响应时间的应用程序效果很好，但是，由于它是基于 UDP 的，因此存在严重的不可预测的数据包丢失。
容量
MQTT 和 CoAP 在带宽效率方面是通过计算每条消息传输的数据总量来进行的。 在传输小消息时，CoAP 的吞吐量低于 MQTT。 但是，当根据有用信息字节数与传输字节总数的比率来比较协议效率时，CoAP 更为有效。
在 使用 MQTT、DDS（以 TCP 作为传输协议）和 CoAP 带宽，发现 CoAP 通常表现出相对较低的带宽消耗，并且不会随着网络丢包或网络延迟的增加而增加，这与 MQTT 和 DDS 不同，其中上述场景中带宽利用率的增加。 另一种场景涉及大量设备同时传输数据，这在物联网环境中很常见。 结果表明，为了获得更高的利用率，最好使用 CoAP。
轻负载下，CoAP 使用的带宽最少，其次是 MQTT 和 REST HTTP。 然而，当有效负载的大小增加时，REST HTTP 具有最佳结果。
功耗
能源消耗问题始终非常重要，尤其是在物联网系统中。 如果 MQTT 和 HTTP 都消耗电力，但 HTTP 消耗的电力更多。 CoAP 更 与 MQTT 相比，允许电源管理。 然而，在简单的场景中，MQTT更适合在物联网网络中交换信息，特别是在没有功率限制的情况下。
在移动或不稳定的无线网络测试台上比较 AMQP 和 MQTT 功能的实验发现，AMQP 提供更多安全功能，而 MQTT 更节能。
安全
安全性是研究物联网和雾/云计算主题时提出的另一个关键问题。 安全机制通常基于 HTTP、MQTT、AMQP 和 XMPP 中的 TLS 或 CoAP 中的 DTLS，并支持这两种 DDS 变体。
TLS 和 DTLS 从在客户端和服务器端之间建立通信以交换受支持的密码套件和密钥的过程开始。 双方协商设置以确保进一步的通信在安全通道上进行。 两者之间的区别在于一些小的修改，允许基于 UDP 的 DTLS 在不可靠的连接上工作。
在 TLS 和 DTLS 的几种不同实现发现 TLS 做得更好。 由于其容错能力，对 DTLS 的攻击更加成功。
然而，这些协议的最大问题是它们最初并不是为物联网而设计的，也不适合在雾或云中工作。 通过握手，它们会在每次连接建立时增加额外的流量，从而耗尽计算资源。 平均而言，与没有安全层的通信相比，TLS 的开销平均增加了 6,5%，DTLS 的开销增加了 11%。 在资源丰富的环境中，通常位于 在物联网层面，这不会是一个问题，但在物联网和雾层面的连接中，这成为一个重要的限制。
选择什么？ 没有明确的答案。 MQTT 和 HTTP 似乎是最有前途的协议，因为与其他协议相比，它们被认为是相对更成熟、更稳定的物联网解决方案。
基于统一通信协议的解决方案
单协议解决方案的实践有很多缺点。 例如，适合受限环境的协议可能无法在具有严格安全要求的域中工作。 考虑到这一点，我们只能放弃物联网雾到云生态系统中几乎所有可能的单协议解决方案，除了 MQTT 和 REST HTTP。
REST HTTP 作为单一协议解决方案
有一个很好的示例说明 REST HTTP 请求和响应如何在 IoT-to-Fog 空间中交互： 。 这些动物配备了可穿戴传感器（物联网客户端，C），并由智能农业系统（雾服务器，S）通过云计算进行控制。
POST 方法的标头指定要修改的资源 (/farm/animals) 以及 HTTP 版本和内容类型，在本例中是一个 JSON 对象，表示系统要管理的动物农场 (Dulcinea/cow) 。 服务器的响应通过发送 HTTPS 状态代码 201（资源已创建）表明请求成功。 GET 方法必须仅在 URI 中指定请求的资源（例如，/farm/animals/1），这会从服务器返回具有该 ID 的动物的 JSON 表示形式。
当需要更新某些特定资源记录时，使用 PUT 方法。 在这种情况下，资源指定要更改的参数的 URI 和当前值（例如，指示牛当前正在行走，/farm/animals/1? state=walking）。 最后，DELETE 方法与 GET 方法的用法相同，但只是删除操作结果的资源。
MQTT 作为单一协议解决方案
让我们采用相同的智能农场，但我们使用 MQTT 协议而不是 REST HTTP。 安装了 Mosquitto 库的本地服务器充当代理。 在此示例中，一台简单的计算机（称为场服务器）Raspberry Pi 充当 MQTT 客户端，通过安装 Paho MQTT 库实现，该库与 Mosquitto 代理完全兼容。
该客户端对应于代表具有传感和计算能力的设备的物联网抽象层。 另一方面，中介者对应于更高层次的抽象，代表具有更大处理和存储能力的雾计算节点。
在所提出的智能农场场景中，Raspberry Pi 连接到加速度计、GPS 和温度传感器，并将这些传感器的数据发布到雾节点。 您可能知道，MQTT 将主题视为层次结构。 单个 MQTT 发布者可以将消息发布到一组特定的主题。 在我们的例子中，有三个。 对于测量动物谷仓温度的传感器，客户选择一个主题（动物农场/棚/温度）。 对于通过加速度计测量 GPS 位置和动物运动的传感器，客户端将发布更新到 (animalfarm/animal/GPS) 和 (animalfarm/animal/movement)。
该信息将被传递给经纪人，经纪人可以将其临时存储在本地数据库中，以防稍后出现另一个感兴趣的订阅者。
除了在雾中充当 MQTT 代理并由充当 MQTT 客户端的 Raspberry Pi 向其发送传感器数据的本地服务器之外，在云级别可能还有另一个 MQTT 代理。 在这种情况下，传输到本地代理的信息可以临时存储在本地数据库中和/或发送到云端。 在这种情况下，雾 MQTT 代理用于将所有数据与云 MQTT 代理关联起来。 通过这种架构，移动应用程序用户可以订阅两个经纪商。
如果与其中一个代理（例如云）的连接失败，最终用户将收到来自另一个代理（例如云）的信息。 这是雾和云计算相结合的系统的一个特征。 默认情况下，移动应用程序可以配置为首先连接到雾 MQTT 代理，如果失败，则连接到云 MQTT 代理。 该解决方案只是 IoT-F2C 系统中的众多解决方案之一。
多协议解决方案
单一协议解决方案因其更易于实施而广受欢迎。 但很明显，在 IoT-F2C 系统中，结合不同的协议是有意义的。 这个想法是不同的协议可以在不同的级别上运行。 以三个抽象为例：物联网、雾和云计算层。 物联网级别的设备通常被认为是有限的。 在本概述中，我们将物联网层视为最受约束的层，将云层视为受约束最小的层，将雾计算视为“中间的某个位置”。 事实证明，在物联网和雾抽象之间，当前的协议解决方案包括 MQTT、CoAP 和 XMPP。 另一方面，在雾和云之间，AMQP 是使用的主要协议之一，还有 REST HTTP，由于其灵活性，也在物联网和雾层之间使用。
这里的主要问题是协议的互操作性以及将消息从一种协议传输到另一种协议的便利性。 理想情况下，未来云雾资源的物联网系统架构将独立于所使用的通信协议，并保证不同协议之间良好的互操作性。
由于目前情况并非如此，因此将没有显着差异的协议组合起来是有意义的。 为此，一种潜在的解决方案是基于遵循相同架构风格的两种协议的组合：REST HTTP 和 CoAP。 另一个提议的解决方案基于提供发布-订阅通信的两种协议的组合：MQTT 和 AMQP。 使用类似的概念（MQTT 和 AMQP 都使用代理，CoAP 和 HTTP 使用 REST）使得这些组合更容易实现，并且需要更少的集成工作。
图 (a) 显示了两种基于请求-响应的模型：HTTP 和 CoAP，以及它们在 IoT-F2C 解决方案中的可能位置。 由于 HTTP 是现代网络上最知名和采用的协议之一，因此它不太可能被其他消息传递协议完全取代。 在代表云与雾之间强大设备的节点中，REST HTTP 是一种智能解决方案。
另一方面，对于在雾层和物联网层之间通信的计算资源有限的设备，使用CoAP会更有效。 CoAP 的一大优势实际上是它与 HTTP 的兼容性，因为这两种协议都基于 REST 原则。
图(b)展示了同一场景下的两种发布-订阅通信模型，包括MQTT和AMQP。 尽管假设这两种协议都可以用于每个抽象层的节点之间的通信，但它们的位置应根据性能来确定。 MQTT 被设计为针对计算资源有限的设备的轻量级协议，因此可用于 IoT-Fog 通信。 AMQP 更适合更强大的设备，这将理想地将其定位在雾和云节点之间。 XMPP 协议可以代替 MQTT 用于物联网，因为它被认为是轻量级的。 但在此类场景中应用并不那么广泛。
发现
所讨论的协议之一不太可能足以覆盖系统中的所有通信，从计算资源有限的设备到云服务器。 研究发现，开发人员最常使用的两个最有前途的选项是 MQTT 和 RESTful HTTP。 这两个协议不仅是最成熟和稳定的，而且还包括许多有据可查且成功的实现和在线资源。
由于其稳定性和简单的配置，MQTT 是一种协议，随着时间的推移，在设备有限的物联网级别使用时，它已经证明了其卓越的性能。 在系统中通信有限和电池消耗不成问题的部分（例如某些雾域和大多数云计算）中，RESTful HTTP 是一个简单的选择。 CoAP 也应该被考虑在内，因为它作为物联网消息传递标准也在快速发展，并且很可能在不久的将来达到类似于 MQTT 和 HTTP 的稳定性和成熟度。 但该标准目前正在不断发展，这就带来了短期兼容性问题。
你还能在博客上读到什么？
→
→
→
→
→
订阅我们的 -频道，以免错过下一篇文章！ 我们每周写信不超过两次，而且只写生意。
来源： habr.com