带宽从 10M 升到 100M,下载速度纹丝不动;直连时明明能跑满,一接代理就卡在半路。不少人先怀疑出口,再怀疑服务商,很少有人注意到:连接两端的窗口协商,可能才是那个看不见的天花板。
窗口是什么: 接收方会告诉发送方”我一次还能收这么多”,这个承诺写在 TCP 头部的窗口字段里。字段只有 16 位,最大只能表达 65535 字节——在几十年前的网络里绰绰有余,放到今天的带宽下,连一秒的流量都装不下。吞吐再大,也得装进这个窗口里慢慢交。
缩放因子把上限抬高: 后来的机制在连接建立时协商一个缩放因子,把窗口数值放大几十到几千倍,高带宽链路的吞吐这才跑得满。关键在于:缩放因子必须在握手阶段就谈妥,而且两端都要支持,任何一端不认,就只能退回小窗口,速度立刻被按回老水平。
代理链路最容易被卡住: 走代理时,客户端到代理、代理到目标端是两段相互独立的连接,每一段都要各自协商缩放因子。任何一段没谈成,该段的吞吐就受限于 65535 字节,整条链路的实际速度被压到某个固定值,再大的带宽也填不进去——这不是线路问题,是协商结果问题。
现象很典型: 小请求、网页浏览几乎不受影响,一传大文件速度就封顶在某个数值,而且这个值不随带宽提升而改变。因为它不是带宽决定的,是窗口决定的:换个更大的带宽,封顶值还是老样子,换成直连却立刻恢复,多半就是窗口在作怪。
怎么判断是不是窗口的问题
先看速度封顶值。如果下载速度稳定停在一个固定数值,换带宽、换出口都不变,优先怀疑窗口协商,而不是出口质量。再看直连对比:同一文件直连能跑满,走代理就封顶,结合代理两端独立协商的特性,基本可以锁定。能查看连接信息的工具会显示协商后的窗口大小与缩放因子,两端数值对得上,问题就出在别处。
另一种判断方式看变化的规律。窗口受限的慢是”匀速封顶”,数字稳定得反常;链路拥堵的慢是”忽高忽低”,波动剧烈。两种形态差异明显,先分清是哪一种,再决定往哪边查,能省掉不少冤枉路。
需要注意的是,窗口缩放异常只是”大带宽跑不满”的众多原因之一,别一上来就怪它。先排除物理线路、出口拥堵、磁盘写入、测速方式这些更常见的原因,再往窗口这类细节上查。排查顺序反了,常常白绕一大圈。
问:窗口问题能自己修吗?答:普通用户能做的有限,通常是更换代理线路,或调整代理客户端的连接参数,让两端协商出更大的窗口。真正要记住的是:评估代理链路时,别只盯带宽数字,吞吐上限往往藏在连接的协商细节里。把链路当成”两段各自协商的连接”来看,很多解释不通的慢,一下就通了。