软硬件领域技术的发展，新通信协议的出现导致了物联网（IoT）的发展。 设备的数量每天都在增长，它们产生大量的数据。 因此，需要一种能够处理，存储和发送该数据的便利的系统架构。
现在，他们将云服务用于这些目的。 但是，不断增长的雾模式（Fog）能够通过扩展和优化IoT基础架构来补充云解决方案。 云可以关闭大多数物联网请求。 例如，为了提供监视服务，可以快速处理设备生成的任意数量的数据及其可视化。 朦胧的计算在解决实时问题方面更为有效。 它们提供对请求的快速响应和最小的数据处理延迟。 也就是说，雾正好补充了“云”，扩展了其功能。
但是，主要的问题是不同的：在物联网的背景下，所有这些如何相互作用？ 在统一的IoT-雾云系统中工作时，哪种通信协议最有效？
尽管HTTP显然占主导地位，但IoT，Fog和Cloud使用了大量其他解决方案。 这是因为物联网必须将各种设备传感器的功能与安全性，互操作性和其他用户要求相结合。
这只是参考架构的一个单一想法，而通信标准根本就不存在。 因此，针对特定的物联网任务创建新协议或完善现有协议是IT社区面临的最重要任务之一。
现在使用什么协议，它们可以提供什么？ 让我们做对。 但是首先，让我们讨论一下云，雾和物联网相互作用的生态系统的原理。
物联网雾云架构（F2C）
您一定已经注意到，在以合理和协调的方式探索物联网，云和雾的管理的收益和收益方面付出了巨大的努力。 如果没有，那么就已经有三个标准化计划：
OpenFog联盟 ，
边缘计算联盟和
mF2C H2020 EU项目 。
如果之前只考虑了2个级别，即云和终端设备，那么建议的体系结构将引入一个新级别-雾计算。 在这种情况下，根据资源的具体情况或确定在这些子级别中使用不同设备的策略集，雾级别可以分为几个子级别。
这种抽象可能是什么样？ 这是典型的IoT-雾-云生态系统。 物联网设备将数据发送到功能更强大的服务器和计算设备，以解决要求低延迟的任务。 在同一系统中，云负责解决需要大量计算资源或数据存储空间的问题。
智能手机，智能手表和其他小工具也可以成为物联网的一部分。 但是，此类设备通常使用大型开发人员的专有通信协议。 生成的IoT数据通过REST HTTP协议传递到雾化级别，该协议在创建RESTful服务时提供了灵活性和互操作性。 考虑到需要与在本地计算机，服务器或服务器群集上运行的现有计算基础结构向后兼容，这一点很重要。 称为“雾的节点”的本地资源会过滤接收到的数据并在本地进行处理，或者将其发送到云中以进行进一步的计算。
云支持各种通信协议，其中最常见的是AMQP和REST HTTP。 由于HTTP是众所周知的并且在Internet上被囚禁，因此可能会出现一个问题：“但是我应该使用它来与IoT和fog一起工作吗？”。 但是，此协议存在性能问题。 稍后再详细介绍。
通常，有两种适合我们需要的系统的通信协议模型。 这是一个请求-响应和发布-订阅。 第一种模型更为广为人知，尤其是在服务器-客户端体系结构中。 客户端从服务器请求信息，然后他接收请求，处理请求并返回响应消息。 REST HTTP和CoAP协议适用于此模型。
之所以出现第二个模型，是因为需要在生成数据的源与该数据的接收者之间提供异步，分布式，弱通信。
该模型涉及三个参与者：发布者（数据源），经纪人（调度员）和订户（收件人）。 在此，充当订户的客户端不应向服务器请求信息。 他没有发送请求，而是通过代理来订阅系统中的某些事件，该代理负责过滤所有传入消息并在发布者和订阅者之间路由它们。 并且，当发生与某个主题有关的事件时，发布者将其发布给代理，代理将有关所请求主题的订户数据发送给代理。
本质上，此架构是事件驱动的。 而且这种交互模型对于IoT，云，雾中的应用程序非常有趣，因为它具有提供可伸缩性和简化不同设备之间的互连，支持动态多对多通信和异步通信的能力。 MQTT，AMQP和DDS是使用publish-subscribe模型的最著名的标准化消息协议。
显然，发布-订阅模型具有很多优点：
- 发布者和订阅者不需要了解彼此的存在；
- 一个订阅者可以从许多不同的出版物中接收信息，而一个发布者可以将数据发送给许多不同的订阅者（“多对多”原则）；
- 发布者和订户不需要同时处于活动状态以交换数据，因为代理（作为队列系统）将能够为当前未连接到网络的客户端存储消息。
但是，请求-响应模型也有其自身的优势。 如果服务器端处理多个客户端请求的功能不成问题，则使用已经证明的可靠解决方案是有意义的。
也有支持两种模型的协议。 例如，支持服务器推送选项的XMPP和HTTP 2.0。 IETF还发布了CoAP。 为了解决消息传递问题，创建了其他几种解决方案，例如WebSockets协议或通过QUIC（快速UDP Internet连接）使用HTTP协议。
对于WebSockets，尽管它用于从服务器到Web客户端的实时数据传输，并通过同时的双向通信提供稳定的连接，但它不适用于计算资源有限的设备。 由于新的传输协议提供了许多新功能，因此QUIC也值得关注。 但是由于QUIC尚未标准化，因此预测其可能的应用和对物联网解决方案的影响还为时过早。 因此，我们将WebSockets和QUIC留在了内存中，以期面向未来，但我们将不进行更详细的研究。
世界上最甜蜜的人：我们比较协议
现在让我们谈谈协议的优点和缺点。 展望未来，我们立即做出保留，没有一个明确的领导者。 每个协议都有一些优点/缺点。
响应时间通信协议（尤其是有关物联网的通信协议）最重要的特征之一就是响应时间。 但是在现有协议中，没有一个能证明在不同条件下工作时的最小延迟级别的出色表现。 但是，对协议功能进行了大量的研究和比较。
例如，在使用IoT时比较HTTP和MQTT有效性的结果表明，来自MQTT的请求的响应时间少于来自HTTP的请求。 而且，当
研究 MQTT和CoAP的接收和传输时间（RTT）时，发现平均RTT CoAP比MQTT少20％。
针对MQTT和CoAP协议的RTT的另一项
实验是在两种情况下进行的：局域网和IoT网络。 事实证明，IoT网络中的平均RTT高出2-3倍。 与CoAP相比，具有QoS0的MQTT显示出较低的结果，而由于应用和传输级别的ACK，具有QoS1的MQTT显示出更高的RTT。 对于不同的QoS级别，对于MQTT，无拥塞的网络延迟为毫秒，对于CoAP，为数百微秒。 但是，值得记住的是，当在不太可靠的网络中工作时，在TCP之上运行的MQTT将显示不同的结果。
通过增加有效负载来
比较 AMQP和MQTT协议的响应时间，结果表明在负载较小的情况下，延迟级别几乎相同。 但是，当传输大量数据时，MQTT展示了更少的响应时间。 在另
一项研究中，在机器对机器通信场景中将CoAP与HTTP进行了比较，该设备部署在配备有气体传感器，天气传感器，位置（GPS）和移动网络接口（GPRS）的车辆顶部。 通过移动网络发送CoAP消息所需的时间几乎比使用HTTP消息所需的时间短三倍。
进行的研究不是比较两个协议，而是比较三个协议。 例如，在医疗用例中使用网络仿真器
比较 IoT协议MQTT，DDS和CoAP
的性能。 在各种恶劣的网络条件下，DDS在体验遥测延迟方面胜过MQTT。 基于UDP的CoAP非常适合需要快速响应的应用程序，但是由于它是基于UDP的，因此存在严重的不可预测的数据包丢失。
通量MQTT和CoAP在带宽利用率方面的
比较是对每条消息传输的数据总量的计算。 发送小消息时，CoAP显示的带宽小于MQTT。 但是，按照有用信息字节数与传输的字节总数之比来比较协议的有效性时，CoAP更为有效。
当
分析 MQTT，DDS（以TCP作为传输协议）和CoAP带宽的使用时，事实证明CoAP倾向于显示相对较低的带宽消耗，与网络数据包丢失的增加或网络延迟的增加相比，CoAP并未增加MQTT和DDS，在上述情况下，通道容量的使用有所增加。 在另一种情况下，大量设备正在同时传输数据，这是物联网环境中的典型情况。 结果表明，对于较高的负载，最好使用CoAP。
轻负载时，CoAP使用的带宽最少，其次是MQTT和HTTP REST。 但是，当有效负载大小增加时，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似乎是最有前途的协议，因为与其他协议相比，它们被认为是IoT相对更成熟，更稳定的解决方案。
统一通信协议解决方案
单协议解决方案的实践有很多缺点。 例如，满足有限环境的协议可能无法在具有严格安全要求的域中使用。 考虑到这一点，除了MQTT和REST HTTP之外，我们仍然要丢弃物联网中从雾到云生态系统中基于一种协议的几乎所有可能的解决方案。
REST HTTP作为单协议解决方案有一个很好的IoT到雾REST HTTP请求和响应交互的示例：
smart farm 。 动物配备了可穿戴式传感器（IoT客户端，C），并由智能耕种系统（雾服务器，S）通过云计算进行控制。
POST方法的标题指示要更改的资源（/农场/动物）以及HTTP版本和内容类型，在这种情况下，这是一个JSON对象，代表系统应管理的牲畜场（杜尔西那/牛）。 来自服务器的响应通过发送HTTPS 201（资源创建）状态码表示请求已成功。 GET方法应仅在URI中指示请求的资源（例如/ farm / animals / 1），该资源会从服务器返回具有此标识符的动物的JSON表示形式。
当您需要更新特定的资源记录时，将使用PUT方法。 在这种情况下，将在资源中指示要更改的参数和当前值的URI（例如，指示母牛当前正在行走，/农场/动物/ 1？状态=行走）。 最后，DELETE方法同样用于GET方法，但是作为操作的结果只是删除资源。
MQTT作为单协议解决方案
采用相同的智能服务器场，但是我们使用MQTT协议代替REST HTTP。 安装了Mosquitto库的本地服务器充当代理。 在此示例中，一台简单的计算机（称为场服务器）Raspberry Pi充当MQTT客户端，通过安装MQTT Paho库实现，该库与Mosquitto代理完全兼容。
该客户端对应于IoT抽象层，代表具有检测和计算功能的设备。 另一方面，中间层对应于较高级别的抽象，表示雾的计算节点，该雾的特征在于在处理和存储数据方面具有强大的功能。
在建议的Smart Farm方案中，Raspberry Pi连接到加速度计，GPS和温度传感器，并在雾节点中发布来自这些传感器的数据。 您可能知道，MQTT将主题视为层次结构。 一个MQTT发布者可以发布一组特定的主题。 在我们的案例中，有三个。 对于测量动物仓中温度的传感器，客户选择一个主题（动物农场/棚屋/温度）。 对于通过加速度计测量GPS位置和动物运动的传感器，客户端将发布更新（动物农场/动物/ GPS）和（动物农场/动物/运动）。
此信息将被传输给代理，代理可以将其临时存储在本地数据库中，以防以后出现其他感兴趣的订户。
除了在雾中充当MQTT代理的本地服务器，以及充当MQTT客户端的Raspberry Pi从传感器发送数据的本地服务器之外，在云级别可能还有另一个MQTT代理。 在这种情况下，可以将传输到本地代理的信息临时存储在本地数据库中和/或发送到云。 在这种情况下，模糊的MQTT代理用于将所有数据与云MQTT代理链接。 通过这种体系结构，可以将移动应用程序用户订阅到两个代理。
如果与其中一个代理（例如，云）的连接失败，则最终用户将从另一个（有雾）接收信息。 这是雾和云计算系统相结合的功能。 默认情况下，可以将移动应用程序配置为首次连接到有雾的MQTT代理，如果发生故障，则可以连接到云中的MQTT代理。 该解决方案只是IoT-F2C系统中的众多解决方案之一。
多协议解决方案
单一协议解决方案因易于实现而广受欢迎。 但是很明显，在IoT-F2C系统中，组合不同的协议是有意义的。 关键是不同的协议可以在不同的级别上工作。 以三个抽象为例：物联网，雾和云计算级别。 物联网设备通常被认为是有限的。 在本次审查中，我们将物联网级别限制为最大，将云级别限制为最小，将雾计算视为“介于中间的某个位置”。 事实证明，在物联网和雾抽象之间，当前的协议决策包括MQTT，CoAP和XMPP。 另一方面，在雾和云之间，AMQP是与HTTP REST一起使用的主要协议之一，由于其灵活性，它还可以在IoT和雾层之间使用。
这里的主要问题是协议的互操作性以及将消息从一种协议转换为另一种协议的简单性。 理想情况下，将来，具有云和雾资源的物联网系统架构将独立于所使用的通信协议，并将在不同协议之间提供良好的互操作性。
由于目前还不是这样，因此合并没有明显差异的协议是有意义的。 为此，一个潜在的解决方案是基于两种协议的结合，这些协议遵循相同的体系结构样式，即REST HTTP和CoAP。 另一个提出的解决方案基于提供发布-订阅交互的两种协议的组合MQTT和AMQP。 使用紧密的概念（MQTT和AMQP都使用代理，CoAP和HTTP都使用REST）简化了这些组合的实现，并减少了集成工作。
图（a）显示了两个基于请求响应的模型HTTP和CoAP，以及它们在IoT-F2C解决方案中的可能位置。
由于HTTP是现代网络中最著名和最适合的协议之一，因此不太可能被其他消息协议完全替代。在代表介于云和雾之间的强大设备的节点中，HTTP REST是一种智能解决方案。另一方面，对于计算量有限的设备，它们在雾级别和IoT之间进行通信时，使用CoAP更为有效。 CoAP的一大优势实际上是它与HTTP的兼容性，因为这两种协议都是基于REST原理的。图（b）显示了在一种情况下的两种发布－订阅交互模型，包括MQTT和AMQP。尽管假设这两种协议都可以用于每个抽象级别的节点之间的通信，但是应根据性能确定其位置。 MQTT是为具有有限计算资源的设备开发的简化协议，因此可用于IoT和fog之间的通信。 AMQP更适合于功能更强大的设备，这些设备理想地将其放置在雾和云的节点之间。物联网可以使用XMPP协议代替MQTT，因为它被认为是轻量级的。但是在这种情况下并没有那么广泛地使用它。结论
考虑的协议之一不可能足以覆盖系统中的所有通信，首先是计算资源有限的设备，最后是云服务器。研究表明，开发人员经常使用的两个最有希望的选择是MQTT和RESTful HTTP。这两个协议不仅是最成熟，最稳定的，而且还包含许多有据可查且成功的实施方案和在线资源。由于其稳定性和简单的配置，MQTT是一种协议，随着时间的推移，该协议已在物联网级别的有限设备上证明了其出色的性能。在不存在受限通信和电池消耗问题的系统部分中，例如在雾气弥漫的区域和大多数云计算中，RESTful HTTP是一个容易的选择。还应考虑CoAP，因为它也正在迅速发展成为IoT消息传递标准，并且很可能在不久的将来它将达到类似于MQTT和HTTP的稳定性和成熟度。但是该标准正在开发中，与短期兼容性问题相关。在Cloud4Y博客上阅读还有什么有用的→
电脑会让你好吃→
人工智能帮助研究非洲的动物→
夏天快结束了。 几乎没有数据泄漏→
4种方式在云中保存备份→ 在包含人口信息的单一联邦信息资源上订阅我们的
电报频道，以免错过其他文章！ 我们每周写不超过两次，并且只在商务上写。