libwebsockets中HTTP/GET请求超时问题分析与解决方案

问题背景

在使用libwebsockets构建HTTP/HTTPS服务器时，开发者可能会遇到请求超时的问题。本文深入分析libwebsockets中的超时机制，并提供有效的解决方案。

超时机制解析

libwebsockets内置了一套完善的超时管理系统，主要分为两类：

1. 连接级超时：通过wsi(WebSocket Interface)结构体管理，影响整个连接的生命周期
2. 用户级超时：通过SUL(Scheduled Uevent List)系统实现，用于自定义业务逻辑超时

默认情况下，libwebsockets会为每个连接设置15秒的超时时间。当服务器在15秒内没有完成请求处理时，连接会被强制关闭。

解决方案对比

方法一：完全禁用超时

lws_set_timeout(wsi, NO_PENDING_TIMEOUT, 0);

优点：

• 简单直接
• 适用于需要长时间处理的请求

缺点：

• 失去超时保护机制
• 可能导致连接堆积，影响服务器性能

方法二：延长超时时间

lws_set_timeout(wsi, PENDING_TIMEOUT_CLIENT_CONN_IDLE, requestTimeout);

优点：

• 保留超时保护机制
• 可根据业务需求灵活调整

缺点：

• 需要合理设置超时时间

HTTPS特殊注意事项

当从HTTP切换到HTTPS时，开发者可能会发现超时时间缩短为5秒。这是因为HTTPS连接有额外的握手和加密处理阶段，libwebsockets为此设置了更严格的初始超时。

解决方案：

1. 在SSL/TLS握手完成后重新设置超时
2. 在请求处理开始时调整超时设置

最佳实践建议

1. 合理设置超时：根据业务需求设置适当的超时时间，既不能太短导致正常请求被中断，也不能太长影响服务器资源回收

2. 渐进式超时：对于长时间运行的任务，可以采用"心跳"机制，定期重置超时时间

3. 异常处理：实现自定义的SUL回调来监控长时间运行的任务，在超时前检查任务状态

4. 资源管理：对于文件传输等场景，可以在每次数据发送后延长超时时间

实现示例

// 自定义SUL回调示例
static void
custom_timeout_cb(lws_sorted_usec_list_t *sul)
{
    struct my_conn_data *data = lws_container_of(sul, struct my_conn_data, sul);
    
    if (task_is_still_running(data->task)) {
        // 任务仍在运行，重置超时
        lws_set_timeout(data->wsi, PENDING_TIMEOUT_CLIENT_CONN_IDLE, 30);
        __lws_sul_insert(&data->context->pt_sul_owner, &data->sul,
                         custom_timeout_cb, 5 * LWS_US_PER_SEC);
    } else {
        // 任务已完成或异常，关闭连接
        lws_set_timeout(data->wsi, NO_PENDING_TIMEOUT, 0);
    }
}

通过理解libwebsockets的超时机制并合理配置，开发者可以构建出既稳定又高效的网络服务，满足各种业务场景的需求。