读 RFC 9114 时，先把三件事分开：HTTP 定义请求与响应的含义；HTTP/3 规定这些消息怎样装进 QUIC 流；QUIC 再提供流、可靠传输和安全连接。外层使用 UDP，不代表应用要自己补上可靠性。
HTTP/2 虽然能同时传输多个请求，但它们共用一条 TCP 有序字节流。前面的字节没有补齐，后面已经收到的字节也不能越过缺口交给上层。这就是为什么应用已经分了流，仍会一起等待。
可以想象同一连接正在下载图片 A 和脚本 B。如果丢失的数据只属于 QUIC 的 A 流，B 流不必为了补齐 A 的字节而停止交付。这里的变化是把有序交付的边界缩到了流，而不是宣称所有请求从此完全独立。
B 仍可能受到共享拥塞控制、连接级流量限制或字段压缩依赖的影响。因此排查一次卡顿时，应分别看：是不是流内缺字节、是不是整条连接的发送额度受限、是不是 HEADERS 在等 QPACK 表项。只说“HTTP/3 没有队头阻塞”，会把这些不同的问题混在一起。