为何单WebSocket连接下载大量小二进制文件比HTTP2快两倍？

1. 协议帧开销的累积差异 #

HTTP/2即便复用连接并使用HPACK压缩头信息，每个文件请求仍需发送HEADERS帧（哪怕压缩后仅几十字节）+ DATA帧；而WebSocket的二进制消息仅需极小的帧头（通常2-10字节）。对于200KB的小文件，HTTP/2每个请求的协议开销占比远高于WebSocket，当文件数量达到数百甚至数千时，累积的额外字节量和处理耗时会被放大，直接拉低整体速度。

2. 请求生命周期的简化 #

HTTP/2每个请求都要经历完整的流生命周期：流创建、状态转换、响应结束后的流销毁，即便连接复用，这些协议层操作仍会产生额外开销。WebSocket是持久化连接，发送二进制消息无需重复初始化请求上下文，直接复用已建立的会话，省去了每个文件对应的请求启动和收尾步骤。

3. 流量控制与调度策略差异 #

Chrome的HTTP/2实现对并发流的调度和流量控制窗口可能更保守，比如默认的流控制窗口大小或流优先级调度逻辑，会导致小文件请求出现更多等待时间；而基于ws包的WebSocket实现，发送端可更高效地批量推送二进制数据，且浏览器对WebSocket消息的流量控制策略更宽松，减少了窗口阻塞的概率。

4. 浏览器内部处理路径的差异 #

fetch请求会触发浏览器完整的HTTP流程：缓存校验、CORS验证、状态码处理、响应解析等，即便预连接完成，每个请求仍需走这些环节。而WebSocket的二进制消息直接进入应用层处理，跳过了部分HTTP专属的内部逻辑，减少了主线程的CPU占用和处理延迟。

• 用Chrome DevTools的Network面板，分别查看HTTP/2和WebSocket的帧详情：统计HTTP/2每个请求的HEADERS+DATA帧总开销，对比WebSocket的帧开销，计算两者的协议开销占比差异。
• 开启Performance面板录制下载流程，对比两种方式的主线程任务耗时，看HTTP/2是否在请求处理环节占用更多CPU资源。
• 调整HTTP/2的并发流数（比如测试10、30、50、100），观察性能变化：若在低并发下差距缩小，说明流调度是关键因素。
• 启用ws包的日志功能，查看WebSocket消息的批量发送情况；同时在Node.js端记录HTTP/2请求的处理耗时，对比两者的端到端延迟。
• 测试大文件（比如10MB级）下载：若WebSocket的速度优势明显缩小，可验证小文件场景下协议开销是核心影响因素。

内容的提问来源于stack exchange，提问作者Fez Vrasta