HTTP请求合并与功耗平衡实战 - 第1节
1.1 串行请求瓶颈：从单个连接说起
在最原始的 HTTP/1.1 模型中，客户端对同一个域名的多个请求必须串行排队——前一个请求的完整响应到达后，才能发送下一个请求。这种串行机制在网络传输层面暴露出两个直接瓶颈：
- 空闲时间堆积：每个请求等待前一个请求的 RTT（往返时延）和服务器处理时间，整个任务流的尾部延迟被串联放大。
- 连接复用低效：虽然 HTTP/1.1 支持 keep-alive 复用 TCP 连接，但队头阻塞（HOL blocking）仍使多个资源无法并行获取，尤其在高延迟网络（如移动蜂窝网、卫星链路）上表现严重。
以下表格对比串行请求与理想并行情况下的关键指标：
| 指标 | 串行（HTTP/1.1 默认） | 理想并行 |
|---|---|---|
| 总完成时间 | n × (RTT + Tproc) | RTT + max(Tproc) |
| 连接利用率 | 每连接串行 | 并发复用 |
| 队头阻塞 | 存在 | 可消除 |
| 功耗影响 | 发送唤醒次数多 | 合并唤醒 |
串行模型下，移动设备的射频模块每次收发都必须经历“唤醒→发射→监听→休眠”的周期，频繁的唤醒导致非信号传输功耗（RF tail）大幅增加。
1.2 请求合并的数学收益：从排队论到网络效率
将多个小请求合并为一个批处理请求，本质上是将 n 次独立的网络事务压缩为 1 次。收益可通过以下数学模型量化：
假设每个请求的固定开销为 C (含 DNS、TLS 握手、TCP 慢启动等)
单个请求总开销 = C + S/B (S为请求大小，B为带宽)
n个请求串行总开销 = n*(C + S/B)
合并后总开销 = C + nS/B
节省开销 = (n-1)*C
当 n 较大或 C 占主导时（如高频小请求场景），合并收益趋近线性。实际测量中，C 在移动网络环境下可高达 50~200ms（含 3/4G 空口调度延迟），而单个小请求的传输时间通常只有 1~5ms。合并 n=10 个请求时，理论上可节省 9×C 的延迟，约 450~1800ms。
1.3 功耗与延迟的权衡：合并不是越多越好
请求合并虽然降低协议开销，但引入新的延迟——必须等待更多请求到达才能合并发送，即汇总延迟（batching latency）。若合并窗口设置过大，用户感知到的交互延迟会恶化；若过小，合并收益不明显。
设计准则：在延迟敏感的交互场景（如用户点击、实时消息）中，合并窗口应控制在 20~50ms 以内；在非交互的后台同步场景（如日志上传、批量更新）中，窗口可放宽至 1~5 秒以最大化功耗节省。
功耗节省主要来自射频模块的休眠时间延长：每减少一次收发，就减少一次射频 tail 能量消耗（约 200~800mJ 每次，取决于网络制式）。
1.4 实现流程：合并策略的分层决策
在客户端/网关实现请求合并时，通常遵循以下流程：
- 请求入队：将同域名的请求暂存于内存队列。
- 触发策略：基于时间窗口（定时器）或数量阈值（如队列满 10 条）触发合并。
- 请求重构：将多个请求体拼接为单个合并请求（如 HTTP Multipart 或自定义批次格式）。
- 网络发送：通过保持的长连接发送合并后的单个请求。
- 响应分发：服务器处理合并请求后返回批响应，客户端拆分结果并回调各原始请求。
以下表格列出常见合并触发策略及适用场景：
| 策略 | 触发条件 | 适用场景 |
|---|---|---|
| 固定时间窗口 | 每 T ms 合并一次 | 定时上报、周期性数据 |
| 自适应窗口 | 根据历史延迟动态调整 T | 混合交互/后台场景 |
| 数量阈值 | 队列长度 ≥ N | 高并发小请求（如埋点） |
| 混合触发 | 时间 or 数量谁先到 | 通用兼容 |
1.5 内联 SVG：请求合并原理与能量权衡图
1.6 调试与性能观察
实践中最直接的调试手段是使用浏览器开发者工具（Network 面板）或抓包工具（如 Wireshark）观察请求的水线图。在合并实现中，应重点检查：
- 同一连接上是否存在连续多个小请求（无合并时出现大量短连接或空闲间隔）。
- 合并后的请求体大小是否显著增加且响应时间接近单一请求的 1 倍左右。
- 移动端可使用 Android Profiler / iOS 的 Xcode Energy Log 对比合并前后的射频唤醒次数。
常见错误：合并后请求体过大导致 HTTP 分片或 TCP 分段，反而增加尾部延迟。建议合并后的总大小控制在 1 MB 以内（视网络条件调整）。此外，合并不当会导致服务端解析失败——必须确保服务端能正确处理批量请求（如支持 multipart/mixed 或自定义 Content-Type）。
1.7 部署注意事项
在生产环境引入请求合并时，需考虑以下策略：
- 白名单机制：仅对配置的 URL 模式或请求类型（如 GET 静态资源、POST 异步埋点）启用合并，避免影响 API 语义。
- 降级开关：当用户网络质量极差或服务器返回 503 时，自动退化为串行模式，保证可用性。
- 请求优先级：高优先级请求（如用户触发的关键操作）应跳过合并队列立即发送。