在Vultr上组建同机房集群时，内网链路是节点间通信的主要通道。数据库主从复制、Redis集群Gossip协议、消息队列的副本同步，都依赖这条链路。如果内网带宽上限很低，或者延迟抖动明显，业务层往往需要增加重试和限流，甚至被迫拆分数据分片。因此，在方案落地前先对内网做一次压测，比上线后被动排查要划算得多。
本次测试选取位于新泽西数据中心的两台High Frequency实例，规格为4 vCPU、8GB内存，操作系统为Ubuntu 22.04 LTS。两台实例均启用Vultr的私有网络，并通过内网网卡获得10.116.0.0/16网段的地址，分别为10.116.0.3和10.116.0.4。测试期间关闭防火墙规则对测试端口的限制，并使用官方软件仓库中的iperf3 3.9版本进行带宽测量。
一、测试环境与准备
Vultr的内网功能默认在创建实例时需要勾选Enable Private Networking，创建后系统会新增一张内网网卡。以Ubuntu为例，可以通过ip addr查看第二张网卡，通常命名为ens7或eth1，并自动获取10.x.x.x地址。需要特别注意的是，Vultr的内网流量在同一账号同一数据中心内免费，但不会自动跨区域转发。如果多台实例位于同一机房，配置内网互访非常简单，不需要额外购买交换机或VPC网关。
为了避免公网链路干扰，本次测试全部通过内网私有IP进行，不经过任何NAT或负载均衡器。测试前先确认两台机器可以通过内网互相ping通，并且MTU保持默认1500，后续再单独测试巨帧。为了减少宿主机邻居带来的偶然抖动，每组测试重复三次，取中间值或平均值作为参考。
# 查看内网网卡和地址 ip addr show ens7 # 内网连通性测试 ping -c 20 10.116.0.4
本次拓扑为两台实例直连内网网卡。实际测试中，Vultr同机房内网并不是物理直连，而是经过数据中心内部的虚拟交换机转发。这个虚拟交换机和宿主机上的邻居实例共享链路，因此测试结果会受到宿主机整体负载的影响。这也是为什么单次测试数据不适合直接作为SLA依据，需要多次测量并结合业务峰值时段评估。
二、iperf3单流与多流带宽测试
iperf3是评估TCP和UDP吞吐的常用工具。先在接收端启动服务，再在发送端发起连接。默认单流测试能反映单个TCP连接的传输能力，但TCP窗口和拥塞控制会影响结果。多流测试用-P参数并行多个连接，可以更充分地占用物理链路，同时也能观察多连接场景下的总带宽能否接近网卡上限。
本次先运行30秒单流测试，命令如下。接收端执行iperf3 -s，发送端指向内网IP。为了避免结果受TCP慢启动影响，测试时间设置为30秒，并在统计时剔除前2秒的爬升过程。
# 接收端 iperf3 -s # 发送端：单流TCP测试 iperf3 -c 10.116.0.4 -t 30 -i 5
单流测试稳定后，发送端平均带宽约3.2Gbps，接收端显示约3.18Gbps，重传次数为零。这个数值说明单个TCP连接已经能获得接近3Gbps的吞吐，但距离网卡标称的10Gbps仍有明显差距。限制因素可能包括内核TCP参数、虚拟网卡队列深度以及宿主机调度延迟。接下来用四路并行连接测试，命令中增加-P 4。
iperf3 -c 10.116.0.4 -t 30 -P 4 -i 5
四流并发时，总带宽提升到7.5Gbps左右，每个流的带宽在1.8Gbps到2.0Gbps之间波动。这说明多连接可以更好地利用链路，也说明内网本身并非严格限制在1Gbps或3Gbps，而是动态共享的。对于数据库复制这类通常只使用单连接的场景，3Gbps已经足够；对于批量数据传输或分布式计算中的并发连接，7Gbps以上的能力更具吸引力。
UDP测试则能反映丢包和抖动情况。使用iperf3的UDP模式，设置目标带宽为8Gbps，观察接收端丢包率。实测在7Gbps以下几乎不丢包，超过7.5Gbps后丢包率快速上升。Vultr同机房内网的虚拟交换机对UDP流量没有额外优化，因此如果业务对丢包敏感，建议将单流目标带宽控制在实测稳定值的80%以内。
三、延迟、丢包与TCP行为分析
带宽只是内网质量的一面，延迟和丢包对数据库事务和消息系统的影响更大。使用ping进行64字节ICMP测试，连续发送1000个包，平均往返时间约0.32ms，最大延迟约1.8ms，抖动很小。这个延迟水平远低于公网常见的几十毫秒，适合强一致性的主从复制。带批量数据的TCP请求，实际延迟会比ICMP略高，因为需要等待数据帧组装和中断处理。
ping -c 1000 -i 0.1 10.116.0.4
在TCP行为方面，可以通过查看重传统计判断网络稳定性。iperf3在测试结束时会在发送端打印retr字段，表示重传次数。单流测试中retr为0，多流测试中偶尔出现个位数重传，对应丢包率低于0.001%。使用ss -ti可以进一步观察TCP连接的重传超时和拥塞窗口变化。总体来看，Vultr同机房内网的TCP重传极低，拥塞窗口能快速爬升到较高水平，适合长连接和大包传输。
还有一个值得注意的现象：当宿主机上其他租户实例产生突发流量时，ping延迟可能瞬时升高到5ms以上。这种邻居噪声在共享虚拟网络中难以完全避免，但Vultr的实例隔离策略和网络限速机制会把影响控制在较低范围。对于生产环境，建议在业务高峰期做短周期监控，观察延迟P99是否超过阈值。
四、影响内网性能的关键因素与优化建议
影响Vultr同机房内网性能的第一个因素是实例套餐。High Frequency实例使用更高主频的CPU和NVMe存储，网络端口也更大，实测能稳定跑到7Gbps以上。普通Cloud Compute实例的内网吞吐通常较低，可能在1Gbps到3Gbps之间波动。如果内网带宽是瓶颈，升级到High Frequency或Bare Metal实例会带来显著改善。第二个因素是MTU。默认1500字节在虚拟交换机上需要分片处理，如果两端都支持巨帧，可以提高有效载荷占比，降低CPU中断次数。
启用巨帧需要将内网网卡的MTU调整到9000。Vultr同机房内网对巨帧支持良好，但需要两端同时生效，并且中间不能经过不支持巨帧的网关。调整命令如下。
# 临时设置MTU
sudo ip link set dev ens7 mtu 9000
# 永久写入netplan
network:
version: 2
ethernets:
ens7:
mtu: 9000
dhcp4: true
调整MTU后，单流带宽可提升约8%到12%，CPU占用略有下降。对于数据库备份、文件同步等大块数据传输场景，这个提升是可观的。但要注意，如果业务中混用公网和内网，或者内网对端未开启巨帧，会产生IP分片异常，导致部分连接不可用。建议先在测试环境验证，再推广到生产节点。
第三个因素是内核网络参数。Linux默认的TCP拥塞控制算法、接收缓冲区和队列长度都会影响高带宽长距离网络，但在同机房低延迟环境下，默认参数通常够用。可以适当增大net.core.rmem_max和net.ipv4.tcp_rmem，避免高速单流因窗口受限而无法跑满。对于多流并发，开启TCP窗口缩放和SACK即可。如果业务对延迟极其敏感，可以调整网卡中断合并策略，但内核版本和虚拟化环境会限制部分参数生效。
# 增大接收缓冲区 sudo sysctl -w net.core.rmem_max=16777216 sudo sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
最后，从系统设计角度考虑，不要把所有节点都压在同机房内网上。Vultr同机房内网适合低延迟、高吞吐的同城集群，但跨机房容灾仍需单独规划。多机房之间的数据同步应走公网加密隧道或专线，并配合异步复制降低对实时带宽的依赖。如果你正在评估Vultr用于生产集群，建议在业务正式上线前，用本文的方法做一轮完整的内网压测，并记录不同时段的数据，作为容量规划和告警阈值的依据。
