MQTT通信的冗余性：一种演进

论文标题：Redundancy for MQTT Communication: an Evolution

中文标题：MQTT通信的冗余性：一种演进

作者信息：

• Claudio Zunino
• Manuel Cheminod
• Gianluca Cena
• Stefano Vitturi
• Alberto Morato
• Elena Ferrari
• Federico Tramarin 他们分别来自意大利国家研究委员会CNR-IEIIT、帕多瓦大学信息工程系、以及摩德纳雷焦艾米利亚大学“恩佐·法拉利”工程系。作者的电子邮件地址分别是：
• Claudio Zunino, Manuel Cheminod, Stefano Vitturi, Alberto Morato: {alberto.morato, claudio.zunino, manuel.cheminod, stefano.vitturi}@cnr.it
• Elena Ferrari: elena.ferrari.7@phd.unipd.it
• Federico Tramarin: federico.tramarin@unimore.it

论文出处：2024年IEEE第29届新兴技术和工厂自动化国际会议（ETFA）

摘要： 关键基础设施、公用事业和大型企业日益复杂。这些庞大的系统，通常地理分布广泛，依赖于在庞大网络中的无缝协调。通常，它们使用互联网和TCP/IP协议进行通信。然而，确保系统级弹性需要异常可靠的网络基础设施。本文提出了一种解决方案，它建立在MQTT协议的冗余版本上，直接在网络端点实现。这种方法确保即使在潜在的网络问题面前也能可靠地通信。此外，本文还探讨了未来解决方案的潜力，该解决方案分析了多点发布器/订阅器场景，为此目的，进行了初步研究，以同步网络中更大数量设备的通信。论文最后详细说明了所提出的解决方案，评估了其有效性，并通过实验验证了其实用性。

第一节 引言 传统上，确保可靠的运行对于大多数工业设施至关重要。这种概念，根据Laprie等人的说法，被称为可靠性，包括可用性、可靠性、安全性、数据完整性、可维护性，有时甚至包括机密性等因素。因此，多年来开发了许多实用策略和保障措施，显著提高了这些系统的可靠性行为。此外，最近的全球事件（恐怖主义、大流行病、战争以及自然灾害和人为灾害）已将焦点转移到弹性上。在形成关键基础设施的大型、互联和广泛的系统背景下，弹性可以定义为在变化面前维持可靠运行的能力。简单来说，它代表了这些系统的整体能力，我们的生命、社会和经济常常依赖于它们，在不可预见和不可避免的中断期间适应挑战并继续可接受地运行。在这个场景中，我们还有由工业4.0运动推动的工业自动化革命，它正在推动采用相关技术，如工业物联网（IIoT）。这种影响不仅在工厂和工厂（现场）内部感受到，而且在全球范围内也有所体现。云技术促进了无缝集成，并启用了大规模、全球优化等功能。分布式应用程序依赖于互联网进行通信，其可靠性直接与互联网的稳定性相关。用户无法控制内部网络操作，这可能影响可靠性。虽然像TCP这样的协议为大多数应用程序提供了足够的可靠性，包括对低延迟要求的应用程序，如流媒体和VoIP，但它们可能不适用于关键任务控制系统。这些系统需要近乎完美的数据传输，最小化丢失或延迟。对于这些场景，实现无缝冗余提供了一个简单的解决方案。这些场景的一个关键协议可以是MQTT（消息队列遥测传输）。MQTT专为物联网（IoT）设计，由于其在启用机器对机器（M2M）通信和通过互联网的多播形式方面的灵活性而受到欢迎。它通过为消息分配主题来实现这一点，允许不同的数据流。与传统的客户端-服务器协议如HTTP不同，MQTT使用发布-订阅（Pub/Sub）方法，实现了事件驱动和定期数据交换。这种Pub/Sub模型有效地将数据生产者（发布者）与数据消费者（订阅者）分开。这种分离允许可扩展的解决方案，通信设备之间的依赖性最小。MQTT的核心组件是客户端和代理。代理充当中心消息路由器，将消息从发布者定向到感兴趣的订阅者。客户端向代理发布消息，然后代理将它们转发给订阅的客户端。从这些要求出发，我们提出了一种基于具有冗余性的MQTT协议的解决方案。在[5]中提出了类似的方法，其中修改了MQTT库以实现无缝冗余，而无需更改程序与它们（API）的交互方式，引入了基于软件定义网络（SDN）方法的路径选择：从全球池中自动选择代理，可能分布在世界各地，以优化通信。这种选择是动态的，为冗余连接选择路径，优先考虑特定的性能指标，如最小化延迟或消息丢失。在本文中，提出了一种改进先前解决方案的机制，并在端节点上实现冗余，而不仅仅是在代理上。此外，为了进行更详细和现实的分析，架构提出了一种不再基于一个节点同时充当发布者和订阅者的延迟测量，而是多个客户端。然而，为了能够以足够的精度评估延迟，需要基于NTP协议进行节点同步，并进行初步的拟合优度分析。本文的结构如下：第二节介绍了将冗余性应用于MQTT的解决方案，第三节描述了用于实验评估的设置。第四节报告了我们获得的结果，包括对NTP同步的一些考虑，第五节得出了一些结论。

 

