用代理IP访问海外站点时,总有一种”规律性顿挫”:平时很流畅,每隔一阵子卡顿一两秒,然后又恢复正常。换出口、换协议都没用,直连却又好好的。这种时好时坏的状态,很多时候不是出口带宽问题,而是 TCP 的重传超时定时器 RTO 在代理链路里被放大了——丢了一个包,发送方要等多久才重新发,这个”等多久”的节奏,在走代理时会被拉长。
RTO 是怎么工作的
TCP 发送数据后,会启动一个重传定时器:在规定时间内没收到确认,就认为数据丢了,重新发送。这个规定时间就是 RTO。它不是固定值,而是根据连接的往返时间动态计算的——链路越慢,RTO 默认越大,给足等待空间。
如果超时后重传仍没收到确认,RTO 会指数退避:第一次超时等 1 秒,第二次约 2 秒,第三次约 4 秒,以此类推。这个退避是为了防止网络拥塞时重传火上浇油,但对用户体验而言,意味着每次卡顿的时长在成倍拉长。
RTO 计算还引入了抖动项:如果网络延迟忽高忽低,计算出的 RTO 会自动加大,给波动留余量。这条规则在稳定链路上很合理,但在代理链路上,两段连接的延迟波动会叠加,算出来的 RTO 往往偏大,卡顿恢复更慢。
走代理IP时,一次请求要经过”客户端到代理”和”代理到目标”两段连接,每段各有自己的 RTO。任一段丢包,都要按自己那段的节奏重传,恢复时间近似两段之和,而不是一段。
| 场景 | 丢包后的表现 | 恢复节奏 |
|---|---|---|
| 直连 | 按本段 RTO 重传 | 单段退避,通常较快 |
| 走代理IP | 两段各自重传 | 恢复近似两段之和 |
| 代理链路抖动大 | RTO 被抖动项放大 | 退避更慢、卡顿更久 |
代理链路为什么把 RTO 放大
一是两段连接的叠加效应:任一段出问题,整条链路都要等;二是抖动项的连锁反应:代理IP出口的延迟波动会被计入两端 RTO,值越算越大;三是重传与业务超时叠加:应用层往往有自己的超时设置,链路重传还没结束,应用先报错重试,进一步加重网络负担。可以说,代理IP链路本身的转发开销并不大,真正放大问题的是它对丢包与延迟波动的”传导”。
怎么判断是不是 RTO 在作怪
卡顿有规律性、集中在丢包高发时段、卡顿时长呈递增趋势(1秒、2秒、4秒),基本就是重传退避的特征。抓包看重传时间间隔,或者看连接日志里”重传后恢复”的记录,都能确认。处理上,优先选丢包率低、抖动小的代理IP出口;业务侧给足超时余量,避免应用层比 TCP 先超时。
选出口:把丢包率和抖动作为第一筛选条件,而不是只看带宽峰值
调参数:在业务侧合理设置连接超时与重试次数,别让应用层抢在 TCP 之前超时
看趋势:把重传次数与卡顿记录成日志,持续观察哪个时段、哪条出口重传高发
回到开头的问题:为什么总是”规律性顿挫”?因为 RTO 的指数退避把每次丢包的恢复时间拉成了 1、2、4 秒的阶梯。代理IP链路本身不制造丢包,但会放大丢包的代价——把卡顿从”一次”变成”一串”。理解了 RTO 的节奏,再遇到时好时坏的代理IP连接,就知道该往丢包率和抖动上找原因,而不是盲目换出口了。