我们想与我们的客户和读者分享今天早上和本周早些时候发生的互联网中断的更多细节，以及我们正在做些什么来防止这些事情再次发生。6月17日事件6月17日08:32 UTC，我们的系统检测到我们的主要传输提供商主干网之一Telia Carrier上的多个目的地之间存在严重的数据包丢失。在我们的工程师分析事故的时间范围内，损失变得断断续续，最后消失了。电信运营商的丢包（AS1299）今天的事件今天，6月20日，协调世界时12:10，我们的系统再次检测到我们的主要传输提供商主干网之一Telia Carrier的大量数据包丢失。电信运营商的丢包（AS1299）通常，传输提供商非常可靠，能够将我们所有的数据包从全球的一个点传输到另一个点而不会丢失—这就是我们付钱给他们的原因。在本例中，我们的包（以及其他Telia客户的包）被丢弃。虽然互联网用户通常认为他们可以从家里和企业到达世界上任何一个目的地，但现实情况比这更严峻。我们的星球很大，互联网管道并不总是可靠的。幸运的是，因特网主要是建立在TCP协议上的，它允许丢失的数据包被重新传输。这对有损链接特别有用。在大多数情况下，您不会注意到这些数据包丢失并被重新传输，但是，当丢失太严重时，就像今天早上的情况一样，您的浏览器不能做什么。我们的系统立即发现问题并记录下来。以下是事件期间检测到的数据包丢失的动画地图：CloudFlare检测数据包丢失（以厚度表示）因为交通服务提供商通常是可靠的，他们往往会很快解决问题。在这种情况下，这并没有发生，我们不得不在协调世界时12:30与Telia一起关闭港口。因为我们与大多数第1层提供商互连，所以我们能够将流量从一个有问题的提供商转移出去，让其他性能更好的提供商来负责传输我们的数据包。对客户的影响我们看到我们的522s错误大幅增加。522http错误表示我们的服务器无法访问客户的源服务器。你可以在这里看到尖峰和崩溃：POP中出现522个错误（到达源服务器时）关于我们的沟通在这种情况下，沟通是关键，同时也是困难的。可以理解，我们的客户希望得到及时、准确的信息，并希望这种影响尽快停止。在今天的事件中，我们发现了我们沟通中的弱点：只有在欧洲才错误地确定了事件的范围，我们的反应时间不够。我们想向您保证，我们正在采取一切措施改善我们的沟通，包括实施自动化检测和缓解系统，这些系统的反应比任何人都快得多。我们已经为我们的小型数据中心准备了这样的系统，并且正在积极测试它们的准确性和有效性，然后再将它们用于更大的pop。在全球范围内取缔一家重要的运输供应商并非易事，在采取行动之前，必须采取许多谨慎的措施。因特网及其相关协议是一个基于相互信任的社区。链条上的任何薄弱环节都会导致整个链条失灵，需要各方通力合作才能成功。我们知道在状态页上交流是多么重要。我们听取了客户的意见，并采取了必要的措施来改善我们的沟通。我们的支持团队正在改进如何更新我们的状态页面，并审查内容的准确性和透明度。构建弹性网络尽管CloudFlare已经发展成为400万个面向互联网的应用程序面前的关键互联网基础设施，但投资于更大的恢复能力仍然是一项正在进行的工作。这是通过将更大的互连、自动缓解和更高的故障转移能力结合起来实现的。我们使用多个传输提供商（如Telia）从公共互联网填充缓存，并使用传输提供商和多个对等关系将流量传输到本地眼球网络。在可能的范围内，我们与我们的供应商保持缓冲容量，使他们能够承受潜在故障对其他多个网络的影响。在供应商之间分散流量可以实现多样性，并减少来自上游提供商的潜在中断的影响。即便如此，今天的事件仍然影响了依赖Telia主干网的相当一部分流量。重新路由后从一个提供商到另一个提供商的流量切换在可能的情况下，我们尝试将流量故障转移到冗余的提供商或数据中心，同时将流量保持在同一国家/地区内。BGP是用于在因特网上的自治网络之间路由数据包的协议。虽然它在保持互联互通方面做得很好，但它没有内置机制来检测路径上的数据包丢失和性能问题。我们一直致力于构建一种机制（它增强了BGP），以主动检测数据包丢失，并将流量从遇到数据包丢失的提供商那里转移出去。因为这个系统目前只对我们最偏远和最小的地点激活，所以在今天早上的事件中没有触发。我们计划在接下来的两周内扩大这一能力，使我们所有的持久性有机污染物从手动反应转变为自动反应。例如，在这个屏幕截图中，您可以看到我们在约翰内斯堡的POP由于连接到源服务器时检测到的问题而自动从我们的网络中删除：约翰内斯堡流行音乐优雅地失败了最近的流行音乐摘要我们了解我们的基础设施对客户业务的重要性，因此我们将继续向全自动化系统发展，以处理此类事件。我们的目标是尽可能减少客户的中断和停机，而不管问题的起因是什么。