为什么 TCP 选择性 ACK 不能防止 HTTP/2 中的 HOL 阻塞？

Question

HTTP/3 规范指出

because the parallel nature of HTTP/2's multiplexing is not visible to TCP's loss recovery mechanisms, a lost or reordered packet causes all active transactions to experience a stall regardless of whether that transaction was directly impacted by the lost packet

虽然我在累积 ACK 的上下文中理解这一点，但我曾假设 selective ACKs 会阻止停顿，因为它们允许

the receiver to acknowledge discontinuous blocks of packets which were received correctly

但根据上述 HTTP/3 规范中的引述，显然情况并非如此。那么，我的问题是为什么 队头 阻塞即使在不连续的确认下仍然存在？

Answer 1

即使使用选择性 ACK，在将数据流转发给应用程序之前仍然需要获取丢失的数据。应用程序期望来自 TCP 的连续数据流，并且没有机制来处理稍后填充的临时漏洞。选择性 ACK 所允许的只是传达已经接收到的数据不需要再次重新发送，而只有未完成的数据（流中的空洞）需要重新发送。