为什么 VPN 下载受服务器上行的限制

客户端显示下行很快，服务器接在光纤上，传输却依然很慢。人们比较的数字通常是客户端套餐上印的那个数字，而数据包实际上先经过服务器的出方向接入链路。那条链路才是传输必须落入的预算。在小型家庭宽带上，它就是整条路径中最小的数字。

你读到的那个数字方向错了

面向远程客户端的下载，消耗的是隧道服务器一侧的上行容量。服务器标称的下载速率描述的是相反方向，对这个方向一无所知。同一份不对称在客户端上传时会翻转，所以一个方向感觉良好时，另一个方向可能根本无法使用。

封装开销和任何竞争流量都会占用同一份预算的一部分。只测量客户端的速度测试看不出其中任何一项。

把路径写成一笔预算

列出数据包必须跨过的每一道边界，并给每一道写出同一单位下的数字。源端投递、服务器处理、服务器上行链路、中间路径、客户端下行链路和客户端处理都算在内。可用速率是其中最小者减去开销，超过这个上限的任何调优都不会改变结果。先把这个清单写下来再测量，因为它会告诉你哪个数字不该信。

服务器上行 20 Mbit/s、客户端下行 100 Mbit/s 时，服务器远在客户端察觉之前就已经成为瓶颈。开销和任何并发传输会再切走一份，饱和的上行还会推迟确认，使 TCP 传输降到原始上限以下。这两种效应都不会出现在套餐对比里。

把兆比特和兆字节分开，并说明每个数字衡量的是加密链路上的流量还是应用载荷。把这两者混为一谈，正是预算看起来对不上的最常见原因。给每个数字标上单位和测量点。

主板真正让你付出代价的地方

一旦接入链路足够大，终端硬件才变得可见，也只有到那时处理器才重要。确认型号、接口布局和所用的实现。关于早期主板共享总线的观察，并不能描述后来的每一个版本。

比较单条处理路径，而不是一个 CPU 平均值。中等的总体负载可能掩盖某一个核心已饱和、独自承担全部每包工作的情况；而且主频并不能作为性能分数在处理器设计之间横向搬运。包速率和吞吐量同样重要，因为小包相对于大包每字节更贵。请用你工作负载实际使用的包大小去测量。

温度和功耗上限同样决定持续表现。短时突发看起来可能很漂亮，而十分钟的传输却在降频，所以几秒钟的基准测试对夜间备份来说是很差的参考。

厂商的性能说明把接入带宽、CPU、包处理、传输和包大小分成不同的约束。改动加密算法之前值得读一读，因为换算法很少能挪动一条本来就不是瓶颈的边界。

先测量，再改加密算法

跑一次方向性测试，报告隧道内实际达到的速率，然后在裸接口上跑同样的测试作对照。这两个数字之差就是隧道的代价，而两个上限中较小的那个会告诉你该攻哪一道边界。

对比时保持安全策略不变。用弱算法或超频主板得到的旧结果，不是当前部署的方案。

iperf3 -c 10.44.0.1 -R -t 30
iperf3 -c 10.44.0.1 -t 30
ethtool eth0 | grep -i speed

把方向性结果和同一次运行的端点观察放在一起保存。下一次改动应当瞄准被测出的上限，而不是规格表上看起来最小的那个部件。