定义
HTTP/2是IETF RFC 7540定义的HTTP协议第二个主要版本，基于二进制分帧、多路复用、头部压缩（HPACK）等技术，在保持HTTP语义（请求/响应、方法、状态码）的同时大幅提升传输效率。HTTP/2基于TCP+TLS，物联网设备与云端API通信时可采用HTTP/2；其继任者HTTP/3基于QUIC，进一步降低延迟。
核心特性
- 二进制分帧：将HTTP消息拆分为帧（Frame），支持多路复用与优先级
- 多路复用：单TCP连接上并发多个请求/响应流，消除HTTP/1.1队头阻塞
- 头部压缩HPACK： Huffman编码+静态/动态表，减少重复头部开销
- 服务端推送：服务器可主动推送资源，减少往返
与MQTT的选型
HTTP/2适合请求-响应模式的API调用；MQTT适合发布/订阅、双向推送。物联网设备管理、配置下发、OTA升级等可采用HTTP/2；实时数据上报、命令下发可采用MQTT。两者可并存于同一平台。
典型应用场景
物联网云平台API、设备管理、OTA升级、配置下发等。达希物联云平台API支持HTTP/2，可降低连接开销、提升传输效率。
达希物联云平台API支持HTTP/2，物联网设备与云端通信时可利用多路复用与头部压缩，降低连接开销、提升传输效率。对于需要频繁调用API的设备管理、OTA升级等场景，HTTP/2可显著减少时延与流量消耗，达希物联为客户提供高效的云端对接能力。
流窗口和连接窗口是两级限速
HTTP/2把多个请求拆成帧，复用在同一条传输连接上。每个流有自己的流量窗口，整条连接还有一个总窗口。某一个大文件把连接窗口占满时，同一连接上的小请求即使流窗口还有余量，也发不出去。这和前一版协议的队头阻塞不同：请求已经并发，卡在窗口而不是卡在顺序响应。判断时看是单个流慢，还是所有流一起停。所有流一起停，先查连接窗口和底层拥塞；只有某一个流停，再查该流的应用处理。
窗口过小会把带宽浪费在等待窗口更新上；过大则让慢设备堆积对端内存。模组内存有限时，应把并发流的数量和窗口一起限制。只增加并发、不增加处理能力，请求会在模组里排队，空口上仍是一条连接。
头部动态表在连接重置后要重头学
头部压缩靠一张静态表和一张连接级动态表。重复的头部用索引代替，连接活得越久，压缩越好。弱网把连接频繁打掉时，动态表每次清空，随后的请求又把完整头部送一遍，压缩收益消失，流量比长连接时更大。判断是不是这个问题：短连接上的字节数接近未压缩的请求，长连接上明显下降。物联网应尽量复用连接，而不是每次上报都握手。
动态表有大小上限。表太小，旧的头部索引会被挤掉，发送端和接收端必须同步这个上限。中间代理若改写头部，索引和实际头部会错位，表现为偶发的四零零类错误，而底层连接仍然是通的。代理要声明自己是否终结HTTP/2，不能透明地改头部。
服务端推送在模组上经常被直接关掉
协议允许服务器在响应之外再推送它认为客户端需要的资源。浏览器可以用这个能力提前取页面依赖，物联网模组多数只想要自己请求的那一份配置或固件。推送会占用流和内存，模组常在设置帧里把推送禁用。服务器若忽略禁用仍然推送，模组会复位相应的流，两边都浪费一次往返。对设备下发配置应走设备发起的请求，或走专门的下行通道，而不是依赖推送。
达希物联云平台的接口若启用HTTP/2，收益主要在多次调用共享连接和压缩重复头部。卡和模组仍要先把这条连接稳定地送到平台，协议替代不了覆盖。平台侧看到同一设备反复握手、业务请求很少，应先把连接保持时间延长到覆盖上报周期，再谈并发流。固件下载这种大流应单独限制窗口，避免堵住同连接上的状态查询。
并发流的上限要和模组内存一起写进设置帧
连接开始时的设置帧协商最大并发流和窗口。服务器若按浏览器的习惯给出很大的并发，模组内存放不下对应的流状态，就会复位连接或静默丢帧。复位之后应用看到的是整条连接失败，而不只是某一个请求失败。上限应取模组能同时处理的请求数，而不是取协议允许的最大值。状态查询、配置读取和固件分块不要无限制地并行，固件分块尤其容易占满窗口。
代理在中间终结HTTP/2再转成旧版本时，设置帧里的并发只对第一段有效，第二段可能重新排队。端到端的多路复用收益会在代理处消失。达希物联云平台如果直接对设备提供HTTP/2，应公布设备侧需要遵守的并发和窗口，并在超限时返回明确的流错误，而不是关掉整条连接。卡和覆盖只负责把连接送到平台，连接被设置帧打掉时，重试覆盖没有意义，要先把并发降到模组承受得住的数量。