发送 GET 和 POST 请求(中)

GET 请求的响应处理是确保设备获取有效数据的关键，嵌入式 HTTP Client 需通过 “分阶段解析” 应对响应数据流，同时规避内存不足风险。当 ENC28J60 接收到服务器返回的 TCP 数据后，会触发 INT 引脚中断，MCU 通过 SPI 读取模块接收缓冲区（默认 6KB）中的响应数据，首先解析响应行中的状态码：若为 200 OK，说明请求成功，需继续解析响应头与响应体；若为 304 Not Modified，表明资源未更新，直接关闭连接以节省功耗；若为 400 Bad Request 或 404 Not Found，需记录错误日志并触发重试（通常重试 2 次，间隔 3 秒）；若为 5xx 服务器错误，则需延长重试间隔（如 10 秒），避免频繁请求加重服务器负担。解析响应头时，重点提取Content-Length（如Content-Length: 128）以确定响应体大小，Content-Type（如Content-Type: application/json）以选择对应解析方式，例如 JSON 格式的 OTA 版本响应体{"has_update":true,"new_version":"v1.1","firmware_url":"http://ota-server.com/fw/v1.1.bin"}，MCU 可通过轻量化 JSON 解析库（如 cJSON 的微型版本）提取has_update与firmware_url字段，无需加载完整库；若响应体体积较大（如 1KB 的配置文件），则采用 “分块读取 - 即时解析” 模式，每读取 256 字节就解析一次，避免将完整响应体存入 RAM 导致溢出。

POST 请求作为 HTTP Client 中核心的资源提交方法，其核心定位是 “向服务器推送数据”，在物联网场景中常用于传感器数据上报、设备状态反馈、OTA 升级结果提交等，其关键特征是请求参数通过请求体传递（而非 URL），支持大体积数据传输，且对资源的操作不具备幂等性（多次请求可能导致服务器资源重复创建），这一特性使其在需提交动态数据的场景中更具灵活性。与 GET 请求相比，POST 请求的构建更复杂，需同时处理 “请求头” 与 “请求体”，且需通过Content-Type字段明确请求体格式，以确保服务器能正确解析 —— 在嵌入式设备中，POST 请求的设计需重点解决 “内存占用” 与 “数据完整性” 的平衡，例如 STM32F103（RAM 仅 20KB）在上报 10KB 传感器日志时，需通过固定大小缓冲区（如 1024 字节）分块构建请求体，避免动态内存分配导致的碎片问题。

POST 请求的头部构建需额外关注与请求体相关的字段，以确保数据传输的正确性与效率。除Host、User-Agent、Connection等基础字段外，Content-Type是 POST 请求的核心必选字段，需根据请求体格式选择对应值：若请求体为 JSON 格式（如传感器结构化数据{"temp":25.3,"humidity":60.2,"timestamp":1731800000}），则Content-Type设为application/json；若为表单数据（如设备注册信息device_id=sn_123&key=abc123），则设为application/x-www-form-urlencoded；若需传输二进制数据（如小体积设备日志文件），则设为multipart/form-data并指定边界符（如boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW）。Content-Length字段同样关键，需准确填写请求体的字节数（如 JSON 数据长度为 58 字节，则Content-Length: 58），服务器通过该字段判断请求体是否接收完整，避免数据截断；若请求体体积动态变化（如实时采集的传感器数据流），则可采用 “分块传输编码”（设置Transfer-Encoding: chunked），无需预先计算总长度，每传输一块数据就附加该块长度（十六进制），最后以0\r\n\r\n标识结束，这一方式尤其适合 NB-IoT 等低带宽场景，可减少因数据长度计算错误导致的传输失败。

POST 请求体的构建是嵌入式 HTTP Client 的实现难点，需根据数据类型与设备资源设计 “轻量化方案”。对于 JSON 格式的结构化数据，嵌入式设备通常采用 “静态字符串拼接 + 参数替换” 的方式构建请求体，例如预先定义 JSON 模板{"temp":%f,"humidity":%f,"timestamp":%d}，再通过sprintf函数将采集到的温度（25.3）、湿度（60.2）、时间戳（1731800000）替换占位符，生成完整请求体 —— 需注意的是，sprintf可能导致缓冲区溢出，因此需使用安全版本（如snprintf）并严格限制缓冲区大小（如 256 字节），确保适配多数短数据上报场景。对于大体积数据（如 5KB 的设备运行日志），则需采用 “分块写入” 策略：MCU 将日志数据从 Flash 中逐块读取（每块 1024 字节），通过 HTTP Client 的esp_ota_write类接口写入请求体缓冲区，每写满一块就触发一次传输，同时记录已传输字节数，避免内存堆积；若设备支持硬件 SPI DMA（如 STM32L4），可将 Flash 读取与请求体写入过程并行，进一步提升效率。对于二进制数据（如小图片、固件片段），需通过 “Base64 编码” 转换为文本格式嵌入请求体（如{"log_data":"SGVsbG8gV29ybGQh..."}），或使用multipart/form-data格式直接传输二进制流，前者兼容性更强（多数服务器支持 Base64 解码），后者更节省带宽（无需编码开销），需根据服务器支持能力选择。