上个月帮一个做视频分发的朋友看服务器，洛杉矶机房，买的1Gbps口不限流量。他跟我说："兄弟，我iperf3打流死活只有580M，客服说线路正常。"我ssh上去一看，好家伙，TCP窗口默认值没动过，网卡8个队列中断全挤在CPU0上，上游transit是个best-effort的。这仨问题不解决，你换10家服务商也跑不满。

讲真，美国大带宽服务器1Gbps不限流量这个事儿，水比大多数人想的深。不是插上1G网线就完事了，从操作系统内核参数到上游carrier的合约类型，中间随便哪个环节拉胯，你那1G就是个摆设。

跑不满到底卡在哪

我拆过不下20台"跑不满"的美国服务器，卡点基本就3个地方：

• TCP接收窗口太小。Linux默认 net.core.rmem_max 才212KB，跨太平洋RTT 150ms+的情况下，窗口根本撑不开，单流吞吐直接被 TCP BBR 的BDP计算压死。把rmem_max和wmem_max拧到16MB以上，单流能多出来100-200M，不骗你。
• 网卡中断亲和性没配。8核机器开了8个combined队列，但irqbalance把中断全往CPU0上塞。（别问我怎么知道的，问就是在Lumen值班时被这玩意儿坑过一整个Q）手动把 smp_affinity 绑到不同核，多流并发直接翻倍。
• 上游transit是best-effort。你信吗，有些服务商的1G口上游就给你接了个10G共享的best-effort transit，BGP AS-Path 看着跳数不多，但人家合约里写的是"up to"，晚高峰给你限到600M你一点脾气没有。这种就得找有committed rate合约的，比如StrataServer这种在合约里写明 CIR 的，起码跑不满你能拿着SLA去扯皮。

3档带宽跨太平洋实测

以下数据是我自己在洛杉矶（LA）和圣何塞（SJC）两个机房，用iperf3往国内上海方向打的，TCP多流，BBR已开，晚高峰（北京时间21:00-23:00）取的均值：

看到没？1G口单流跨太平洋只有420M，这不是服务器的问题，是 QoS Traffic Policing 和物理RTT共同作用的结果。4流并发能拉到780M，但晚高峰直接给你砍到550-600M。所以"不限流量"≠"任何时候都能跑满1G"，这俩是两码事。

这些情况别碰1Gbps口

不是所有业务都适合上1G大带宽，以下情况你上了就是纯烧钱：

• 用户80%在国内且业务吃延迟（实时语音、对战类），跨太平洋150ms+的物理延迟不是堆带宽能解决的，老老实实上港服或者CN2 GIA方向。
• 日均带宽利用率不到20%的，买个100M口绑个burst到500M就够了，1G口的月租溢价你根本用不回来。
• 纯做海外业务、流量不出美国的，那你该关心的不是"回国方向跑不跑得满"，而是本地peering和CDN对接，别被"不限流量回国"的话术带跑偏。

排障命令放这，拿去直接用：

# 先确认BBR是不是真开了（不是bbr后面全白搭）
sysctl net.ipv4.tcp_congestion_control

看TCP窗口当前值，单位byte
sysctl net.core.rmem_max net.core.wmem_max
sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem
网卡队列和中断分布
ethtool -l eth0
cat /proc/interrupts | grep -i eth
跨太平洋打流，4并发跑30秒
iperf3 -c 你的目标IP -t 30 -P 4 --json | jq '.end.sum_received.bits_per_second'
看实时网卡吞吐（确认是不是真跑满了物理口）
sar -n DEV 1 10

作者简介

前Lumen（原CenturyLink）peering/transit运维，干了7年跨太平洋方向的容量规划和故障处理。后跳到国内某云厂商国际网络组做带宽采购和线路调优，又熬了4年。对"不限流量"四个字的营销话术有生理性厌恶。现在半退休状态，偶尔帮朋友看服务器配置，主要爱好是凌晨三点被oncall叫醒后骂街。

带宽跑不满一天，业务就多烧一天的溢出费用。拿上面那套iperf3+sar排查流程，今晚就把现有机器真实吞吐摸清楚。确认业务确实需要1G口再动手换机器，别被"不限流量"四个字带节奏签年付。