本周波罗的海的互联网电缆切断事件已被广泛报道，尽管对其原因和影响的理解仍在继续。文中转向 RIPE Atlas 对这些事件进行初步分析，并询问该地区的互联网在多大程度上对其具有弹性。

11 月 17 日星期日，连接瑞典和立陶宛的 BCS 东西互联互联网电缆停止工作。次日，连接芬兰和德国的 C-Lion1 互联网电缆也被切断。在撰写本文时，对导致这两条在波罗的海路径中相互交叉的电缆在如此短的时间间隔内被切断的原因的调查仍在进行中。但当转向 RIPE Atlas 来测量这些事件对互联网的影响时，这里真正想询问的问题是互联网是否设法绕过了造成的损害。

分析

目前对这些事件的分析仍在进行中，此处共享的测量结果和图表是初步的。不过，到目前为止我们所观察到的确实让我们对电缆切断的影响有了初步的了解。

分析基于 RIPE Atlas 对曾由受影响电缆连接的国家之间路径的测量数据。更具体地说，使用从 RIPE Atlas 锚点收集的数据，这些锚点提供了互联网的特别稳定视图。这些设备执行的测量之一是“ping 网格”，其中每个锚点每隔四分钟对所有其他锚点进行持续测量。由此产生的网格使我们能够了解锚点之间路径的状态，包括延迟和随时间的损耗。

在深入分析之前，值得强调的是，我们并非在所有地方都有锚点。因此，我们并未测量所分析国家对之间所有 IPv4 和 IPv6 地址之间的互联网路径，也不知道如何将 RIPE Atlas 锚点的数据外推到更广泛的国家。所以严格来说，这是对目标国家之间 RIPE Atlas 锚点网格的分析。

对于那些没有时间阅读完整分析的人，这里是我们初步发现的快速总结：

BCS 切断

据报道，该互联网电缆于 11 月 17 日凌晨被切断。作为我们分析的起点，我们查看了瑞典和立陶宛之间路径的锚点网格中的测量数据。在网格中，瑞典有 15 个 RIPE Atlas 锚点，立陶宛有 5 个，提供延迟数据。

在初步数据探索后，我们看到在 08:00 UTC 之前有一些延迟变化，这与事件的一些报告时间相吻合。以该时间为重点，我们查看了从 12 小时前到 12 小时后的时间间隔。

图 2（我们生成的一系列类似图表之一）显示了立陶宛 RIPE Atlas 锚点与瑞典斯德哥尔摩一个目标锚点之间的延迟示例。对于此（和其他延迟图表），我们减去观察期间路径的最小延迟，以使延迟跳跃具有可比性。这里的一些路径在 08:00 UTC 左右显示出延迟的上升，而其他路径则没有。

图 3 是我们图表中的一个示例，其中我们在事件发生时间附近未看到延迟增加。在这种情况下，这些是立陶宛的锚点与斯德哥尔摩的 RIPE Atlas 锚点之间的延迟，网络与图 2 不同。

为了查看受延迟增加影响的路径的百分比，我们比较了切断前一小时和切断后一小时的延迟（详见脚注 1）。

图 4 显示了这些延迟影响的分布。无需详细说明，在这里我们看到 80%的路径（y 轴上的 0.8）没有显著的延迟差异，而其他 20%的路径有增加的延迟。延迟差异最大的 10%的路径增加了 10 到 20 毫秒。

此外，除了查看延迟影响外，我们还可以使用 RIPE Atlas 锚点网格查看数据包丢失。图 5 显示了我们在瑞典和立陶宛锚点之间的 ping 网格中测量的所有路径的数据包丢失指标（详见脚注 2）。总体而言，我们看到 0%数据包丢失的基线，偶尔有峰值。但这里引人注目的观察结果是，在电缆切断时间（08:00 UTC 前不久）没有数据包丢失的增加。

C-Lion1 切断

该互联网电缆于 11 月 18 日凌晨被切断。同样，作为我们分析的起点，我们查看了德国和芬兰之间路径的锚点网格中的测量数据。这次，在网格中，德国有 100 个锚点，芬兰有 12 个锚点，为我们的分析提供了有用的数据。

