在Workflow项目中实现基于IP地址的大规模SSL网页抓取方案

背景介绍

在大规模网页抓取场景中，特别是当需要每小时处理千万级站点时，传统的DNS解析流程会成为性能瓶颈。直接使用IP地址进行访问可以显著提高抓取效率，但这在SSL/TLS环境下会遇到一些技术挑战。

问题分析

当使用IP地址直接访问HTTPS网站时，主要会遇到以下两个问题：

1. SNI(Server Name Indication)问题：现代TLS协议要求客户端在握手阶段发送目标主机名，以便服务器返回正确的证书。如果直接用IP地址访问，服务器无法确定客户端想要访问哪个虚拟主机。

2. 证书验证问题：SSL证书通常是为域名颁发的，直接使用IP地址访问会导致证书验证失败。

解决方案探索

初始方案及其局限性

最初尝试的方案是：

1. 将URL中的主机名替换为IP地址
2. 通过set_header_pair("Host", "站点名")设置Host头

这种方法对于部分网站有效，但对于需要SNI的网站（如www.onpalms.com）会出现SSL错误。

使用Upstream管理的方案

Workflow项目提供了Upstream管理功能，可以这样使用：

int main()
{
    // 启用TLS SNI支持
    struct WFGlobalSettings settings = GLOBAL_SETTINGS_DEFAULT;
    settings.endpoint_params.use_tls_sni = true;
    WORKFLOW_libraray_init(&settings);

    // 创建upstream并添加服务器
    UpstreamManager::upstream_create_weighted_random("name", false);
    UpstreamManager::add_server("name", "example.com");

    // 创建任务并设置prepare回调
    auto task = WFTaskFactory::create_http_task("https://name", ...);
    task->set_prepare([](WFHttpTask *task){
        auto *t = static_cast<WFComplexClientTask<protocol::HttpRequest, protocol::HttpResponse> *>(task);
        task->get_req()->set_header_pair("Host", t->get_current_uri()->host);
    });
    ...
}

这种方案利用了Workflow的Upstream功能，但仍然需要域名解析。

自定义命名服务策略的终极方案

为了完全控制IP地址的使用并正确处理SNI，可以采用以下高级方案：

1. 自定义命名服务策略（继承自WFNSPolicy）
2. 自定义路由任务（继承自WFRouterTask）

这种方案的核心思想是：

• 完全接管Workflow的域名解析过程
• 使用业务上游提供的IP地址
• 在TLS握手阶段正确设置SNI字段

实现要点

1. 自定义WFNSPolicy：

   • 重写create_router_task方法
   • 直接返回预设的IP地址，跳过DNS查询

2. 自定义WFRouterTask：

   • 确保在TLS握手时正确设置server_name字段
   • 保持Host头与证书验证的一致性

3. 性能优化：

   • 实现IP地址的缓存和复用
   • 处理IP地址失效时的回退机制

总结

在Workflow项目中实现基于IP地址的大规模SSL网页抓取，关键在于正确处理TLS/SSL握手过程中的SNI字段和证书验证。通过自定义命名服务策略和路由任务，可以完全控制IP地址的使用，同时保证与各种HTTPS网站的兼容性。这种方案特别适合需要极高抓取效率的大规模网页抓取场景。