搜索 K
Appearance
一句话结论:千兆宽带跑不满 90%,八成不是带宽不够,而是 TCP 单流 BDP 上限、CDN 就近调度失败与回程丢包这三件事叠加。把下载区域选对、并发线程拉满、回程换成低丢包专线,200G 的《使命召唤》更新可以稳定压在 8–12 分钟内完成。
BDP(带宽时延积)= 链路带宽 × 往返时延。千兆 ≈ 125MB/s,代入不同 RTT:
| RTT | BDP | 需要的接收窗口 |
|---|---|---|
| 10ms | 1.25MB | ≥ 1.25MB |
| 30ms | 3.75MB | ≥ 3.75MB |
| 80ms | 10MB | ≥ 10MB |
| 200ms | 25MB | ≥ 25MB |
Windows 的 TCP 自动调优上限通常封顶在 16MB 左右(netsh int tcp show global 可查),Linux 默认 tcp_rmem 最大值仅 6MB。这意味着在 200ms 的跨境线路上,单条 TCP 流最多只能跑出 640Mbps,而且还是在零丢包的理想情况下。
结论很直白:单流被 BDP 卡死时,只能靠多线程把总吞吐拼回来。Steam 客户端的多线程下载、aria2 的 -x16、IDM 的多连接,本质都是在"开多条流绕开单流窗口上限"。
Steam 走 HTTP 分片下载,域名解析与 Anycast 路由共同决定你落到哪个边缘节点。关键在于:出口 IP 决定 CDN 认为你在哪里。
实操判据:Steam「设置 → 下载」里的"下载区域",永远选离你物理位置最近的城市,而不是跟着账号区服走。用 curl -w 看实际命中的 IP 归属地,比任何配置都可靠。
这是最容易被"带宽数字"掩盖的一层。
丢包 1% 对 TCP 的伤害是非线性的:CUBIC 遇到丢包直接把窗口减半,实测吞吐下降 30%–50%;而 BBR 系列对丢包的容忍度要高得多。这就是为什么同样标注"1Gbps",两条线路的实际下载速度能差 3 倍。
服务端是否启用 BBRv3,直接决定你在晚高峰能不能跑出稳定的 100MB/s。这一点比"节点带宽标称 1Gbps"重要十倍。
现代协议(VLESS + Reality、Hysteria2、TUIC)在握手阶段会多 1–2 个 RTT,对持续大文件下载的总体影响在 3% 以内,可以忽略。但 Hysteria2 基于 QUIC,自带前向纠错,在丢包链路上反而优势明显。
双 ISP 入口是另一个被低估的点:同一节点同时接入电信、联通、移动入口,避免跨网结算带来的额外跳数与丢包。家庭宽带是移动的用户,如果节点只有电信入口,跨网那一段就会成为瓶颈。
| # | 指标 | 入门共享 | 主流中转 | 优质 IEPL 专线 | 高配双 ISP 专线 | 实测方法 |
|---|---|---|---|---|---|---|
| 1 | 单流吞吐(30ms RTT) | 15–30MB/s | 40–60MB/s | 80–100MB/s | 110MB/s+ | aria2c -x1 |
| 2 | 多流聚合(16 线程) | 40–60MB/s | 90–110MB/s | 120MB/s+ | 140MB/s+ | aria2c -x16 |
| 3 | 晚高峰速率保持率 | 30%–50% | 60%–75% | 85%+ | 92%+ | 20:00 后复测 |
| 4 | 平均丢包率 | 3%–10% | 1%–3% | 0.1%–0.5% | < 0.1% | mtr -rwzc 200 |
| 5 | 抖动 Jitter | 20–60ms | 8–20ms | 3–8ms | < 3ms | mtr 标准差 |
| 6 | 首字节时间 TTFB | 300ms+ | 150–250ms | 80–150ms | < 80ms | curl -w time_starttransfer |
| 7 | 单节点峰值带宽 | 100–500Mbps | 1Gbps | 1–2Gbps | 2Gbps+ | iperf3 -P16 |
| 8 | 流量计费方式 | 月付限速 | 月付大流量 | 月付 + 倍率 | 月付不限速 | 阅读 TOS |
| 9 | 并发设备数 | 1–2 | 3–5 | 5–10 | 10+ | 实测多端登录 |
| 10 | 断流恢复能力 | 需手动重连 | 秒级重连 | 无感切换 | 无感切换 | 拔网线复测 |
读表要点:第 1 项与第 2 项的