甲骨文大带宽高延迟服务器优化教程
从带宽时延积开始，正确设置 128 MiB TCP 自动滑动窗口， 启用 BBR 与 fq，并通过 iperf3 和 ss 验证真实效果。
Overview
这篇教程要解决什么问题
甲骨文 Oracle Cloud 的 Ampere A1 弹性实例会根据 OCPU 数量分配网络带宽。 例如配置 4 个 OCPU 时，实例网络能力可达到 4 Gbps。 但是，实例拥有较高的带宽上限，不代表位于中国大陆的单个用户一定能够通过一条 TCP 连接跑满这部分带宽。
中国大陆访问美国西海岸服务器时，往返延迟可能达到 150 至 250 毫秒。 在这种高带宽、高延迟环境中，TCP 必须允许足够多的未确认数据同时存在于网络中， 否则粗大的网络通道仍然可能因为窗口不足而无法被充分利用。
扩大上限
把 TCP 自动收发缓冲区上限提高到 128 MiB。
保持自动调节
不强制所有连接占用 128 MiB，由 Linux 根据连接情况动态增长。
启用 BBR
使用 BBR 拥塞控制，并搭配 fq 队列调度与数据包节奏控制。
实际验证
分别测试单连接、多连接、重传、RTT、拥塞窗口和交付速率。
必须先理解的一点
128 MiB 是 Linux 允许 TCP 自动缓冲区增长到的最大值， 不是每建立一条连接就立即分配 128 MiB 内存，也不是把网站速度强制设置成某个数值。
Principle
为什么滑动窗口会限制带宽
TCP 发送数据后，需要等待接收方返回确认。发送方在等待确认期间可以保留在网络中的数据量， 受到接收窗口、拥塞窗口和本地发送缓冲区等因素限制。
判断高速链路需要多大窗口，通常使用带宽时延积，也就是 BDP：
以 4 Gbps 和 180 ms 为例
理论计算结果约为 85.83 MiB。实际配置还需要为协议开销、RTT 波动、系统缓冲计算方式和链路变化 留出余量，因此选择 128 MiB 是比较合理的上限。
| 有效窗口 | 180 ms 下理论吞吐量 | 适用判断 |
|---|---|---|
| 16 MiB | 约 0.75 Gbps | 不足以覆盖 4 Gbps |
| 32 MiB | 约 1.49 Gbps | 适合 1 Gbps 级链路 |
| 64 MiB | 约 2.98 Gbps | 仍不足以覆盖 4 Gbps |
| 128 MiB | 约 5.97 Gbps | 可以覆盖 4 Gbps 并保留余量 |
理论窗口足够不等于实际一定跑满
实际速度还会受到客户端宽带、客户端接收窗口、跨境丢包、线路拥塞、 CPU、磁盘、TLS 加密、应用限速和 Oracle 公网出口状态影响。
Calculator
带宽时延积与窗口计算器
输入服务器带宽和用户到服务器的往返延迟，计算器会给出理论 BDP、 建议预留值以及适合写入 Linux 配置的窗口上限。
当前参数适合设置为 128 MiB 自动缓冲区上限。
Preparation
操作前的适用条件与备份
适合
- Ubuntu 22.04、Ubuntu 24.04 等现代 Linux 系统
- Oracle Cloud Ampere A1 或其他大带宽云服务器
- 跨地区、跨国访问，RTT 较高
- 大文件下载、网盘、视频、反向代理或 VPN 服务
- 服务器拥有充足内存
不代表
- 不会直接提高 Oracle 分配给实例的带宽
- 不会解决所有跨境线路丢包
- 不会突破客户端自身宽带上限
- 不会让 WordPress PHP 执行速度自动变快
- 不会保证中国大陆单连接稳定达到 4 Gbps
备份当前运行参数
sysctl net.ipv4.tcp_window_scaling
sysctl net.ipv4.tcp_moderate_rcvbuf
sysctl net.ipv4.tcp_rmem
sysctl net.ipv4.tcp_wmem
sysctl net.core.rmem_max
sysctl net.core.wmem_max
sysctl net.core.default_qdisc
sysctl net.ipv4.tcp_congestion_control还可以把结果保存到文件：
sysctl -a > /root/sysctl-before-network-tuning.txt备份现有配置文件
mkdir -p /root/sysctl-backup
cp -a /etc/sysctl.conf /root/sysctl-backup/sysctl.conf
cp -a /etc/sysctl.d /root/sysctl-backup/sysctl.d检查重复参数
同一个参数可能同时出现在多个文件中。后加载的配置会覆盖先加载的配置， 所以不能只看文件内容，必须以最终的 sysctl 查询结果为准。
grep -R "tcp_rmem\|tcp_wmem\|rmem_max\|wmem_max\|tcp_congestion_control\|default_qdisc" /etc/sysctl.conf /etc/sysctl.dInspection
查看服务器当前 TCP 配置
sysctl net.ipv4.tcp_window_scaling
sysctl net.ipv4.tcp_moderate_rcvbuf
sysctl net.ipv4.tcp_rmem
sysctl net.ipv4.tcp_wmem
sysctl net.core.rmem_max
sysctl net.core.wmem_max
sysctl net.ipv4.tcp_available_congestion_control
sysctl net.ipv4.tcp_congestion_control
sysctl net.core.default_qdisc优化前可能看到类似结果：
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_rmem = 4096 87380 67108864
net.ipv4.tcp_wmem = 4096 65536 67108864
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864上面的最后一个数值为 67,108,864 字节，也就是 64 MiB。 在 RTT 为 180 ms 时，64 MiB 对应的简化理论上限约为 2.98 Gbps， 因此无法从窗口容量上完整覆盖 4 Gbps 单连接。
TCP Buffer
设置 128 MiB TCP 自动缓冲上限
可以使用 Nano 编辑配置，也可以通过 Heredoc 一次写入。 为了减少终端编辑和复制错误，下面使用一次性写入方式。
cat > /etc/sysctl.d/99-tcp-128mb.conf <<'EOF'
# 开启 TCP Window Scaling
net.ipv4.tcp_window_scaling = 1
# 开启 TCP 自动调整接收窗口
net.ipv4.tcp_moderate_rcvbuf = 1
# Socket 最大缓冲区 128 MiB
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
# TCP 接收缓冲区
# min default max
net.ipv4.tcp_rmem = 4096 131072 134217728
# TCP 发送缓冲区
# min default max
net.ipv4.tcp_wmem = 4096 16384 134217728
EOF三个数字分别代表什么
| 位置 | 含义 | 本文数值 |
|---|---|---|
| 第一个数值 | 最小缓冲值 | 4096 字节 |
| 第二个数值 | 初始或默认缓冲值 | 接收 131072，发送 16384 |
| 第三个数值 | 自动调节允许达到的最大值 | 134217728 字节，即 128 MiB |
为什么保留发送初始值 16384
16384 只是发送缓冲区的初始值，不是最大窗口，也不会把连接限制在 16 KiB。 Linux 可以根据连接情况继续自动扩大，最高增长到本文设置的 128 MiB。
服务器性能强，不代表必须把初始缓冲值设置得很大。对于包含大量短连接的网站， 较小的初始值可以减少不必要的初始内存占用；真正决定高带宽连接容量的是第三个最大值。
Congestion Control
开启 BBR 与 fq
调大 TCP 缓冲区只解决允许更多数据同时在途的问题。 真正发送多少数据，还受到拥塞窗口影响。高延迟和存在一定丢包的跨境链路， 可以测试 BBR 拥塞控制算法。
确认系统支持 BBR
sysctl net.ipv4.tcp_available_congestion_control如果结果中包含 bbr，例如：
net.ipv4.tcp_available_congestion_control = reno cubic bbr即可写入配置：
cat > /etc/sysctl.d/99-bbr.conf <<'EOF'
# 使用 fq 队列调度
net.core.default_qdisc = fq
# 使用 BBR TCP 拥塞控制
net.ipv4.tcp_congestion_control = bbr
EOF现代 Linux 内核中的 BBR 不再绝对依赖 fq 才能运行， 但 fq 能够提供更合适的数据包节奏控制，在高负载服务器上通常是合理的搭配。
BBR 不是万能加速开关
BBR 可能改善部分高延迟链路的吞吐量，但不同运营商、不同地区和不同丢包模式下， BBR 与 CUBIC 的表现可能不同。应当通过相同时间、相同客户端、相同测试文件进行对比。
Advanced
可选的高延迟与队列参数
以下参数不是扩大滑动窗口的必要条件，但可以作为高延迟、多站点、反向代理或 Docker 服务器的辅助配置。不要把它们理解成固定适用于所有服务器的万能参数。
cat > /etc/sysctl.d/98-tcp-buffer.conf <<'EOF'
# Keep congestion window after idle periods
net.ipv4.tcp_slow_start_after_idle = 0
# Enable MTU probing when a PMTU black hole is suspected
net.ipv4.tcp_mtu_probing = 1
# Connection and packet queues
net.core.somaxconn = 8192
net.ipv4.tcp_max_syn_backlog = 8192
net.core.netdev_max_backlog = 16384
# Ephemeral port range
net.ipv4.ip_local_port_range = 10000 65535
EOFtcp_slow_start_after_idle = 0
空闲连接恢复传输时尽量保留之前的拥塞窗口，适合频繁暂停后继续传输的场景。 但在链路状况已经变化时，也可能产生更明显的瞬时突发。
tcp_mtu_probing = 1
当系统怀疑存在路径 MTU 黑洞时启用 MTU 探测， 可降低部分网络中大包无法通过但 ICMP 提示又被拦截的问题。
somaxconn = 8192
提高已完成连接等待应用接收时的队列上限，主要影响突发并发连接， 不会直接提高单连接传输速度。
tcp_max_syn_backlog = 8192
提高尚未完成三次握手的连接队列上限，主要用于处理连接突发。
netdev_max_backlog = 16384
当数据包到达速度暂时高于内核处理速度时，允许网络设备排队更多数据包。
ip_local_port_range = 10000 65535
扩大本机主动发起连接时可使用的临时端口范围。 如果服务器在高端口运行大量服务，应检查端口规划，必要时保留系统默认值。
这些队列参数不能代替应用优化
如果 NGINX、PHP-FPM、数据库、Docker、磁盘或上游程序本身已经达到瓶颈， 继续扩大内核队列只会延迟错误出现，并不会创造额外处理能力。
Apply
应用配置并验证最终值
加载全部 sysctl 配置
sysctl --system成功时会看到系统依次加载多个配置文件，其中应当包含：
* Applying /etc/sysctl.d/98-tcp-buffer.conf ...
* Applying /etc/sysctl.d/99-bbr.conf ...
* Applying /etc/sysctl.d/99-tcp-128mb.conf ...一次性检查最终状态
sysctl net.ipv4.tcp_window_scaling net.ipv4.tcp_moderate_rcvbuf net.core.rmem_max net.core.wmem_max net.ipv4.tcp_rmem net.ipv4.tcp_wmem net.ipv4.tcp_slow_start_after_idle net.ipv4.tcp_mtu_probing net.core.somaxconn net.ipv4.tcp_max_syn_backlog net.core.netdev_max_backlog net.ipv4.ip_local_port_range net.core.default_qdisc net.ipv4.tcp_congestion_control正确结果示例
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
net.ipv4.tcp_rmem = 4096 131072 134217728
net.ipv4.tcp_wmem = 4096 16384 134217728
net.ipv4.tcp_slow_start_after_idle = 0
net.ipv4.tcp_mtu_probing = 1
net.core.somaxconn = 8192
net.ipv4.tcp_max_syn_backlog = 8192
net.core.netdev_max_backlog = 16384
net.ipv4.ip_local_port_range = 10000 65535
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr确认 BBR 模块
lsmod | grep tcp_bbr模块方式加载时可能看到：
tcp_bbr 20480 222通常不需要重启服务器
sysctl 参数在加载后立即生效。为了完整测试窗口协商和新拥塞控制， 应当重新建立 TCP 连接，例如重新开始下载或重新运行 iperf3。
Benchmark
使用 iperf3 对比单连接与多连接
网页测速工具往往使用多个并发连接，容易掩盖单条 TCP 流的问题。 iperf3 可以分别测试单连接和多连接，更适合判断窗口与拥塞控制是否成为瓶颈。
在 Oracle 服务器安装 iperf3
apt update
apt install iperf3 -y
iperf3 -s需要在 Oracle 安全列表、防火墙或安全组中临时允许 TCP 5201， 测试完成后应关闭公网入口。
从客户端测试上传到服务器
iperf3 -c 服务器IP -P 1 -t 30模拟用户从网站下载数据
iperf3 -c 服务器IP -R -P 1 -t 30测试八条并发连接
iperf3 -c 服务器IP -R -P 8 -t 30总带宽可能充足，但单流受到 RTT、丢包、拥塞窗口、 接收窗口或单连接限速影响。
更可能是跨境线路、客户端宽带、Oracle 出口、CPU、 防火墙、应用或中转节点限制。
当前 TCP 参数基本充足，没有继续放大缓冲上限的必要。
Observation
使用 ss 观察真实网站连接
在用户下载大文件或进行 iperf3 测试时，可以在服务器上观察 TCP 的实时状态。
ss -tinss -tin '( sport = :443 )'| 字段 | 含义 | 判断方向 |
|---|---|---|
rtt |
往返延迟与波动 | 延迟越高，需要的在途数据越多 |
cwnd |
拥塞窗口 | 过小可能限制发送速度 |
wscale |
窗口扩大协商 | 确认窗口缩放是否正常 |
bytes_retrans |
重传字节数 | 持续快速增长通常表示丢包或拥塞 |
delivery_rate |
估算交付速率 | 观察当前连接真实传输能力 |
rwnd_limited |
受对方接收窗口限制 | 持续增长表示客户端窗口可能不足 |
sndbuf_limited |
受本地发送缓冲限制 | 持续增长才需要重点检查发送缓冲 |
不要只看最大缓冲值
即使最大缓冲区已经是 128 MiB，实际连接也可能因为拥塞窗口、客户端接收窗口、 丢包或应用发送速度不足而无法增长到所需规模。
Web Server
NGINX 静态文件传输配置
TCP 内核参数只负责底层传输。对于 ZIP、图片、视频、备份文件和网盘下载， NGINX 还应避免不必要的用户态复制，并合理组织数据包发送。
可检查 NGINX 的 http 配置区域是否包含：
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;修改后必须先检查语法：
nginx -t
systemctl reload nginx不要重复写入未知配置位置
宝塔面板可能已经在主配置中启用这些选项。 应先使用 nginx -T 查看完整生效配置，避免在错误层级或多个文件中重复添加。
nginx -T | grep -E "sendfile|tcp_nopush|tcp_nodelay|keepalive_timeout"这些选项主要改善静态文件发送方式，不会直接提升 WordPress 中 PHP、MySQL 或插件生成动态页面的计算速度。
Proxy
使用 Cloudflare 时如何理解这些参数
域名开启 Cloudflare 橙色云后，访客通常不会直接与 Oracle 源站建立同一条 TCP 连接。 服务器上的 TCP 参数主要影响 Cloudflare 到源站这一段，以及绕过代理的直连域名。
走 Cloudflare 代理
用户到边缘节点的连接由 Cloudflare 管理。 源站窗口优化仍有价值，但不能直接控制用户到 Cloudflare 的 TCP 或 QUIC 参数。
直连下载域名
用户直接连接 Oracle，此时服务器发送窗口、拥塞控制、丢包和 RTT 会直接影响单条下载连接。
Rollback
出现问题时如何回滚
删除本文新增的配置文件，然后重新加载系统参数即可。
rm -f /etc/sysctl.d/98-tcp-buffer.conf
rm -f /etc/sysctl.d/99-bbr.conf
rm -f /etc/sysctl.d/99-tcp-128mb.conf
sysctl --system如果之前已经备份整个目录，也可以恢复备份：
rm -rf /etc/sysctl.d
cp -a /root/sysctl-backup/sysctl.d /etc/sysctl.d
cp -a /root/sysctl-backup/sysctl.conf /etc/sysctl.conf
sysctl --system恢复前先确认备份存在
不要直接删除系统配置目录。应先确认 /root/sysctl-backup 中的备份完整， 并保留当前 SSH 会话，以便在网络异常时继续修复。
FAQ
常见问题
设置 128 MiB 后，每条连接都会占用 128 MiB 吗？
不会。本文设置的是自动调节最大值。连接会从较小的初始缓冲开始， Linux 根据 RTT、吞吐量和接收情况动态调整。
128 MiB 是否一定可以跑满 4 Gbps？
只能说明窗口容量足够覆盖 4 Gbps、180 ms 的理论带宽时延积。 实际速度仍可能受到丢包、客户端、线路、拥塞窗口、CPU、磁盘和应用层限制。
为什么不直接设置 256 MiB 或 1 GiB？
4 Gbps、180 ms 的原始需求约为 85.83 MiB，128 MiB 已经有足够余量。 继续放大上限通常不会自动提高速度，却可能增加异常高并发下的内存风险。
tcp_wmem 中间的 16384 会限制速度吗？
不会。它是发送缓冲的初始或默认值，不是自动调节最大值。 最大值是第三个数字 134217728。
配置后需要重启服务器吗？
一般不需要。执行 sysctl --system 后参数立即生效。 为了准确验证，建议重新建立测试连接。
BBR 和 fq 已经显示生效，还要做什么？
不要继续盲目修改参数。下一步应使用 iperf3、ss 和真实文件下载， 对比单连接、多连接、重传率和实际交付速度。
为什么 Speedtest 很快，浏览器单文件下载却很慢？
Speedtest 往往使用多条并发连接，每条连接都有自己的拥塞窗口。 单文件下载可能只有一条或少量连接，更容易暴露高 RTT、丢包和单流性能问题。
Checklist
最终检查表
窗口上限已经足够，接下来应该优化真实瓶颈
对于 4 Gbps、180 ms RTT 的理论链路，原始带宽时延积约为 85.83 MiB。 设置 128 MiB 自动缓冲区上限后，服务器已经在窗口容量方面保留足够余量。
如果实际速度仍不理想，排查重点应转向跨境丢包、客户端接收窗口、拥塞窗口、 Oracle 公网出口、CPU、磁盘、TLS、NGINX、应用限速以及是否经过代理或中转。
官方参考资料
- Linux Kernel Documentation：IP Sysctl
- Oracle Cloud Infrastructure：Compute Shapes
- Google BBR：BBR Quick Start
- NGINX Documentation：ngx_http_core_module
暂无评论内容