第二节 扩展冗余性 本文在先前描述的系统基础上，解决了端节点缺乏冗余性的问题。我们引入了一个两部分组成机制来实现这一点：

• 操作系统路由配置：这需要修改路由表以根据源IP地址指导流量。这确保了消息通过所需的网络接口发送。
• 网络接口绑定：这涉及修改发布者/订阅者代码。具体来说，它建立了MQTT通信使用的套接字与主机上特定网络接口之间的绑定。有几种方法可以实现第一个机制，但我们将重点关注iproute2。这个程序预装在大多数现代Linux发行版上，非常适合这项任务。默认情况下，Linux系统依赖于一个路由表来指导网络流量。这个表将数据包指向一个单一的“默认网关”，它作为网络的主要出口点。然而，iproute2工具套件提供了使用多个路由表的可能性。有了iproute2，就可以在默认路由表旁边创建额外的路由表。这些自定义表随后可以填充特定的路由和网关。因此，如果我们有两个网络接口卡（NIC），NIC1和NIC2，NIC1可能使用默认网关的标准路由设置进行配置。另一方面，NIC2可以连接到一个单独的网络。要利用NIC2进行特定流量，您将创建第二个路由表。这个第二个表将包含三个关键规则：
  • 到达特定网络：这个规则（或可能是一对规则）将定义如何路由目的地为NIC2所属网络的数据包。它将指定该网络的适当网关。
  • NIC2流量使用：另一个规则将确保从分配给NIC2的IP地址本身发起的流量使用这个第二个路由表。
  • 流量定向到NIC2：最后一个规则将捕获任何直接或打算通过NIC2 IP地址的数据包。这确保了所有与NIC2相关的流量都使用其专用连接有效地路由。这些规则使得路由环境更加可控。源自或目的地为连接到NIC2的网络的数据包现在将使用专用网关和连接，绕过默认网关和NIC1。这允许根据网络配置要求优化流量流动。机制的第二部分需要修改订阅者/发布者代码。尽管代码仍然使用Python并继续使用PAHO库，但新版本引入了重要的增强功能。它现在允许指定特定MQTT连接与指定IP地址之间的绑定，然后可以将其链接到特定的网络接口卡。这种改进使系统能够在保留之前建立多个连接到不同代理的能力的同时，还提供在一或多个网络接口卡上复制这些连接的选项。因此，这次更新显著增强了网络通信设置的灵活性和鲁棒性。为了评估实验设置中的延迟，我们需要节点精确地同步时间。在我们的系统中，我们使用Chrony套件确保所有机器彼此保持同步。Chrony作为网络时间协议（NTP）的实现，是计算机网络中时间同步的标准。每台机器上的Chrony（发布者和两个订阅者）不断监控和调整系统时钟以保持精确的时间记录。

第三节 实验设置 在本文中，我们专注于使用单个代理、发布者节点上的双路径和两个订阅者的分析。如图1所示，发布者通过电缆连接到路由器的互联网，并使用移动电话配置的热点模式提供的WiFi连接。发布者是Raspberry PI四核Cortex-A72（ARM v8）64位SoC @ 1.8GHz，拥有8GB的RAM，5.0 GHz IEEE 802.11ac无线连接和千兆以太网端口。操作系统是Raspbian GNU/Linux 11（bullseye），内核版本为Linux rasp4 6.1.19。代理是Eclipse Mosquitto，版本1.6.9，它运行在一台装有Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz和16GB RAM的PC上。操作系统是Ubuntu 20.04.6 LTS，内核版本为Linux 5.4.0-172。虽然发布者和代理都在都灵，但它们位于城市的两个不同区域。

两个订阅者在亚马逊网络服务云中托管的虚拟机上运行，分别位于法兰克福和巴黎

