QUIC 协议支持

大多数 Lighthouse 用户都知道，默认情况下，Lighthouse 监听两个端口，TCP 9000 和 UDP 9000。自上次发布以来，我们添加了第三个端口（UDP 9001）。在这篇文章中，我们将解释原因，如果你是 Lighthouse 用户，如何支持它，并希望降低一些系统资源。

如果你没有阅读这篇文章的其他内容，那么你真正需要知道的唯一一件事是，如果你正在运行 Lighthouse，请更新到 v4.5.0，并在你的路由器中为 UDP 9001 添加端口转发。

QUIC

一切都始于 QUIC。QUIC 是一种通用的传输层网络协议，允许两台计算机以可靠和安全的方式交换数据。对于对细节感兴趣的技术读者，wiki 页面提供了一个很好的概述。

直到之前的版本，Lighthouse 与网络上其他节点通信的主要方式是通过 TCP 传输。这是互联网上大多数计算机通信的久经考验的方法。最近（在事物的时间尺度上），人们努力构建一种新的协议来优化这种通信。其中一项努力就是 QUIC 协议。

为了给出一个高层次的概述，让我们首先描述 TCP，然后介绍 QUIC 以及它如何改进 TCP。随着网络应用程序在近年来不断发展，越来越多的复杂性建立在诸如 TCP 之类的基础通信协议之上。在许多现代应用程序中，这些协议一个叠着一个。作为一个例子，考虑连接到一个网站。

1. 此连接首先需要我们建立一个 TCP 连接，这需要在我们的计算机和 Web 服务器之间来回发送 3 条消息（SYN，SYN + ACK 和 ACK）。

2. 建立 TCP 连接后，我们通常希望在新连接上发送的信息被加密、认证和检查完整性。因此，我们建立某种加密协议，如 TLS，这需要在已建立的 TCP 连接之上，双方之间发送额外的消息（在 TLS 1.3 的情况下为 3 条）。

3. 在此之上，我们就可以开始与 Web 服务器交换信息了。在应用程序中（如在 Lighthouse 中），我们可能希望对多个协议使用相同的连接，这称为多路复用，需要在原始 TCP+TLS 连接之上再添加一个协议层。

在 TCP 的情况下，加密握手（上面的步骤 2）只能在连接建立后（步骤 1）运行。这至少需要 2 个往返。QUIC 通过将连接建立握手（步骤 1）和加密握手（步骤 2）结合在一起，从而改进了这种设计，因此只需要 1 个往返。这是延迟的显著降低。

最后，QUIC 还结合了多路复用（步骤 3），从而可以进行各种优化，例如防止连接级别的 head-of-line\ blocking。

Rust libp2p 实现一直在努力将 QUIC 集成到他们的库中，并进行了一些初步的 基准测试，比较 QUIC 与我们一直在使用的 TCP 传输。一些结果看起来很有希望。

最初的基准测试表明，与 TCP 传输堆栈相比，在延迟和吞吐量方面都有显著的提高。延迟的提高是由于 QUIC 握手本身的改进，即通过更好的协议设计进行的改进。吞吐量的提高是由于 Rust QUIC 实现中更复杂的多路复用器实现（即 Quinn）。与我们的 TCP 堆栈中使用的多路复用器实现（即 Rust Yamux 实现）相比（实现级别），QUIC 实现可以更好地饱和连接。对于狂热的读者，你可以在 https://github.com/libp2p/rust-yamux/issues/162 中阅读更多内容。总的来说，结果非常引人注目，以至于我们认为我们应该通过将 QUIC 引入到 Lighthouse 中来在实践中进行测试。

Lighthouse 和 QUIC

我们在 v4.5.0 中将 QUIC 引入到 Lighthouse 中。如果你已将 Lighthouse 节点更新到最新版本，则很有可能已启用 QUIC。但是，利用此传输方式存在一些注意事项。首先（也可能是最重要的），Lighthouse 现在监听一个新的 UDP 端口（默认为 9001）。可以通过 CLI 标志 --quic-port 和 --quic-port6（对于 IPv6）进行设置。也可以通过 --disable-quic CLI 标志禁用 QUIC。

由于 Lighthouse 现在监听一个新的 UDP 端口，为了能够被联系到，用户现在必须确保他们的节点可以通过这个额外的 UDP 端口进行联系，以便利用 QUIC 传输的优势。这可能意味着在你的路由器中添加一个新的端口转发映射，和/或打开你的本地防火墙。

其次，应该提到的是，此升级是完全向后兼容的。我们仍然支持 TCP，并且这是与所有其他客户端的首选连接（因为当前规范规定）。QUIC 将仅与其他的 Lighthouse 节点进行功能与尝试连接，因此我们应该仅在 Lighthouse <-> Lighthouse 连接之间开始看到好处。你的 Lighthouse 对等节点越多，你应该拥有的 QUIC 连接就越多（前提是你的对等节点已升级到最新的 Lighthouse 版本并转发了他们的 QUIC 端口）。

自从 v.4.5.0 版本发布以来，我们一直在跟踪我们在主网上看到的连接类型。下面给出了过去一周来自单个主网节点的示例。

这个特定的节点平均（在过去的一周中）拥有 50 个 Lighthouse 对等节点。如果所有这些对等节点都使用最新版本的 Lighthouse 并且通过 QUIC 连接，我们预计会看到大约 50 个 QUIC 连接。自发布以来，网络上的 QUIC 连接数量有所增加，但这仍然表明大多数 Lighthouse 用户要么尚未更新他们的客户端，要么尚未通过 QUIC 端口使他们的节点可联系。我们一直希望看到此图中的 QUIC 连接随着时间的推移而增长，但目前停滞不前。

我们正在分析这些连接，以统计方式确定对于这些类型的连接是否存在显着的性能改进，并且网络上支持这些连接的 Lighthouse 节点越多，我们可用于分析的数据就越多。

总结

如果你是 Lighthouse 用户，并且想要帮助我们进行 QUIC 实验，或者想要尝试获得性能更高的 Lighthouse 节点，请更新到 v4.5.0 并端口转发 UDP 端口 9001。一旦我们收集并审查了足够的数据，我们将发布一篇后续文章，其中包含这些连接的性能结果，如果它们非常积极，则可能会旨在鼓励规范的采用。

• 原文链接： blog.sigmaprime.io/quic-...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～