带宽够大，下载就一定快吗？不少人换过更大带宽的套餐，跨国传输还是老样子。问题往往不在带宽本身，而在一笔常被忽略的账：带宽乘以延迟，也就是常说的带宽延迟积。
问：一条连接最多能跑多快
TCP 单条连接的吞吐上限，大致等于”窗口大小 ÷ 往返时间”。窗口是发送方在收到确认之前，最多能发出去的数据量；往返时间是数据从发出到收到确认的时间。两者相除，就是这条连接的实际吞吐天花板——带宽数字再高，也突破不了这个上限。
问：为什么链路一长就慢
因为延迟进了分母。同样的窗口，直连往返 30 毫秒，走一条往返 200 毫秒的长链路，单连接吞吐上限直接掉到六分之一。带宽没有变，延迟变大了，能跑起来的速度就下来了。跨境传输、远程文件同步这类场景，慢常常不是带宽不够，而是这条除法算式在作怪。
问：怎么确认是不是它卡住的
做一次估算：用带宽乘以实际延迟，得到维持满速所需的窗口大小，再看当前连接能否达到这个窗口。如果估算值远超连接的实际能力，多半就是带宽延迟积在作怪。此时加带宽没有用，问题出在窗口与延迟的配合上，而不是出在带宽数字上。
多连接为什么有效？因为每条连接都独立计算窗口，十条连接就有十个窗口同时工作，相当于把吞吐天花板抬高了十倍。这也是下载工具默认开多个线程的原因——它们是在用连接数，对冲单连接被窗口卡住的问题。但连接数不是越多越好，每多一条连接都伴随握手与维护开销，数量要按实际需要来，不是无限叠加就快。
窗口参数也不是一成不变的。现代系统普遍支持窗口缩放，把窗口上限从早期的小数值放大到很大，专门应对高带宽长延迟链路。但遇到老旧系统或中间设备时，缩放协商失败会退回小窗口，长链路的吞吐立刻受限。所以排查这类问题时，除了算带宽延迟积，也值得看一眼窗口缩放是否真的生效，两件事常常同时出状况。
常见做法：先加带宽，以为速度会跟着涨。结果：带宽没到顶，延迟没变，单连接还是跑不满，钱花在了瓶颈之外的地方。
更稳妥的做法：先算清瓶颈在哪。是多开几条连接分担，调整窗口参数，还是换一条延迟更低的路径，对症处理才有效，盲目加带宽往往最不划算。
带宽延迟积不是冷门概念。跨国协作、云端同步、数据备份这些场景里，它都是最常见的隐形瓶颈，只是很少有人把它放进”出口够不够用”的判断里。测速工具往往开多条连接，掩盖了单连接受限的事实，所以只看测速数字会失真。
评估一条链路时，把延迟也纳入考量，算一算带宽延迟积，才知道真实业务跑起来是什么水平。对需要长时间大流量传输的代理链路来说，这条账算清楚，比盯着测速数字有用得多。
带宽决定天花板的高度，延迟决定你能不能摸到它。