发送 GET 和 POST 请求(下)

POST 请求的传输与响应处理需针对 “请求体存在” 的特性优化，尤其在网络不稳定的物联网场景中，需确保数据不丢失、不重复。传输阶段，HTTP Client 在发送请求头后，需紧接着发送请求体：若为固定长度（Content-Length），则按 “头部→空行→完整请求体” 的顺序一次性发送；若为分块传输（Transfer-Encoding: chunked），则每发送一块数据就附加该块的十六进制长度（如3\r\nabc\r\n），最后发送0\r\n\r\n。在 ENC28J60 模块中，由于其发送缓冲区仅 2KB，当请求体超过缓冲区大小时，MCU 需通过 SPI 循环写入数据：先写入 1KB 请求体数据并触发发送，待模块返回 “发送完成” 信号后，再写入下一块，避免缓冲区溢出 —— 这一过程中，需通过esp_http_client_get_write_len等接口实时监控发送进度，确保数据连续传输。响应处理方面，POST 请求的状态码解析与 GET 类似，但需关注 201 Created（资源创建成功，如设备注册成功）、202 Accepted（请求已接收但未处理，如日志上报排队）等特有状态码；响应体通常包含服务器处理结果（如{"code":0,"msg":"success","data":{"task_id":123}}），MCU 需解析code字段判断是否成功，若失败则根据msg字段调整请求参数（如重新获取设备密钥），确保业务闭环。

GET 与 POST 请求的场景适配需结合物联网设备的业务特性与网络环境，选择最优化的请求方式，同时通过协同设计提升整体效率。在 “高频次轻量查询” 场景（如每 30 秒拉取控制指令），优先选择 GET 请求：一方面无需构建请求体，节省 RAM 与 Flash 资源；另一方面可利用If-Modified-Since等条件头减少无效传输，配合 ENC28J60 的睡眠模式，将单次请求的功耗控制在 0.5mAh 以内。在 “大体积数据上报” 场景（如每小时上报 10KB 传感器日志），则必须选择 POST 请求：通过application/json或分块传输确保数据完整性，同时启用 HTTPS 加密（如 ESP32 的 TLS 硬件加速）防止数据被窃听，若网络为 NB-IoT（带宽仅 100kbps），可通过 gzip 压缩请求体（将 10KB 日志压缩至 3KB），将传输时间从 800ms 缩短至 240ms。在 “混合业务场景”（如设备先 GET 检查 OTA 版本，再 POST 反馈升级结果），可复用 TCP 连接（通过Connection: Keep-Alive），避免两次请求重复建立连接 —— 例如 ENC28J60 在完成 GET 请求后，保持 TCP 连接 30 秒，期间发送 POST 请求时直接复用该连接，减少 TCP 三次握手与 TLS 握手的开销（单次握手可节省 500ms 延迟与 1mAh 功耗）。

嵌入式场景下 GET 与 POST 请求的优化需围绕 “资源节省”“低功耗”“高可靠” 三大核心目标，结合硬件特性与协议细节展开。内存优化方面，GET 请求的 URL 参数与 POST 请求的请求体均需使用静态缓冲区，避免malloc动态分配，例如将 GET 的 URL 缓冲区固定为 512 字节，POST 的请求体缓冲区固定为 1024 字节，适配 90% 以上的物联网场景；同时通过 “字段复用” 减少冗余，如不同请求复用同一User-Agent头字段，无需重复构建。低功耗优化需与硬件模块休眠协同：GET 请求发送后，若需等待服务器响应（如 OTA 版本检查），可让 ENC28J60 进入睡眠模式，仅保留 INT 引脚监听数据，待收到响应后再唤醒；POST 请求分块传输间隙，若网络延迟较高，可暂停数据发送，让模块休眠 50ms 后再继续，避免空等耗电。可靠性优化方面，GET 请求需处理 URL 参数过长问题（通常限制在 2048 字节内，嵌入式设备建议不超过 512 字节），避免服务器截断；POST 请求需实现 “断点续传”，通过记录已传输字节数，若传输中断（如网络断开），下次连接时通过Range头（如Range: bytes=1024-）从断点继续发送，避免重新传输全部数据 —— 这一机制在 HTTP OTA 固件上报场景中尤为重要，可将大文件传输的失败重试成本降低 80%。

主流嵌入式 HTTP Client 库对 GET 与 POST 请求的实现提供了成熟接口，开发者需根据设备资源与业务需求选择适配方案。esp_http_client（ESP32 平台）通过esp_http_client_perform统一处理 GET 与 POST 请求，仅需通过esp_http_client_set_method设置请求方法，esp_http_client_set_post_field设置 POST 请求体，即可快速实现功能，且支持 TLS 硬件加速与分块传输，资源占用低（GET 请求仅需 3KB RAM，POST 请求需 5KB RAM）；libcurl 的轻量化版本（curl-for-embedded）则提供更灵活的接口，如curl_easy_setopt(curl, CURLOPT_HTTPGET, 1)启用 GET，curl_easy_setopt(curl, CURLOPT_POSTFIELDS, post_data)设置 POST 数据，适合中高端嵌入式设备（如 ARM Cortex-M7）。开发过程中需注意细节：GET 请求的 URL 参数需编码，POST 请求的Content-Type需与请求体格式匹配；HTTPS 场景下需正确配置 CA 证书（或证书指纹），避免连接失败；超时参数需根据网络类型调整（Wi-Fi 环境 GET 请求超时设为 5 秒，NB-IoT 环境设为 15 秒），防止长时间阻塞业务线程。

随着物联网技术的演进，GET 与 POST 请求的实现也在向 “更高效率”“更智能” 方向发展。HTTP/2 协议的支持为 GET 与 POST 带来多路复用能力，可在单个 TCP 连接上同时发送多个 GET/POST 请求，避免 HTTP/1.1 的 “队头阻塞” 问题 —— 例如工业网关通过一个 TCP 连接，同时向服务器发送 10 个传感器的 GET 配置请求与 5 个 POST 数据请求，延迟可从 5 秒缩短至 1 秒。智能化方面，HTTP Client 可通过 “网络感知” 动态调整请求策略：监测到网络带宽低（如 NB-IoT）时，自动压缩 GET 的 URL 参数（通过短参数名替换，如device_id改为did）与 POST 的请求体（gzip 压缩）；监测到网络延迟高时，延长 GET 请求的超时时间，减少 POST 请求的分块大小（从 1024 字节改为 512 字节）。安全性方面，未来 GET 与 POST 请求将更深度集成硬件安全模块（HSM），通过硬件存储 TLS 密钥与证书，防止软件层面的泄露，同时支持 TLS 1.3 协议，将握手时间缩短至 100ms 以内 —— 这些演进将使 GET 与 POST 请求在物联网 “海量连接、复杂网络、高安全需求” 场景中，持续作为数据交互的核心方式，支撑设备全生命周期的业务需求。