QPACK
HTTP/3中用于头部压缩的算法，类似HTTP/2的HPACK，通过动态表和静态表减少头部大小，引入编码器流与解码器流解决队头阻塞问题。
时间轴 (近 90 天)
QPACK是HTTP/3中用于头部压缩的算法，类似于HTTP/2的HPACK。
QPACK运行在QUIC之上，QUIC的多个流可能乱序到达，若直接沿用HPACK会造成队头阻塞。
QPACK引入了编码器流与解码器流两条单向控制流，用绝对索引和相对索引区分对动态表的引用，并通过已知接收计数等机制协调表状态。
QPACK的动态表容量由SETTINGS参数协商，两端都必须为表预留内存；当引用尚未被确认时，编码方还需限制被阻塞流的数量。
在连接尚未完全验证的窗口，若服务端实现允许携带较大头部块的Initial或0-RTT数据，仍可能形成有限的放大面。
HTTP/3服务器如果未对QPACK头部大小进行限制，可能面临严重的放大攻击风险。
防御QPACK放大攻击应限制头部字段的大小和数量，避免响应膨胀。
防御QPACK放大攻击应对动态表的大小进行严格限制，防止攻击者滥用。
全部知识事实 (8)
QPACK是HTTP/3中用于头部压缩的算法，类似于HTTP/2的HPACK。
50%待验证QPACK运行在QUIC之上，QUIC的多个流可能乱序到达，若直接沿用HPACK会造成队头阻塞。
50%待验证QPACK引入了编码器流与解码器流两条单向控制流，用绝对索引和相对索引区分对动态表的引用，并通过已知接收计数等机制协调表状态。
50%待验证QPACK的动态表容量由SETTINGS参数协商，两端都必须为表预留内存；当引用尚未被确认时，编码方还需限制被阻塞流的数量。
50%待验证防御QPACK放大攻击应对动态表的大小进行严格限制，防止攻击者滥用。
50%待验证HTTP/3服务器如果未对QPACK头部大小进行限制，可能面临严重的放大攻击风险。
50%待验证防御QPACK放大攻击应限制头部字段的大小和数量，避免响应膨胀。
50%待验证在连接尚未完全验证的窗口，若服务端实现允许携带较大头部块的Initial或0-RTT数据，仍可能形成有限的放大面。
50%