一次握手要花多久，代理IP访问的延迟里它占多少

很多人测代理IP延迟只看数据往返的时间，却忽略了每次连接建立时握手也要花时间。握手的时间不是零，在频繁建连的场景里，它甚至会占到总耗时的大头。

先把概念理清：握手耗时约等于一个半的数据往返时间。为什么是一个半，看完三次握手的报文走向就明白了。

一个半往返是怎么算出来的

数据往返时间（RTT）是报文从发送方到接收方再回来的总时长。三次握手的三步报文：SYN 过去、SYN-ACK 回来，这一来一回正好一个 RTT；第三步 ACK 再过去，只要半个 RTT（不需要等回应）。

所以理想情况下，握手耗时 = 1.5 × RTT。RTT 越大，握手越慢；RTT 越小，握手越快。距离远、链路差，RTT 就大，握手自然就慢。

要注意的是，握手只发生在「建立连接」那一刻。连接建立后持续使用，握手的时间成本就摊薄了；如果是用完就断、断了又连，握手的时间成本就会被反复支付。

代理IP链路为什么握手更贵

走代理IP时链路拆成两段，握手也拆成两次：本机到转发层一次，转发层到目标站一次。两段握手时间相加，总握手耗时接近 1.5 倍的整条链路 RTT，比直连的 1.5 倍单段明显更长。

还有一层隐藏成本：如果代理IP出口经常切换，每次切换后与目标站的连接往往要重建，握手跟着重新来一遍。出口换得越勤，握手费用付得越多次。

所以长连接业务用静态出口更划算——连接保持得久，握手只付一次；短连接高并发业务则要掂量握手开销，能复用连接就别反复新建。

有一个常见误区：把延迟完全归咎于线路慢。实际上如果应用在频繁重连，一半以上的「慢」可能是反复握手造成的，优化方向是减少建连次数，而不是换线路。

判断是不是握手拖慢了体验，有个简单的对照：如果页面第一次加载明显比后续刷新慢，往往就是首轮握手加首包延迟的代价；如果每次都一样慢，才更可能是线路本身的瓶颈。

另一个容易被忽略的点：首包延迟。网页访问时，浏览器要先建连接再发请求，握手完成前的这段时间用户什么都看不到。连接池与长连接，省的就是握手这一步的时间：代理IP链路里两段握手的花费更高，能复用就别重建。

两个容易算错的账

第一笔账是口径：连接建立时间通常已含握手，普通延迟测试不含，对比前先对齐。第二笔账是重连：出口频繁切换会让握手反复发生，长连接业务省下的正是这笔反复花费，这也是静态出口在长任务里更受欢迎的原因。

记住：测代理IP延迟时，分开看「连接建立耗时」和「数据传输耗时」两笔账，很多慢的真相就浮出来了。

还有一个细节值得记住：测量工具显示的连接建立时间通常已经把握手算进去了，而普通延迟测试显示的是数据传输往返，两者口径不同。对比数据时先对齐口径，别拿两个数字硬比。