路由器或笔记本的 CPU 不够用？VPN 速度为何提前见顶

路由器宣传着快速的 Wi-Fi，却难以同时为三台设备加密流量。笔记本已经触到处理上限，而接入链路仍有富余。人们通常先怪服务器，而服务器通常是无辜的。瓶颈就在执行隧道工作的那台机器上，找到它意味着盯住这台机器，而不是盯住测速。

症状指向一台机器，而不是互联网

隧道在哪里运行，就决定了由哪个处理器来付账。如果由路由器终结，每个被覆盖的客户端都要共享这台路由器的预算。如果客户端跑在笔记本上，付账的是笔记本，路由器不付。两端都跑隧道会制造两份工作负载，其中任何一份都可能在另一天成为瓶颈。点明是哪台机器是第一步，而这恰恰是人们在向服务商提工单时跳过的一步。

数清应用与远端之间的设备，然后标出真正做加密的那一台。其余的只是它读不懂的字节的搬运者。

在传输过程中观察每个核心的负载

看总体 CPU 百分比是错的工具，因为加密工作常常把一个核心钉死，其余核心却在闲置。在受控传输中查看每个核心的数字，注意是否有一个核心接近饱和。平均负载中等而单线程很忙是很强的信号，平均负载很高却没有忙线程，通常意味着与本次传输无关的程序。模式比数字更重要。

mpstat -P ALL 1 5
top -H -b -n 1 | head -20
lscpu | grep -i -E "model name|aes"

第三条命令告诉你处理器是否提供 AES 指令，这会让同一种密码的开销相差很大。它并不告诉你 VPN 实现是否在用这些指令，而这两个事实之间的落差正是大多数优化说法的来源。

把加密与数据包处理分开看

加密只是若干开销之一。在内核与用户态之间拷贝数据包、路由查找、防火墙规则和接口处理都有贡献，有些实现为拷贝付出的代价甚至高于密码学本身。注意哪个计数器随传输一起上升，而不要指望进程名能解释每一个时钟周期。用户态隧道与内核内隧道对同样的流量可能呈现完全不同的画像。

如果一个核心在内核内部很忙，处理办法与用户态里的忙线程不同，而画像会告诉你属于哪一种。在买硬件之前，这个区分值得花上一小时。

下结论之前要同类相比

只有任务、接入网络和终点都保持不变，比较才有意义。换掉服务器，结果里就带上了那台服务器的路径与容量；换掉网络，结果里就带上了运营商。使用同一个文件、同一个目的地和一天中的同一时段，并暂停你自己的后台任务。如果必须换设备，就只换设备。

供电与温度会改变持续性能，所以冷机器上的短跑与热机器上的长传输不是同一种测量。比较相近的供电条件并记录下来，因为图表上的温度限制看起来和处理限制一模一样。

使用受支持的卸载加速，并确认它真的生效

有些实现可以把数据路径的一部分移进内核或硬件，能否使用取决于客户端、操作系统、服务端和配置。阅读你所运行版本的文档，并用它自带的状态输出或日志确认该功能已经开启。装了包或勾了选项并不能作为证据。OpenVPN 手册记录了它自己各版本的数据通道选项，而这些选项在不同版本之间并不相同。

当受支持的改动把天花板推高时，重跑应用任务和一次大流量传输，并保留之前的画像以便回退。大流量速率翻倍而应用仍然慢，说明瓶颈只是被挪走，而不是被消除。

如果处理器上的观察与症状对不上，回到网络这一侧。Wi-Fi 重传、排队和出口路径完全不需要 CPU 参与，也能做出同样的结果。