在初步数据探索后，我们看到在 02:00 UTC 之后有延迟变化，再次与一些报告相吻合。再次以该时间为重点，我们查看了从 12 小时前到 12 小时后的时间间隔。

图 6 是我们为相关时间间隔生成的一组延迟增加图表之一。该图表显示了芬兰所有 RIPE Atlas 锚点到德国一个锚点的延迟。再次，我们看到受延迟影响和未受影响路径的混合。

使用与上述相同的方法来查找延迟受影响路径的百分比（脚注 1），我们得到了图 7 中的分布：

在这种情况下，我们看到大约 70%的路径没有任何延迟差异（图表的垂直部分），这意味着大约 30%的路径有延迟差异。20%的路径看到延迟增加 5 毫秒或更多。总体而言，这些延迟增加似乎不大。

最后，查看由于此电缆切断可能导致的数据包丢失影响，我们按照脚注 2 中的方法创建了图 8：

在这里，我们看到在大部分时间内基线在 0.5%到 1.0%的数据包丢失之间。同样引人注目的是，事件时间（02:00 UTC）在图表中并不特别突出。这表明该事件没有导致额外的数据包丢失，至少对于我们可以提取的此指标而言是这样。此图表的最突出特征是在图表的最后 2 小时内数据包丢失增加。目前尚不清楚是什么导致了这种跳跃，但由于它与报告的电缆切断在时间上不相关，因此不太可能是切断的直接影响。

结论

本初步报告包含我们对 2024 年 11 月 17 日和 18 日波罗的海发生的两次电缆切断对 RIPE Atlas 锚点网格影响的分析。正如我们所看到的，数据表明测量的路径中有相当一部分（20 - 30%）有延迟增加。但同样值得注意的是，在我们拥有的数据中，我们没有发现更高数据包丢失的迹象。

这一结果表明，就我们用 RIPE Atlas 锚点测量的范围而言，互联网具有弹性。我们无法直接推断锚点之间的哪些路径穿过了受损的电缆。但我们确实看到了间接的切断证据：在报告的电缆切断后，20 - 30%的路径延迟增加。这可能表明采取了替代路线。迂回路线越长，延迟越高。

这表明，在波罗的海地区，互联网设法绕过了发生的损坏 - 对于每条被切断的物理链路，我们看到相对较小的延迟后果，并且没有可见的数据包丢失。这暗示有足够的备份容量来处理此事件。如果不是这样，我们预计我们的数据会看起来非常不同：数据包丢失应该会增加；和/或延迟增加的形状将是逐渐的，而不是我们看到的受延迟影响路径的逐步变化。

如果我们查看电缆地图（ITU，TeleGeography 的海底电缆地图），在波罗的海周围的物理层面有大量冗余，但我不知道有哪些全面的公共数据源可以揭示这些电缆的哪些部分被使用、由谁使用以及在什么条件下使用。假设物理层面的冗余会自动导致端到端连接的冗余是否天真？我不知道。

更可怕的部分是，虽然我们没有看到容量问题，但我们不知道如果另一个链路被切断，或者更糟，如果许多链路被切断会发生什么。在测量方面，我们只能在事后看到互联网是否足够有弹性。在这种情况下，我们看到了良好的弹性（没有可察觉的损失，一些延迟增加），但我们不知道如果其他类似事件发生，未来会怎样。

脚注

1. 对于每个路径（即锚点网格对），我们取在切断前样本中看到的最小延迟，并将其与切断后一小时内看到的最小延迟进行比较。对于第一个事件，我们将 06:45 至 07:45（事件前）和 08:15 至 09:15（事件后）作为我们的时间间隔，即在事件周围取 15 分钟前后作为缓冲。对于第二个事件，我们取 00:45 至 01:45（事件前）和 2:15 至 2:45（事件后）。然后，我们从事件后最小延迟中减去事件前最小延迟，以获得每个 RIPE Atlas 锚点对的延迟差异，我们可以使用此来了解有多少测量路径受到影响以及延迟影响的大小。
2. 在删除在观察间隔期间有 100%丢失的路径后，我们查看每个 RIPE Atlas ping 结果，并将丢失事件定义为 3 个数据包中的任何一个丢失。如果所有 3 个数据包都得到回复，则定义为无丢失事件。图表显示丢失事件相对于所有事件的比例。