BBR、TCP Fast Open、TLS 1.3：服务器上的三个开关，对抓取到底有没有用

先把预期摆正：这三个开关优化的是连接建立和数据传输的效率，改善的是 TTFB 和抓取效率，不直接影响排名。指望开了 BBR 排名就涨，多半会失望；但如果服务器跨网延迟高、丢包多，它们确实能实打实地省下时间。

图片来源：网络，版权归原作者所有，侵权请联系删除

BBR：解决的是"一丢包就怂"的问题

传统的 CUBIC 拥塞控制把丢包当成网络拥塞的信号，一丢包就大幅降速。在跨运营商、跨省这类延迟高又容易丢包的链路上，这个策略很吃亏。

BBR 换了个思路：不去猜丢包原因，而是主动探测链路的瓶颈带宽和最小往返时间，据此决定发送速率。在长肥网络上收益最明显。

开启方式（需要内核支持）：

echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
sysctl -p
sysctl net.ipv4.tcp_congestion_control

最后一条命令输出 bbr 就是生效了。注意 fq 队列规则是配套的，只改拥塞算法不改队列，效果会打折。

TCP Fast Open：只对"回头客"有用

TFO 允许在 TCP 握手的第一个包里就带上数据，省掉一个往返。参数是：

net.ipv4.tcp_fastopen = 3

3 表示同时作为客户端和服务端启用。它的局限在于只对重复连接有效——客户端必须之前拿过 cookie 才能用。

对爬虫来说这个条件未必成立。爬虫的抓取节点分散，同一个节点重复访问你站点的间隔可能很长，cookie 早就过期了。所以 TFO 的真正受益者是打开过你网站、短期内又回来的真实用户，别把它当成抓取优化项。

TLS 1.3：从两个往返减到一个

TLS 1.2 的完整握手要两个 RTT，TLS 1.3 压到一个，这是最直接的收益。它还提供了 0-RTT 模式，客户端在第一个包里就带应用数据，握手延迟归零。

0-RTT 有个前提要知道：它不具备重放保护，同一个 0-RTT 数据可能被攻击者重放。所以它只适合幂等的请求，涉及状态变更的接口不要走 0-RTT。对目录站这种以 GET 为主的站点，风险相对可控，但要不要开还得自己权衡。

配套的会话复用设置别漏：

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1h;

开了会话缓存之后，重复握手的开销能省掉一大块。如果启用 session ticket，记得定期轮换密钥，否则前向安全性会打折。

顺手提一句密码套件的选择

服务端优先 AES-GCM 没问题，现代 CPU 有硬件加速。但移动端老设备常常没有 AES 指令集，这时候 ChaCha20-Poly1305 反而更快、更省电。配置时把两者都排上、让客户端协商，比只留一个要好。

怎么验证到底有没有效果

不要靠"感觉变快了"。三个可测的口径：

• TTFB：找几个跨网、跨省的监测点，改配置前后各测一批，看中位数变化
• 服务器日志：看爬虫请求的响应时间分布，重点看 p95 而不是平均值
• 抓取量：Search Console 或百度搜索资源平台的抓取统计，看单位时间内的抓取页数有没有变化

第三项是最有意义的——传输优化最终的价值，体现在同样的抓取预算下蜘蛛能多爬几个页面。如果抓取量没变，说明瓶颈不在传输层。

什么时候别折腾这些

如果站点已经挂了 CDN，且用户和爬虫都命中边缘节点，那么源站的拥塞控制算法影响很小，CDN 与用户之间的链路你控制不了。这种情况下优先做的是调 CDN 的缓存命中率和回源策略，把精力花在内核参数上收益有限。

另外，页面本身很重——几兆的图片、几十个第三方脚本——的时候，传输层省下的几十毫秒会被完全淹没。优化永远是按瓶颈排序的。

---

这三个开关值不值得开？值得，成本很低、风险可控。但要把它们放在正确的位置：这是基础设施的整洁度，不是排名杠杆。