ESP32向服务器发送HTTP POST时延迟波动大的原因排查

问题背景 #

我正在测试一款ESP32设备，它每分钟通过HTTP POST向服务器发送一次数据。测试中发现延迟波动非常大，在一次20分钟的测试里，延迟值（单位：微秒）如下：

1051330 213873 1035399 207991 619864 1236647 1437973 1439257 621018 2261337
1034008 1444945 1026229 683158 1379955 688353 1373319 1444669 1845595 208093

代码实现 #

static void client_post_function()
{

    int64_t start_time = esp_timer_get_time();

    float a = 0.66;
    float b = 3.25;
    float c = 29.57;
    float d = 65.78;
    float d = 1008.44; // 编译错误：重复定义变量d

    char json_data[256];
    snprintf(json_data, sizeof(json_data), "{\"a\": %.2f, \"b\": %.2f, \"c\": %.2f, \"d\": %.2f, \"e\": %.2f}", a, b, c, d, e); // 编译错误：变量e未定义

    esp_http_client_config_t config_post = {
        .url = "http://192.168.xx.xx:8080/post",
        .method = HTTP_METHOD_POST,
        .event_handler = client_post_handler};
        
    esp_http_client_handle_t client_post = esp_http_client_init(&config_post);

    esp_http_client_set_post_field(client_post, json_data, strlen(json_data));
    esp_http_client_set_header(client_post, "Content-Type", "application/json");

    printf("Sending: %s\n", json_data);

    esp_err_t err = esp_http_client_perform(client_post);
    int64_t end_time = esp_timer_get_time();
    esp_http_client_cleanup(client_post);

    uint32_t heap_after_post = esp_get_free_heap_size();
    ESP_LOGI("HEAP", "Free heap AFTER HTTP POST : %d bytes", heap_after_post);

    if(err == ESP_OK){
        int64_t latency = end_time - start_time;
        ESP_LOGI("LATENCY", "HTTP POST latency: %lld microseconds", latency);
    } else{
        ESP_LOGE("LATENCY", "HTTP POST failed");
    }
}
    

static void periodic_post_task(void *pvParameters){ 

    while (1)
    {
        client_post_function();
        vTaskDelay(60000 / portTICK_PERIOD_MS);
    }
}

疑问 #

延迟波动如此剧烈的原因是什么？是否是ESP32处理性能、Wi-Fi稳定性或服务器响应时间为主要诱因？

延迟波动的核心诱因分析 #

从数据和代码来看，延迟波动大的核心原因是Wi-Fi连接稳定性和HTTP客户端资源重复初始化，服务器响应时间可能是次要因素，ESP32本身处理性能并非主要问题，具体拆解如下：

• Wi-Fi连接状态波动
  ESP32的Wi-Fi模块在空闲时可能自动进入低功耗模式，每次发起请求前需要重新唤醒、关联AP或重建TCP连接，这会带来几百毫秒到数秒的额外延迟。此外，环境中的Wi-Fi干扰（信道冲突、信号弱）也会导致TCP握手、数据传输的耗时大幅波动。

• HTTP客户端重复初始化的额外开销
  代码每次发送请求都重新执行esp_http_client_init和esp_http_client_cleanup，意味着每次都要重新创建TCP连接、解析URL、初始化资源。TCP三次握手本身就有不确定耗时，加上资源初始化的开销，会进一步放大延迟波动。

• 服务器响应时间的不确定性
  如果服务器负载波动大或请求处理逻辑有耗时波动，也会影响整体延迟。可以用curl等工具单独测试服务器的响应耗时，排除该因素。

• 代码潜在错误的间接影响
  代码存在两个编译错误：重复定义变量d、使用未定义变量e，这会导致程序行为异常，可能间接影响延迟统计的准确性，需优先修复。另外，当前延迟统计包含了JSON格式化、客户端初始化等本地操作，但这些操作耗时相对固定（几十微秒级别），不会导致毫秒级波动。

优化建议 #

• 复用HTTP客户端与TCP长连接：将esp_http_client_init移到任务初始化阶段，仅执行一次，后续请求复用客户端句柄，任务结束时再调用esp_http_client_cleanup。
• 优化Wi-Fi配置：关闭Wi-Fi自动低功耗模式，设置固定信道，确保ESP32与AP的信号强度充足（建议RSSI高于-70dBm）。
• 拆分延迟统计：通过client_post_handler事件回调获取TCP连接、数据发送、服务器响应等细粒度时间节点，精准定位瓶颈。
• 修复代码错误：修正重复定义和未定义变量的问题，保证程序正常编译运行。

内容的提问来源于stack exchange，提问作者Kathryn Silalahi