GCP 静态 IP 与 VPN 速度：三个变量，一次测试

地址预留之后，传输变快了，结论也就自己写好了。只不过同一项改动还把隧道从 UDP 换成了 TCP，把测试挪到了另一个晚上，而且很可能落到了另一个区域的 VM 上。预留外部地址解决的是生命周期问题：它让端点在各次重启之间保持不变。它没有任何能加速数据包的机制，所以那次实验里的速度差异属于其他变量，而你面前的决策是下一步该测哪一个。

预留地址真正买到的是什么

Compute Engine 区分随实例分配和释放的临时地址，以及你预留并保留的静态地址。这一差别关乎保留与计费，而不是数据包走的路径。稳定的端点对 DNS 记录、远程访问配置、合作伙伴允许列表，以及不应随 VM 重启而改变的防火墙规则确实有用。

这些都是预留一个地址的好理由。没有一条是吞吐量理由。

把层级、地址和传输方式当作三个变量

Google Cloud 还销售 Premium 和 Standard 网络服务层级，两者走不同的路径通往互联网，功能可用性也不同。静态寻址与两者都正交，所以把静态和 Premium 当作关于同一台 VM 的互不相关的事实，而不是同义词。记录实际的层级、区域，以及任何在用的互连或挂接，因为这些东西描述路径的方式，地址标签永远做不到。

三个变量，三次独立实验，否则结果只是故事，而不是测量。

设计一个只回答一个问题的测试

在比较已批准的 UDP 和 TCP 配置时，保持 VM、地址、客户端位置、目的地和工作负载不变。每个传输方式既需要服务器监听端，也需要匹配的防火墙规则；改一个客户端关键字却不动监听端，考验的只是你的耐心。使用可重复的传输，并记录方向、时长、单流与并行流以及单位，因为 MB/s 与 Mb/s 相差八倍。

也要观察 VM 的 CPU，因为小实例在加密或 softirq 工作上会远早于网络饱和，而那个上限看起来会和供应商限制一模一样。

来自 VM 和客户端的重传与丢包计数器能把路径问题和传输问题分开，进度条做不到这一点。用 iperf3 的可操作流程每种传输大约要十分钟。在对端启动服务器，让客户端在每个方向各跑三十秒，每个方向重复三次。丢弃每组的第一次运行，然后把发送端和接收端的速率与 TCP 运行打印出的重传数一起比较。

UDP 与 TCP 在机制上为何不同

UDP 上的 OpenVPN 承载数据报，让应用自身的传输层处理丢包。TCP 上，隧道的可靠字节流位于本已可靠的应用程序字节流之下，于是一个丢失的段会堵住它后面的一切，而外层连接按自己的时间表重传。这种队头行为是 TCP 套 TCP 隧道的性质，不是供应商的策略。MTU 和 MSS 的处理在两种模式下也不同，这会改变同一路径上的分片行为。

因此更快的 TCP 试验只证明那天那条路径上 TCP 更快，证明不了更普遍的东西。

把结果写成经得起复核的样子

站得住脚的结论有一个形状：这个配置、在这个机器规格上、在这个网络层级上，在这些条件下沿这个方向维持了这个实测工作负载。任何更宽泛的说法都需要比一个晚上所能提供的更多次运行。如果较慢的情形仍无法解释，就把它连同数据包和资源证据作为观察记录下来，而不是发明一个没有任何供应商文档描述过的限速。

地址稳定性和传输速度可能对同一次部署都很重要，而有用的决策是每次改动你买的是其中哪一个。