提到抓取效率，多數人先想到頁面体积和响應時間。但蜘蛛一次来訪往往要取几十上百個 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 耗时，而不是只看單頁响應；
- 改動一次只動一項配置，避免把原因和结果搅在一起。
连接和协议是抓取鏈條的下半段，平时不太顯眼，但在抓取量增長、頁面數變多的时候，它會决定蜘蛛這一趟能走多遠。