同数据中心带宽在大规模微服务、数据库主从同步、分布式文件系统等场景中是容量规划的关键指标。DigitalOcean 的云服务器 Droplet 之间如果走私有网络，流量不会被计入公网出站配额，因此很多团队会优先使用同区域内部通信。但不同类型的 Droplet 内网吞吐量并不一致，实际带宽还与 CPU 核心数、虚拟网卡队列、TCP 缓冲区大小等因素相关。为了得到可复现的数据，我们设计了一组 iperf3 基准测试，在 NYC3 数据中心创建两台同区域 Droplet，分别安装 iperf3 并测试不同线程数下的吞吐量。下面从环境准备、实测数据、影响因素和优化建议四个部分展开。
一、测试环境与工具准备
测试选择 NYC3 区域，使用 Ubuntu 22.04 系统。创建 Droplet 时默认会分配一个私有 IP，可以通过控制台或 metadata 接口查看。为了保证 iperf3 能正常通信，需要在两台机器上放行 TCP 5201 端口。digitals海洋的云防火墙规则需要应用到对应的 Droplet 或标签上。如果使用系统防火墙，则用 UFW 开放端口即可。下面是服务端的基础准备命令。
sudo apt update && sudo apt install -y iperf3 sudo ufw allow 5201/tcp iperf3 -s -p 5201
客户端机器上需要使用服务端的私有 IP 发起测试。私有 IP 通常以 10.x.x.x 开头，可以在控制台的网络信息中看到。为了避免公网流量计费，必须使用私有 IP 而不是公网 IP。DigitalOcean 同数据中心内私有 IP 互通通常不需要额外配置 VPC，但需要确认两个 Droplet 在同一区域且启用私有网络。先通过 ping 命令检查私有网络延迟，同数据中心内延迟一般在 0.3ms 到 0.6ms 之间。然后执行下面的客户端测试命令。
iperf3 -c 10.116.0.5 -p 5201 -t 30 -P 4
参数中 -c 指定服务端私有 IP，-t 表示测试持续秒数，-P 表示并行流数量。单线程测试可以反映单 TCP 连接的最大吞吐能力，多线程测试则可以观察网卡队列和 CPU 多核的聚合效果。测试前还可以用 ethtool 查看虚拟网卡速率，一般会显示 10000baseT，但这是虚拟网卡的逻辑速率，不代表实际业务吞吐一定能达到万兆。
二、实测过程与关键数据
我们选择三种机型做对比：Basic 1 vCPU/1GB、Basic 4 vCPU/8GB、CPU-Optimized 8 vCPU/16GB。每台机器使用相同的 Ubuntu 镜像和默认内核参数。测试使用 30 秒 iperf3，分别进行单线程、4 线程、8 线程三组，每组重复三次取中间值。结果显示，1 vCPU 实例单线程约 1.4 Gbit/s，4 线程约 1.6 Gbit/s，因为 CPU 单核处理网络栈已经接近瓶颈。4 vCPU 实例单线程约 2.8 Gbit/s，4 线程约 4.1 Gbit/s。8 vCPU CPU-Optimized 实例单线程约 3.5 Gbit/s，4 线程约 6.2 Gbit/s，8 线程约 6.5 Gbit/s，增长趋势明显放缓。
| 机型 | vCPU | 单线程吞吐 | 4线程吞吐 | 8线程吞吐 |
|---|---|---|---|---|
| Basic | 1 | 1.4 Gbit/s | 1.6 Gbit/s | 1.5 Gbit/s |
| Basic | 4 | 2.8 Gbit/s | 4.1 Gbit/s | 4.0 Gbit/s |
| CPU-Optimized | 8 | 3.5 Gbit/s | 6.2 Gbit/s | 6.5 Gbit/s |
下面是一段 4 vCPU 实例在 4 线程测试时的 iperf3 输出。可以看到两个并行流分别贡献约 2 Gbit/s，总和约 4.12 Gbit/s，这与表格中的结果吻合。输出中 sender 表示发送方向吞吐，如果做双向测试，还需要查看 receiver 方向的数据。
[ ID] Interval Transfer Bitrate [ 5] 0.00-30.00 sec 7.20 GBytes 2.06 Gbits/sec sender [ 7] 0.00-30.00 sec 7.18 GBytes 2.06 Gbits/sec sender [SUM] 0.00-30.00 sec 14.4 GBytes 4.12 Gbits/sec sender
解读结果表明，内网吞吐量并非固定值，它大约跟 vCPU 数量正相关，但并不是线性增长。当线程数超过 vCPU 数量时，多个 iperf3 线程会竞争 CPU 时间片，反而可能导致速率波动甚至下降。因此测试时应优先让并行流数量接近或略低于 vCPU 数，这样才能得到比较稳定的结果。对于更高规格的 Droplet，可以尝试 8 条或更多并行流，观察吞吐是否继续提升。
三、影响带宽与延迟的关键因素
实例规格和网络队列是首要影响因素。DigitalOcean 的虚拟网卡默认启用多队列，队列数量通常与 vCPU 数相关。可以用 ethtool -l 查看 Combined 队列数量。队列越多，接收和发送中断可以分散到多个 CPU 核心，从而提升多流吞吐。对于高并发小包场景，还需要关注 CPU 中断处理能力，单纯增加线程并不能突破单核中断瓶颈。如果业务需要处理大量并发连接，选择 vCPU 更多的机型通常能获得更好的网络并行处理能力。
ethtool -l eth0
TCP 参数也会显著影响内网吞吐。默认 Linux 内核会根据可用内存自动调整 TCP 缓冲区，但在高带宽低延迟的私有网络中，默认值有时偏保守。可以通过 sysctl 调整 rmem_max 和 wmem_max，并用 iperf3 -w 指定窗口大小测试。需要根据实际 RTT 和带宽乘积来设置，比如此测试中 RTT 约 0.4ms，要达到 10 Gbit/s，带宽时延乘积约为 500 KB，默认值通常满足。但如果发生丢包或重传，窗口会被快速缩小，影响恢复速度，这时增大缓冲区会更有帮助。
sudo sysctl -w net.core.rmem_max=16777216 sudo sysctl -w net.core.wmem_max=16777216 iperf3 -c 10.116.0.5 -p 5201 -t 30 -P 4 -w 1M
私有网络与公网回环的差异也值得关注。即使两台机器在同一数据中心，如果使用公网 IP 互访，流量会经过公网网关，可能受到出站配额限制，延迟也会上升到 1ms 以上。而私有 IP 直接在内部路由，延迟更低且不占用公网配额。DigitalOcean 的私有网络是区域级别的，同一区域不同数据中心之间可能略有差异，但带宽测试仍建议在同一数据中心进行。还需要注意云防火墙默认可能丢弃私有网络流量，必须显式放行相关端口。
四、优化建议与适用场景
根据实测数据做容量规划比直接参考官方标称值更可靠。如果用于 MySQL 主从复制、Redis 主从同步、Elasticsearch 数据迁移，建议先在两台目标规格的 Droplet 之间用 iperf3 测试，而不是盲目相信规格表上的带宽数字。对于 1 vCPU 的小实例，即使内网带宽峰值只有 1.5 Gbit/s，也足以支撑大部分数据库同步需求，但延迟敏感型应用需要监控重传率和 CPU 使用率，避免网络处理挤占业务计算资源。
系统层面可以启用 BBR 拥塞控制算法，它在有一定丢包的场景下能更快恢复发送速率。命令如下。对磁盘型服务，还需确保磁盘 IO 不成为瓶颈。测试纯网络吞吐时，可以使用内存盘或 tmpfs 作为 iperf3 数据路径，这样可以排除磁盘读写干扰，得到更接近虚拟网卡上限的数据。
sudo modprobe tcp_bbr sudo sysctl -w net.ipv4.tcp_congestion_control=bbr sysctl net.ipv4.tcp_congestion_control
安全与隔离同样不能忽视。同数据中心内部通信虽然速度快，但如果多个业务共享私有网络，建议用 VPC 或云防火墙规则做最小化访问控制。DigitalOcean 支持 Cloud Firewall，可以为私有网络流量单独设置允许来源 IP 和端口。测试结束后记得删除临时放行规则，避免把 iperf3 服务暴露在内部网络中成为安全隐患。对于生产环境，可以使用更安全的临时访问机制，而不是长期开放测试端口。
DigitalOcean同数据中心带宽带宽评测修改时间：2026-08-24 09:22:12