Tailscale 如何突破性能瓶颈
Making Tailscale Faster
我们一直在死磕互联网连接技术，尤其是 NAT Traversal。为了让 Tailscale 跑得更快，我们不仅优化了 Linux 和 Android 上的内存开销，让小包处理更高效，还为 Subnet Routers 和 App Connectors 引入了多队列技术，充分利用 CPU 多核并行处理。此外，通过利用 Linux 的 writev 能力减少数据拷贝，以及推出 netmap caching 功能，即使在网络恶劣的环境下也能实现秒级启动。这些改进让 Tailscale 能更好地服务于 CI 流水线、远程开发等对性能敏感的场景。
糟糕的网络环境，正是人们能从 netmap caching 中获得巨大实用价值的地方。
HN 评论区
43- apenwarr
(Tailscale 联合创始人) 我看到这里有几条评论说使用 kernel wireguard 会让速度更快；事情没那么简单。事实上，有一段时间（我们也写过一篇博客），我们的优化让 wireguard-go 比 kernel wireguard 更快，因为它的优化做得更好。他们采纳了其中一些改进，现在我们正一起迈向下一个数量级的提升。
对于真正的高带宽场景，像 DPDK 这样的技术是长期的最佳选择，而且主要是用户态的，原因很充分。内核模式并不像以前那样（如果它曾经那样过）是纯粹的优势了。
另外，wireguard 本身也有个问题：它使用的加密套件不被硬件加速器支持。所以，如果我们想达到数百 Gbps 的级别，可能完全需要更换数据包格式。（不过，wireguard 本身也需要更新以支持后量子密码，也许他们会同时解决这两个问题，到时候我们也能加入进来。）
- iscoelho
在我看来，这是 Tailscale 最大的问题。
它太慢了。在客户端系统（Windows 和 Mac）上，它无法实现超过 1Gbps 的速度，而这正是人们通常使用它的场景。在 Linux 上，即使使用合成的大数据包基准测试 [1]，它也难以达到 10Gbps。如果用 IMIX 基准测试，它根本没有任何竞争力。
这个问题是可以解决的。WireGuard 能实现更高的性能（内核版 vs 用户态版），而 IPsec 实现可以达到 100Gbps/400Gbps（通过 DPDK/XDP）。零拷贝网络。
从这篇博客来看，Tailscale 似乎还没有这方面的意愿，这很可惜。
- fitblipper
我过去超级喜欢 tailscale。后来我在家庭网络上部署了 wireguard，并通过动态 DNS 提供商将其暴露在公网上，tailscale 立刻变得无关紧要了。不仅原生的 wireguard 更稳定（我不再需要在手机上跟 DNS 问题搏斗），它感觉更快，而且设置起来简直简单得惊人。
- CharlesW
我想知道这篇帖子的重点之所以放在 Linux/Android 上，仅仅是因为那是他们的起步平台，还是因为他们正在利用那些仅在 Linux/Android 上才可行的技术？
- ykurtov
在我们的使用场景中，当隧道中 250 个会话仅传输 60 mb/s 的数据时，延迟呈抛物线式飙升。