。虚拟机类型为t2.micro，拥有一个虚拟CPU和1GB的RAM。操作系统是Ubuntu 24.04 LTS版本，内核版本为Linux 6.8.0。为了评估延迟，我们使用tcpdump在发布者和两个订阅者上捕获了每个数据包发送和接收的时间戳。通过这样做，我们确保了我们的延迟测量是准确的，并且只反映了实际的网络传输时间（包括通过MQTT代理转发消息）。这种方法使我们能够忽略操作系统内核和端节点的应用层可能引入的任何额外延迟，确保了对网络延迟的更精确评估。为了评估实验期间发布者和订阅者之间的同步质量，我们使用了一个Python程序，该程序在测量期间运行。该程序每五秒循环运行一次chronyc工具。Chronyc是Chrony套件中包含的实用程序，允许监控负责系统时钟与NTP服务器同步的chronyd的performance。Python脚本通过每五秒调用一次chronyc并存储检索到的值在文件中，来捕获节点和NTP服务器之间的时钟偏移。

第四节 结果 本节详细描述了一个实验，旨在评估冗余机制在现实场景中的有效性。实验利用上述测试平台在现实世界的操作条件下进行。我们的主要目标是评估使用发布/订阅消息传递范式传输的通知所经历的端到端延迟。值得注意的是，延迟测量仅关注端节点的网络层，如前所述，排除了发布者或订阅者应用程序本身引入的任何延迟。

实验涉及发布者生成总共100,000条MQTT消息（200字节长）。然后，这些消息通过测试平台中可用的两条路径同时传输。我们记录了每个单独路径和每个订阅者的消息到达时间。新数据每0.5秒生成一次，实验持续时间接近14小时。通过分析收集的日志，我们可以计算消息延迟并识别任何潜在的消息丢失。我们对两条路径的通信质量指标的分析揭示了两个关键点：

1. 零数据包丢失：不足为奇的是，在实验期间没有消息丢失。TCP丢失通常由链路故障、路由器崩溃或严重的DDoS攻击等事件引起，这些在短时间间隔内很少见。
2. 延迟分布：两条路径上的延迟统计数据显示，对于两个订阅者，有线连接的延迟分布相当窄，而移动连接则有更长的延迟，如图2和图3所示，显示了两个订阅者和每条路径的累积分布函数（CDF）（图表截止到99.9百分位数）。表I中显示了相同实验的数字综合，其中可以看到有线连接的性能非常好，而移动连接则经历了更大的延迟。

表I 关于使用两个可用路径向两个订阅者发送通知所经历的延迟的统计数据。 订阅者 路径 延迟（毫秒） 最小值 平均值 99.9p 最大值 标准差 法兰克福 有线 16.32 36.52 131.55 569.50 14.10 移动 41.04 74.72 285.59 1231.36 19.53 巴黎 有线 20.09 36.95 130.09 581.29 13.63 移动 40.36 76.56 293.34 1234.21 17.95

两种连接类型（有线和移动）之间的主要区别在于路径的初始段，从发布者到代理。一旦消息到达代理，无论连接类型如何，其传递给订阅者的过程保持不变。移动连接由于两步通信过程而经历更高的延迟：首先，数据通过Wi-Fi从发布者交换到移动设备（热点）；然后，设备连接到蜂窝网络以到达蜂窝无线电塔。

A. 同步评估 如第三节所述，我们收集了在整个实验期间运行在每个节点上的chronyc工具报告的偏移量，以评估我们的延迟测量的质量。总的来说，我们获得了10,000个值，每个节点代表每台机器上的本地时钟与选定的NTP服务器上的参考时钟之间的差异。我们在图4和图5中报告了这些值的分布，分别针对订阅者和发布者。在图表中，我们还包括了一些统计指标。我们可以注意到，在每个节点上，偏移量平均为0毫秒，表明同步工具正确地持续调整时钟。此外，两个订阅节点具有非常相似的小偏移量，分布非常窄。这可能是因为它们使用了一个位于云内部的Amazon Time Sync服务，因此无论从物理上还是逻辑上都离它们非常近。这项服务似乎提供了良好的性能。发布者节点具有不同的且较大的时间同步偏移量绝对值，分布更广。在这种情况下，我们有一个区域NTP服务器，所有由于正常连接到互联网而产生的延迟。然而，我们注意到一个样本大约是半毫秒，而大多数其他值落在±0.1ms的范围内。考虑到我们的实验传输延迟在几十毫秒的顺序，我们可以声明这种时间测量方法是足够精确的。

第五节 结论 在这项工作中，我们提出了一种用于可靠通信的解决方案，该方案使用直接在网络端点实现的MQTT协议的冗余变体。此外，本文还探讨了将此解决方案扩展到多点发布者/订阅者场景的可能性。为此，进行了初步研究，以评估通过在网络中的多个设备之间利用时间同步来评估传输延迟。结果表明，这种方法可以以令人满意的方式使用。

作为未来的工作，可以通过使用带有SIM卡的接入点的解决方案来显著提高发布者节点的性能，以替代移动电话。这将提供更稳定且可能更快的连接。此外，在同步数据上实现分析模型将提供有价值的见解，并可能优化同步过程。