提到抓取效率，多数人先想到页面体积和响应时间。但蜘蛛一次来访往往要取几十上百个 URL，这中间的连接建立、协议协商、TLS 握手同样占时间。同一台服务器、同样的页面，配置不同，蜘蛛单位时间内能走完的页面数可能差出一截。
长连接：一次握手，多次复用
HTTP/1.1 默认开启持久连接。第一个请求完成 TCP 握手和（HTTPS 下的）TLS 握手之后，后续请求可以复用这条连接，省掉重复的握手往返。对蜘蛛来说，这意味着在同一段时间预算里，可以覆盖更多 URL。
影响复用的常见配置：
- Keep-Alive 超时设得过短，连接还没被复用就被关掉；
- 中间层（CDN、负载均衡、反向代理）与源站的超时不一致，客户端看到的是被提前断开；
- 部分动态接口返回 Connection: close，把蜘蛛甩回重新握手。
这些设置本身不会让页面更容易被抓，但会实打实地增加每个 URL 的平均耗时。
HTTP/2 多路复用：并发不再等于多开连接
HTTP/2 在一条连接上并行传输多个请求，蜘蛛不必为每个并发请求各建一条 TCP 连接。对服务器而言连接数下降、握手开销减少；对蜘蛛而言，小页面居多的时候整体节奏更紧凑。
一个连接也意味着一个风险点
多路复用把鸡蛋放进了一个篮子。如果这条连接因为服务端限流、超时配置或中间设备被掐断，同一批请求会一起受影响，蜘蛛需要重连再排队。所以启用 HTTP/2 之后，连接层面的稳定性反而更值得盯。
不是所有流量都走同一条路
实际环境里，蜘蛛的请求可能被 CDN、WAF 或不同回源策略分流到多条链路上，部分走 HTTP/2，部分退回 HTTP/1.1。想判断协议层有没有拖后腿，需要在日志里按协议版本分组看，而不是只看请求总数。
TLS 握手：看不见但确实存在的成本
HTTPS 站点每次新建连接都要握手。会话复用和 TLS 1.3 的 0-RTT 能减少往返，但如果会话票据配置不当、或前端节点频繁变更，复用率会掉下来，握手次数随之上升。
一个经验判断：如果抓取高峰时段的 CPU 里 TLS 握手占比明显，同时平均响应时间也上去了，那瓶颈可能不在应用逻辑，而在连接建立环节。
服务器端可以看哪些指标
- 每 IP 或每 UA 段的连接数与请求数比值：比值高说明复用差；
- 协议版本分布：HTTP/2 与 HTTP/1.1 各占多少；
- TLS 握手次数与会话复用率；
- 连接平均存活时长、被主动断开的次数；
- 首字节时间与总耗时的差距，能反映握手和排队占用多少。
这些数据在 Nginx、网关或 CDN 的日志与监控里大多能拿到。它们不直接说明蜘蛛偏好什么，但能反映抓取过程是否顺畅。
哪些情况不必折腾协议
抓取量本来就不大、日志里蜘蛛请求占比很低的站点，优先把内容质量和内链结构做好，比调协议参数更划算。协议层优化的收益，通常在抓取量上来之后才明显。
一份简单的核对顺序
- 先确认蜘蛛是否存在重连频繁、连接被重置的记录；
- 再看协议版本分布与会话复用率是否异常；
- 对比调整前后的平均每 URL 耗时，而不是只看单页响应；
- 改动一次只动一项配置，避免把原因和结果搅在一起。
连接和协议是抓取链条的下半段，平时不太显眼，但在抓取量增长、页面数变多的时候，它会决定蜘蛛这一趟能走多远。