提升 Tailscale 性能

# 我们正在让 Tailscale 变得更快 来源：https://tailscale.com/blog/making-tailscale-faster 如果你一直关注 Tailscale，就会知道我们其实就是一群非常在意互联网连接的极客。我们喜欢讨论的话题之一就是 NAT 穿透。这是 Tailscale 的核心增值功能之一：我们驯服了 NAT（https://tailscale.com/blog/nat-traversal-improvements-pt3-looking-ahead）。并非所有网络都是友好的，但 Tailscale 仍能在各种条件下找到传输路径。对于互联网协议而言，这并非唯一重要的方面：数据平面的性能同样至关重要。 多年来，我们一直投资于提升 Tailscale 的速度。我们首先提高了 Linux 设备的 TCP 吞吐量（https://tailscale.com/blog/throughput-improvements）。随后，我们在 wireguard-go 上取得重大突破，在裸金属上实现了超过 10Gb/s（https://tailscale.com/blog/more-throughput）的速率。之后，我们利用分段卸载技术，将基于 UDP 的应用的吞吐量提升了 4 倍以上（https://tailscale.com/blog/quic-udp-throughput）。在改进数据平面的同时，我们还构建了如 Tailscale 对等节点中继（https://tailscale.com/blog/peer-relays-beta）这样的基础功能，它能在复杂条件下提升网络性能（https://tailscale.com/blog/peer-relays-international-networks）。 所有这些改进使得 Tailscale 能够适用于更多性能敏感的工作负载。这意味着你可以将 Tailscale 用于持续集成、智能体工作流、远程开发环境、机器人边缘设备、繁重的数据和遥测任务等等。Tailscale 能帮助这些设备在各种网络条件下建立连接。 所以，是的，我们认为 Tailscale 已经很快了。但我们也相信我们可以让它变得更快。 今天，我们将详细介绍如何利用多队列技术（预计在 2026 年下半年上线）来提升应用连接器、子网路由器和出口节点的吞吐量。我们还将预览即将在稳定版客户端中部署的一些吞吐量和内存开销改进。此外，我们将探讨我们希望为客户解决的一些性能诊断工具问题。 ## 小数据包的内存开销更低（https://tailscale.com/blog/making-tailscale-faster#less-memory-overload-for-small-packets） 大多数网络数据包都很小，比如 1 KiB。但为了使用 Linux 最高效的吞吐量工具（如通用接收卸载，GRO），Tailscale 必须准备好一次性接收高达 64 KiB 的流量。这有点像集装箱运输：港口、船舶和卡车都是为一种标准尺寸的集装箱设计的，无论它装得多满。 Tailscale 必须拆解这些“集装箱”——每个数据包都需要单独解密并送达。为 Tailscale 加密和网络核心功能提供支持的 wireguard-go 实现，只提供一种 64 KiB 的缓冲区用于解包。因此，一个 1 KiB 的数据包每次都要被复制到自己的 64 KiB 缓冲区中。这是一个非常有价值的优化目标。 在 Linux 和 Android 上，Tailscale 现在让数据包留在它们被读取的位置。它在单次大型读取操作中识别每个数据包的起始和结束位置，而不是将其复制到新的位置。小型数据包在内存中保持小型，多个数据包共享一次分配，并且它们被复制的时间更少。这本身就在许多网络配置中带来了大约 5% 的速度提升。 比较数据包缓冲分配优化前后的示意图。优化前：三个数据包各自被复制到单独的 64 KiB 缓冲区，存在未使用空间。优化后：三个数据包按大小和目标标记，合并到一个缓冲区中，用分隔符隔开。此外，我们缩短了数据包队列——即数据包在管道各阶段之间排队等待的队列。队列是为了吸收突发流量而存在的。测试表明，大部分队列深度并未被使用，而较短的队列意味着更短的等待时间和更低的内存开销。 我们将释放出的这些内存空间用在了何处？我们将这些节省下来的资源传递给了部分工作最繁重的节点：子网路由器和应用连接器。 ## 面向子网路由器、应用连接器和出口节点的多队列技术（https://tailscale.com/blog/making-tailscale-faster#multi-queue-for-subnet-routers-app-connectors-and-exit-nodes） 子网路由器（https://tailscale.com/docs/features/subnet-routers）在不同 tailnet 中看起来可能完全不同。对于运行小型家庭实验室网络的人来说，一个子网路由器可以轻松处理一小批 `192.168.x.y` 非 Tailscale 设备。而一个为拥有数百个对等节点的云部署服务的子网路由器，则将承载多得多的流量。 直到最近，子网路由器、应用连接器和出口节点都在一个有序的、单线程的管道中处理来自多个独立流的数据包。这意味着一条车道被许多连接共享，因为接收应用程序永远不能看到自己的数据包乱序到达。 在减少了内存占用后，我们有了实现多队列系统的容量：使用多条车道而非一条，其规模取决于机器资源而非对等节点数量。每个数据包流获得一条车道并保持在其中，而这些车道并行运行，允许工作负载分布到多个 CPU 核心。 比较单管道与多队列处理架构的示意图。优化前：数据包通过一个 Reader，经过四个 Crypto 阶段，然后 Writer 输出到 Devices。优化后：数据包分布到四个并行的 Reader-Crypto-Writer 管道，然后输出到 Devices。其结果是，子网路由器和应用连接器的总吞吐容量更高，接收和转发数据包之间的延迟更低。你已有的硬件得到了更高效的利用。应用连接器和出口节点通常为许多用户服务，使用短暂连接，因此会获得特别明显的提升。 Tailscale 技术团队成员 Alex Valiushko 表示：“这转化为更低的延迟，本质上意味着从我们在网线读取数据到将其发送给操作系统的整个过程处理得更快。” ## 通过 `writev` 提升吞吐量（https://tailscale.com/blog/making-tailscale-faster#throughput-gains-with-writev） 利用 Tailscale 客户端中 Linux 的 `writev` 功能（https://linux.die.net/man/2/writev），Tailscale 可以在一次操作中将多个数据包数据片段传递给 Linux 内核，而不必在将这些片段传递给内核之前先复制并组合它们。`writev` 中的 `v` 代表“向量”：Tailscale 可以描述需要移动的独立数据片段，而无需实际移动它们。这意味着内存中数据包数据的复制次数更少，写操作更少，吞吐量更高。 ## 通过 netmap 缓存实现更快启动（https://tailscale.com/blog/making-tailscale-faster#faster-startup-with-netmap-caching） 目前，这些速度提升仅适用于 Linux 以及（在适用情况下）Android 系统。但我们也在开发适用于其他系统的功能。Tailscale 客户端很快就能在许多情况下使用 **netmap 缓存**来更快地启动。 一台机器连接到 Tailscale 时，通常首先连接到 Tailscale 的控制平面，在典型网络上大约需要 100 毫秒。该机器进行身份验证并获得一个“网络映射”（netmap），描述它可以访问的设备以及如何访问它们。这个启动过程应该感觉很快，可能是瞬间完成的，在良好的网络连接下通常确实如此。 但当你使用糟糕的飞机 Wi-Fi、在过滤严格的酒店内、或处于其他连接状况不佳的环境中时，机器可能需要较长时间才能连接到控制平面——有时甚至可能完全无法连接。通常很难明确问题出在哪里，但其影响是你无法连接到其他设备。 即使在理想的网络条件下，100 毫秒的启动延迟对于某些延迟敏感的工作负载也可能过长。 Netmap 缓存可以在控制平面无法快速访问时帮助机器建立连接。启用后，你 tailnet 中的每个设备都会将 netmap 的副本存储在磁盘上。当设备启动时，它可以使用该缓存副本与 tailnet 中的其他设备建立连接，直到它能够联系控制平面获取最新信息。（这些连接由设备之间直接协商，Tailscale 不会像往常一样看到任何流量。） 技术团队成员 Claus Lensbøl 表示：“糟糕的网络条件，这正是人们可以从 netmap 缓存中获得大量实用价值的领域。设备客户端会说，‘你知道吗？我们还没和控制平面通信上。我们可能很快就能联系上。在此期间，你仍然可以开始做一些事情。’” 存在一些限制。缓存仅在设备之前至少连接过一次 tailnet，从控制平面获取过网络映射时才有效。此外，netmap 缓存需要设备拥有持久磁盘空间来存储缓存。我们已注意尽量减少不必要的磁盘写入，但在某些情况下你可能不想启用它。例如，在非常大的 tailnet 中，更新缓存可能需要大量的磁盘 I/O。同样，使用慢速或易磨损存储（如 SD 卡）的设备可能倾向于不启用 netmap 缓存。 然而，对于大多数 tailnet 上的大多数设备而言，此功能可以显著加快设备在启动时相互建立连接的速度。我们看到一些控制平面可达性较差的 tailnet，在“热”缓存启动时，开始通过数据平面发送数据的速度比“冷”启动时快了一到两个数量级。对于面临启动延迟变化、或远离 DERP 服务器或控制平面的设备，其益处尤为明显。 ## 何时能看到所有这些速度提升（https://tailscale.com/blog/making-tailscale-faster#when-you-can-see-all-these-speed-ups） - 通过缓冲区更改实现的 **内存减少**（Linux/Android）预计将在 v1.104 客户端中发布。 - 使子网路由器和应用连接器受益的 **多队列** 技术计划在 v1.104 之后的一个版本中发布。 - **吞吐量提升**（Linux/Android）已于 2026 年春季部分实施；利用内存和吞吐量方面的额外收益计划在 v1.104 之后的一个版本中发布。 - **Netmap 缓存** 作为功能标志在当前 Tailscale 客户端中可用；预计在进一步测试后，将在 v1.104 中默认启用。移动客户端预计在 v1.104 之后的一个版本中获得此功能。 ## 性能诊断和测试仍然困难（https://tailscale.com/blog/making-tailscale-faster#performance-is-still-difficult-to-diagnose-and-test） 当然，我们认为 Tailscale 很快。但你不应该仅仅相信我们的话。这就是为什么我们正在探索一个 Tailscale 专用的监控和测试工具包。我们希望以一种 Tailscale 原生的方式，为我们的客户提供所需的工具，以测试、诊断和理解他们的网络配置。 以下是我们认为在现代性能测试中存在的差距： - **分发成本：**大多数性能工具都是端到端的，需要你在每个终端上安装某些东西。 - **工作流僵化：**很容易运行错误的测试，获得错误的输出，并追逐一个并不存在的问题。 - **协议支持：**许多工具不支持较新的协议，如 QUIC 和 HTTP/3。 - **Tailscale 感知：**通用工具并非 Tailscale 原生。它无法告诉你连接是使用 DERP 还是直连，对等节点中继是否有帮助，或者连接路径随时间如何变化。 现有工具不理解 Tailscale 原生的路径和状态。因此，我们正在探索能够理解这些的工具。帮助我们塑造 Tailscale 性能测试的未来（https://tailscale.typeform.com/performance）。