作者：Yiannis Psaras 编译：CoinTime 237

这取决于您运行的系统/网络类型。在90%的网络或联网系统中，这是一场大规模的灾难，警报在各处弹出，工程师们超出日常工作范围来恢复正常运行，客户恐慌并可能离开该平台，客户服务热线也处于高峰状态。一半的网络是一个很大的比例，但我敢打赌，即使10%或20%的网络经历了停机事件，情况也会相同。

但是当您在分散式、分布式P2P网络（例如IPFS）上运行服务时，并不是这样！2023年初，IPFS网络的一个关键组件，即公共IPFS DHT，经历了大规模的事件。在此事件中，60％的IPFS DHT服务器节点变得无响应。有趣的是，没有内容变得无法访问，几乎没有任何东西看起来像大部分网络基本上已崩溃。我们确实观察到内容路由/解析延迟显著增加（最初约为25％），但这并没有反映事件的规模。

在这篇博客文章中，我们将从“检测”到“根本原因分析”逐步介绍事件的时间线，并详细介绍工程团队的响应。

检测：我们有问题了！

2023年初，IPFS网络的一个关键组件，即公共IPFS DHT，经历了大规模故障。在此情况下，60％的IPFS DHT服务器节点变得无响应。

这里的“无响应”意味着节点似乎在线，它们会接受其他节点的连接，但它们不会回复请求。基本上，当节点尝试向无响应节点之一写入时，无响应节点将立即终止连接。

鉴于这些节点似乎是功能性的，在其他节点的路由表中占据了多个位置，而实际上它们不应该占据这些位置。

问题归结为 go-libp2p 资源管理器的错误配置——这是kubo-v0.17. 手动应用的有问题的配置（即不基于 的默认值kubo-v0.17）被设置为这样的值，即任何与节点交互的尝试都将被标记为资源耗尽事件，并会触发相应的“防御”机制。实际上，这具体表现为连接断开。值得注意的是，kubo最流行的 IPFS 实现使用公共 IPFS DHT，DHT 中约 80% 的节点是kubo节点。

内容仍然可以通过kubo找到，因此没有引起警报。然而，我们的一些研究团队观察到了异常的错误消息：

由于PUT和GET操作成功完成，该错误似乎不会引发广泛的恐慌。我们看到的是比平常慢的性能，并一直在调查Hydra增强器的最近更改是否产生了比预期更大的影响。就在这时，我们的工程团队进行了一次面对面会议，其中一个议程项目是找出这个错误的来源。

诊断：发生了什么？

我们很快意识到，这里存在一个资源管理器问题，远程节点达到了限制并关闭了连接。在研究了资源管理器和错误本身（即无法保留入站连接）的详细信息后，我们意识到问题的根本原因与远程节点有关。事实证明，由于大量节点手动错误配置了资源管理器，设置的值不在kubo-v0.17随附的“基准”资源管理器的默认配置中，这是问题的根源。

正如前面提到的，GET和PUT操作成功完成，所以我们接下来的步骤是确定问题的规模。我们的主要目标是找出：

l 受影响的网络节点百分比

l PUT或GET操作是否有性能损失，或两者都有

通过联网和尝试连接所有50k个DHT服务器节点（即存储和提供提供程序记录和内容的节点）的组合，我们发现约60％的网络受到了错误配置的影响。显然，这是网络中很大的比例，这使得研究性能影响变得紧急。我们采用以下方法：

1、我们想找出哪些节点在节点的路由表中占据了哪些存储桶。我们发现它们占据了节点路由表的较高存储桶，这意味着PUT操作可能会变慢，但GET操作不应受太多影响。这是因为GET操作的DHT查找在命中目标密钥的20个最接近对等方之一时终止，而PUT操作在找到所有20个最接近的对等方后终止。由于网络的重要部分无响应，PUT操作至少会命中一个无响应节点，但GET操作有很好的机会在20个最接近的对等方中找到至少一个响应节点。

2、经过进一步调查，考虑到资源管理器错误配置影响的节点数量非常多，我们开始研究事件对GET性能的影响。

如果GET请求命中其中一个受影响的无响应节点，远程节点将关闭连接，但请求会卡在那里直到超时，然后重新向另一个对等方发出请求。IPFS DHT具有相对较高的并发因子（alpha = 10），这在这种情况下非常有帮助，因为这意味着对于任何给定的请求，最多可以同时处理10个并发请求。即使有高比例的无响应节点，这也会很有帮助，因为它意味着联系到的10个节点中至少有一个会响应。

