点了按钮，圈转了两秒才跳转；换了条出口，同样的操作几乎立刻响应。两次的带宽数字差不多，代理IP网速的体感却差得很远，差别出在往返时间上。
交互类操作看的是往返时间
等待是几个来回加出来的。
一次点击要跑几个来回
一次点击往往要跑好几个请求：先建立连接，再提交表单，服务端处理后返回结果，前端还要拉一次状态。每个来回都要等一个完整的往返，代理IP链路的往返时间偏大时，这几段相加就是用户感受到的等待，也是代理IP网速里最容易被漏掉的一项。
带宽在这里帮不上忙
提交类请求的数据量通常只有几百字节，占用不了多少带宽。代理IP网速在这一类操作上几乎完全由往返时间和抖动决定，加带宽档位不会有明显改善。为了减少提交等待去升级套餐，结果往往是一点变化都没有。
抖动的伤害比平均值大
平均 200 毫秒、抖动很大的线路，实际感受会比平均 250 毫秒、抖动很小的线路更差。这条代理IP线路的往返时间只要有一次超过阈值，整个流程就要重来。交互操作对抖动的容忍度很低，判断代理IP网速时不能只看平均数，要看最差的那几次。
怎么量出真实的往返时间
测速工具给出的多是吞吐数字，不直接反映往返时间。想看这一类指标，用连续的小请求做样本更合适：向目标站发几十次轻量请求，记下每一次的耗时，看中位数和最差值。这样得到的结果贴近日常点击的体验，代理IP链路的往返指标适合按这种方式建立基线。
- 选一个和目标站同类的地址做样本
- 连续发出几十次轻量请求，记录每次耗时
- 看中位数和最差值，不只看平均值
- 在不同时段各测一轮，比较波动范围
交互类任务还有一个容易漏的项：域名解析。首次访问某个域名时要先完成解析，结果没有缓存时这一步会多花时间，表现为点击之后先停顿再开始传输。把解析耗时和往返时间分开测，代理IP的判断会准确得多。
把往返时间和抖动单独量出来，交互类操作的代理IP网速问题就变得可判断了。带宽在这类场景里排在后面，先别急着从套餐上找原因。