讓 Tailscale 速度更快 （★ 108 分）
Tailscale 宣布針對 Linux 與 Android 的資料平面（實際轉送流量的部分）進行一連串效能改良。首要目標是減少小型封包的記憶體浪費：為使用 Linux 的 Generic Receive Offload（GRO，通用接收卸載）機制，程式過去會以 64 KiB 緩衝區處理封包，約 1 KiB 的常見小封包也因此被複製到過大的空間。新版改為直接標示封包在原始緩衝區內的位置，不再逐一複製；加上縮短處理管線中的佇列深度，可降低等待時間與記憶體負擔，許多網路情境的速度約提升 5%。
針對子網路路由器、應用程式連接器（app connector）與出口節點（exit node），Tailscale 將原本所有流量共用的單一依序處理管線，改為多佇列架構。每條連線會固定分派至其中一條佇列，以維持封包順序，同時讓多個 CPU 核心平行處理不同流量，提升總吞吐量並降低轉送延遲；短暫連線多、使用者較多的應用程式連接器與出口節點，預期收益尤其明顯。另藉由 Linux 的 writev 系統呼叫一次交付多塊分散的封包內容，省下合併與複製動作，進一步提升吞吐量。小封包記憶體改良預計納入 v1.104，多佇列及其餘傳輸改良則規劃在其後版本推出。
跨平台部分，Tailscale 即將預設啟用 netmap 快取：裝置曾連上私人網路後，會將可連線裝置及路徑資訊保留在磁碟中。日後若控制平面暫時難以連上，例如飛機 Wi‑Fi、飯店嚴格過濾網路，裝置仍可先用快取資訊直接與其他裝置建立連線；在控制平面可及性不佳的環境中，暖啟動速度可比冷啟動快一至兩個數量級。不過大型私人網路的快取更新可能帶來較多磁碟 I/O，使用 SD 卡等低速或容易耗損儲存媒體的裝置未必適合開啟。公司也正規劃 Tailscale 原生的監測與測試工具，以辨識連線是直連或經 DERP（Tailscale 的加密中繼伺服器）轉送，並補足既有工具對 QUIC 與 HTTP/3 等新協定及動態路徑變化的掌握不足。
Hacker News 討論普遍肯定 Tailscale 免開通連接埠、可快速新增裝置，以及穿越 NAT（網路位址轉換）環境的便利性；不少使用者認為，與自行架設 WireGuard 相比，Tailscale 省去連接埠轉送、動態 DNS（DDNS，動態網域名稱服務）、逐台設定金鑰等維護工作。不過也有人指出，純 WireGuard 並不需要憑證，家用路由器或小型電腦便可輕易架設，且能保有完整掌控權；在一般家用網路頻寬下，兩者效能差異未必可感。
效能仍是最主要的質疑點。有使用者回報，在約 250 個工作階段、總流量僅約 60 Mb/s 時延遲急遽惡化；批評者也認為 Windows 與 macOS 的吞吐量仍有限，並主張 Linux 應採核心層 WireGuard 或零複製網路技術。Tailscale 共同創辦人回應，核心模式不必然較快，過去經過調校的 wireguard-go 曾超越核心實作；未來若要進入數百 Gb/s 等級，較可能依賴 DPDK（Data Plane Development Kit，高速封包處理框架）等使用者空間技術，且 WireGuard 現行加密套件不易使用硬體加速，可能需配合後量子密碼學的下一代協定重新設計封包格式。對 DNS 隱私的疑慮，創辦人則表示，若 DNS 伺服器位於 Tailscale 私人網路內，傳統 UDP DNS 已由加密通道保護；DNS over HTTPS（DoH，以 HTTPS 封裝的 DNS）在此情境增益有限，反而增加 TLS 憑證維護負擔。
👥 43 則討論、評論 💬
https://news.ycombinator.com/item?id=49819880