与此同时，我们估计，在查找过程中，大量的GET请求都会命中至少一个无响应节点。这个事件结果会导致超时，并显著增加请求延迟。在DHT行走的最后几跳遇到无响应节点的概率很高，因为上面的图表显示，无响应对等方主要存在于更高的存储桶中。

3、为了量化影响，我们抓取了网络并收集了无响应节点的PeerID。我们在全球的几个位置设置了六个kubo节点，并尝试：i）发布内容（PUT），和，ii）检索内容（GET）两个情况：1）与网络中的所有节点交互，以及2）忽略所有来自已知PeerID的无响应对等方的响应，并实时进行交叉核对。

我们发现的结果如下：

l PUT操作速度下降约10％

l 与我们最初的假设相反，GET操作也受到干扰，并且速度下降了约15％，有时甚至接近20％。

4、我们还尝试了更高的并发因子，特别是alpha = 20，作为潜在的缓解策略。我们重复了同样的实验，并增加了一组运行：与网络中的所有节点交互的情况下（即不忽略无响应对等方），但具有更高的并发因子。

我们发现性能提高并回到了事故前的水平。然而，决定不走这条路，因为增加的并发因子会带来以下问题：i）显著增加DHT网络中的开销/流量，并且ii）保留与后来不升级（当事件解决时）的节点保持一致，从而给这些节点带来明显的优势。

缓解措施：如何止损。

我们团队的关注点变成了：

1、添加/更新有关Kubo资源管理器集成的文档；

2、处理和回答用户的问题和问题；

3、准备新的kubo发布版（v0.18.1），其中资源管理器的默认设置被设置为更合适的值，从而减少了需要手动调整资源管理器配置的可能性，避免了配置错误；

4、通过公共论坛和直接与已知大型运营商建立联系，鼓励尽可能多的节点升级。

同时，我们通过仪表化PUT和GET测量实验进行监控，该实验自kubo-v0.18.1更新之前就一直在运行，当受影响的节点逐渐更新时，我们也保持了监控。

kubo-v0.18.1于2023-01-30发布，在前10天内，超过8.5k个节点升级到了这个版本。我们的监控软件使我们能够准确地查看网络状态，并观察到新的kubo版本对GET操作带来了显着的性能提高——与kubo-v0.18.1版之前相比，在样本大小约为2k的请求中，第95个百分位点的性能提高了40％以上。

我们还通过运行实验来监控与事件前性能相比的情况，在该实验中我们忽略了被识别为受错误配置影响的 PeerID 集。作为来自 20k 多个 GET 操作的示例，在下图中我们显示影响已降低至约 5%（2023 年 2 月中旬）。

解决根本原因

我们的即时行动成功止住了流血，并迅速使网络恢复正常。然而，很明显我们必须实施长期修复措施，以保护节点的路由表免受无响应对等方的影响，并避免意外使节点变得无响应。具体来说，需要采取以下措施：

1、重新设计Kubo资源管理器的用户体验，以进一步降低灾难性错误配置的可能性。这在Kubo 0.19中已经完成（opens new window）。

2、仅在路由表刷新期间响应请求的对等方才会添加到路由表中（已完成），并且仅在将节点添加到路由表中时才会添加到路由表中（正在进行中——预计在5月份的Kubo 0.21中完成）。

得到的教训

在此之后的几天里，我们从这次经历中学到了几个重要的教训：

1、对代码库进行重大的基本更改（例如追溯性地添加资源记账）容易造成破坏。这增加了文档、公告和向节点运营商提供明确建议的必要性。

2、应该始终安装监控软件，以帮助从一开始就识别出此类事件。

3、直接监控和应用更改到运行在分散网络的节点上的软件是具有挑战性的。建立良好的沟通渠道可以大大帮助工程团队与社区直接沟通。在IPFS中，我们使用多种渠道，包括Discord服务器、Filecoin Slack、Discourse讨论论坛和博客。

4、最后但同样重要的是，IPFS分散、对等的特性使网络继续运行，并成功完成了所有重要操作（尽管速度比正常情况下慢）。正是由于网络的结构，不存在单点故障，并且即使超过一半的网络节点基本上没有响应，性能也不会发生灾难性的破坏。