同一时间段，打开一个接口地址要等两秒，下载一个文件却能跑到满速。有人把这归到对方站点头上，其实是两类请求受制于不同的环节。代理IP网速要分开判断，混在一起看只会得出互相矛盾的结论。
两类请求各自卡在哪里
小请求卡在往返与建连
接口类请求的数据量很小，几十到几百字节，传输本身几乎不花时间。它的耗时集中在建连、握手、等待响应这几步，每一步都是一个完整的往返。出口的往返时间偏大，或者抖动明显，小请求就会一片一片地慢，而且慢得很整齐。
大传输卡在持续速率
大文件的数据量以兆计，传输时间占绝对多数，往返时间那点差异可以忽略。它受制于这条代理IP连接的可用带宽和链路稳定性，丢包、限速、同池占用都会直接反映在耗时上，代理IP网速的差距也往往越到后面越明显。
判断指标不同
小请求看的是首字节时间和完整响应的耗时，大传输看的是平均速率和完成时间。用同一套指标衡量两类任务，结果自然对不上。代理IP网速的评估表里，这两栏应该分开列，各自的基线也分开建立。
优化动作也不一样
小请求的改善方向是减少往返次数和降低抖动，比如复用连接、减少重定向、把出口换到离目标更近的位置。大传输的方向是提高可用带宽和链路稳定，比如错峰、调并发上限。代理IP链路上这两组动作互不替代，用错了方向等于白做。
同一批任务里要分开统计
混合型任务的统计要分栏，把接口请求和文件传输分开记录耗时，否则两类数据平均之后什么都看不出来。代理IP网速的问题定位往往就卡在这一步：指标混着看，方向一直定不下来，改来改去都在原地。
两类问题，两套指标。
- 先按请求的数据量把任务分成两类
- 小请求记首字节时间和响应耗时
- 大传输记平均速率和完成用时
- 分别找出各自的短板再动手调整
两类任务的瓶颈不在同一处，改善手段也不通用。把指标分开记录之后，代理IP网速的问题通常会自己显出方向。
- 小请求：代理IP的往返时间、抖动、建连次数
- 大传输：可用带宽、丢包、持续速率
- 混合任务：两类指标分栏统计
- 动手前先确认要改善的是哪一类
分开看之后还有一个好处：换出口的必要性也变得清楚。小请求慢而大传输正常时，换一条带宽更大的代理IP没有帮助，该调整的是建连次数和路径。