在分布式网页爬取系统中，网络层的设计往往决定了整个系统的吞吐上限。与传统的计算密集型或存储密集型系统不同，爬虫系统的性能瓶颈会随着互联网基础设施的演进而发生迁移 —— 十年前的瓶颈可能已经不是今天的瓶颈，而新的瓶颈往往出现在意想不到的环节。本文以实际完成十亿级网页爬取的工程系统为案例，深入剖析网络架构层面的设计决策与优化策略。
网络基础设施的现实约束
现代云服务提供的网络带宽已经远超大多数开发者的直觉预期。以 AWS 的 i7i 系列实例为例，配置 16 vCPUs、128GB 内存的 i7i.4xlarge 实例提供 10Gbps 的网络带宽上限。在实际爬取任务中，单节点的稳态网络使用量仅为 1 GB/s 左右，即约 8Gbps，这意味着网络带宽利用率仅为 32%。这一数据揭示了一个重要事实：在当前的硬件条件下，网络带宽并非大规模爬虫的首要瓶颈。
这一结论与 2012 年的情况形成了鲜明对比。当时的爬虫系统设计普遍将网络带宽视为核心约束，因为数据中心的网络接入能力有限，而单个请求的页面大小也相对较小。如今，随着 AI 产业对数据中心网络基础设施的大规模投资，带宽已经变得相对充裕。AWS 推出的 P6e-GB200 实例甚至提供高达 28.8 Tbps 的网络带宽，这在十年前是不可想象的。然而，带宽的充裕并不意味着可以忽视网络层的优化 —— 相反，正是因为带宽不再是硬性约束，网络层的其他问题才更加值得关注。
SSL 握手：被低估的 CPU 杀手
在本次爬取任务中，最出乎意料的发现是 SSL 握手计算占据了约 25% 的 CPU 时间。这一数据基于对 fetcher 进程的性能分析，结果显示 SSL 握手成为所有函数调用中开销最大的项。考虑到系统并未接近网络带宽上限，SSL 计算实际上成为了获取流程的 CPU 瓶颈，间接限制了网络吞吐能力的发挥。
这一现象的根因在于现代互联网的 HTTPS 普及率。从 Let's Encrypt 的统计数据来看，Firefox 中加载 SSL 的比例从 2014 年的 30% 上升至 2025 年的超过 80%。对于爬虫系统而言，这意味着几乎每个请求都需要完成完整的 SSL 握手过程，包括证书验证、密钥交换等计算密集型操作。在高并发场景下，数万个并发 SSL 连接的握手开销会迅速耗尽 CPU 资源。
针对这一问题，工程实践中有几种应对策略。连接复用是首要手段：保持与目标域的长连接，避免为每个请求重复建立 SSL 会话。现代 HTTP 客户端库通常默认启用连接池，但需要根据实际负载调优连接池大小。其次，硬件加速是另一个方向，部分云实例提供 SSL 加速引擎，可以将加密计算卸载到专用硬件。最后，会话票据缓存可以减少完整握手的次数，通过复用之前协商的会话密钥来加速后续连接。
连接池管理的工程实践
在异步架构中，连接池的设计直接影响系统的并发能力和资源利用效率。本系统采用 asyncio 实现高并发 fetcher，单个 fetcher 进程可以支持 6000 至 7000 个并发 worker。值得注意的是，这一并发量远未达到网络带宽的上限 —— 瓶颈转移到 CPU 后，单纯增加并发 worker 数量已经无法提升吞吐。
连接池的核心参数包括最大空闲连接数、单域名最大连接数和连接超时阈值。对于爬虫场景，建议将单域名最大连接数设置为 10 至 20，具体取决于目标站点的 politeness 策略和服务器的承受能力。连接超时通常设置为 10 至 30 秒，过短会增加失败率，过长则会拖慢整体进度。
在实际运行中，连接池的监控同样重要。需要关注的指标包括：活跃连接数与空闲连接数的比例、连接获取等待时间、连接错误类型分布等。当活跃连接数持续接近配置上限时，通常意味着需要扩容或优化并发策略。
DNS 解析的演进与现状
传统观点认为 DNS 解析是爬虫系统的重要瓶颈，这一认知源自早期的网络基础设施条件。然而，在本次实验中，DNS 解析并未成为明显瓶颈。分析认为，这一变化主要归因于两个因素：首先，系统限定在 top 100 万域名的种子列表上，DNS 缓存命中率较高；其次，现代 DNS 解析服务已经高度优化，递归解析的延迟通常在毫秒级。
尽管如此，对于更大规模的爬取任务或不同的目标场景，DNS 优化仍然是值得关注的领域。DNS 预解析技术可以将即将访问的域名的解析结果提前缓存到本地，减少请求时的等待时间。实现方式包括定期批量解析待爬队列中的域名、使用 nscd 等系统级 DNS 缓存服务，或在应用层维护独立的 DNS 缓存。
对于需要更高性能的场景，可以考虑使用 DNS 负载均衡器或 Anycast 地址，将 DNS 解析的负载分散到多个节点。同时，保持一份本地域名 - IP 映射的缓存，并设置合理的 TTL（通常 5 至 15 分钟），可以在保证新鲜度的同时减少解析次数。
带宽利用率的监控与调优
虽然理论带宽充足，但实际运行中的带宽利用率收到多种因素制约。关键监控指标包括：入站流量、出站流量、网络延迟分布和重传率。在稳态运行中，单节点带宽利用率应维持在 50% 至 70% 为宜 —— 过低说明存在其他瓶颈，过高则可能触发服务质量降级。
带宽利用率低下的常见原因包括：请求响应体过小导致的协议开销占比上升、频繁的连接建立与关闭、以及上游服务器的响应延迟。针对这些问题，请求批量化是一种有效的优化思路：在不影响 politeness 的前提下，将多个相关请求合并处理，减少协议开销的占比。
另一个值得关注的指标是TCP 拥塞窗口的演化。在长距离网络传输中，拥塞窗口的慢启动过程会显著影响前几个请求的传输效率。通过在连接建立后立即发送探测包来快速扩大拥塞窗口，可以缩短达到理想吞吐量的时间。部分高性能网络库已经内置了这一优化。
流量调度与域名分片策略
本系统采用域名前缀的分片策略，将 top 100 万域名均匀分配到 12 个节点上。每个节点独立运行完整的爬取流水线，包括 fetcher、parser 和 Redis 存储，没有跨节点通信。这一设计的选择基于两个考量：首先是降低分布式系统的复杂度，避免引入协调组件带来的额外延迟；其次是契合实际的流量特征 —— 不同域名的热度差异巨大，热域名可能产生数亿级别的待爬队列。
流量调度的核心挑战在于热点域名的处理。在实验过程中，部分热门域名（如 yahoo.com、wikipedia.org）的 frontier 膨胀至数十 GB，包含了数亿个待爬 URL。这种极端的热点会导致节点内存压力激增，甚至引发服务不可力。解决方案包括：对热点域名实施额外的访问限速、将热点域名单独隔离到专用节点、以及设置 frontier 硬上限并在超限时触发优先级调度。
对于更大规模的系统，可以考虑引入流量调度器来实现更细粒度的控制。调度器可以根据实时的节点负载、带宽利用率和任务优先级，动态调整各节点的爬取速率。常见的调度策略包括：加权轮询、最小连接数优先、以及基于预测的动态调度。
工程参数参考清单
以下汇总了本文涉及的关键工程参数，可作为类似系统的设计参考：
- 实例网络带宽：10Gbps（i7i.4xlarge），目标利用率 50% 至 70%
- 单节点并发 worker 数：6000 至 7000（asyncio 架构）
- 单域名最大连接数：10 至 20
- 连接超时时间：10 至 30 秒
- DNS 缓存 TTL：5 至 15 分钟
- 请求间隔：70 秒（相同域名）
- SSL 会话复用：启用
- 单节点 fetcher 进程数：9
- 单节点 parser 进程数：6
- 解析队列容量：根据内存情况动态调整
总结
大规模网页爬取系统的网络架构设计，本质上是在带宽、CPU、延迟和成本之间寻找平衡点。传统认知中的瓶颈（DNS 解析、网络带宽）在现代云基础设施条件下已经不再是最紧迫的约束，而 SSL 握手计算、连接池效率、流量调度策略等问题则更加值得关注。通过合理的架构设计和参数调优，可以在有限的预算内实现每秒近千页的爬取吞吐，为十亿级网页采集提供可行的工程方案。
资料来源：本文技术细节基于 Andrew Chan 的《Crawling a billion web pages in just over 24 hours》实践报告，该文记录了在 25.5 小时内完成 10.05 亿网页爬取的完整工程过程，成本约 462 美元。