把请求映射到QUIC流
HTTP/3保留HTTP的方法、状态与资源意义，把传输换为QUIC。客户端发起的双向流承载请求及其响应，流中的HEADERS和DATA等HTTP帧表达相应消息；QUIC负责该流内的可靠有序交付。
连接范围的控制信息使用专门的单向控制流，其他单向流还可服务于QPACK等机制。它不是把HTTP/2帧未经修改地装进UDP：哪些工作由QUIC完成、哪些仍由HTTP/3完成，都有明确分层和流类型规则。
参考：[1]
减少跨流顺序依赖
QUIC不要求不同流的字节按单一全局顺序交付，一个流丢失数据不必阻止另一个流已经齐备的数据继续交付。这与HTTP/2的多个流共用一条TCP字节流不同，后者的底层缺口会影响后续字节。
独立交付并没有消除所有等待。请求仍可能依赖另一结果，连接共享拥塞控制与资源，字段解码也可能等待QPACK所需的表项。HTTP/3提供的是不同的传输条件，网页最终耗时仍要结合请求依赖、服务器处理和实际路径分析。
压缩状态也要适应乱序
HPACK的状态更新依靠字段块按连接顺序处理，直接搬到QUIC会重新引入跨流依赖。HTTP/3因此采用QPACK，通过专门流更新并确认动态表，而请求流中的字段区引用相应表状态。
发送端可以在压缩效率和阻塞风险之间选择，不使用未确认表项可降低某些等待风险。接收端也限定表容量和潜在阻塞流数量。选择新版本并不意味着可以取消预算；只有协议能力、对端支持和资源安排配合，才可能发挥多路传输的作用。