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

问题描述

HTTP/3 规范指出

因为 HTTP/2 多路复用的并行特性对 TCP 的丢失恢复机制不可见，丢失或重新排序的数据包会导致所有活动事务陷入停顿，无论该事务是否直接受到丢失数据包的影响

虽然我是在累积 ACK 的上下文中理解这一点的，但我认为 selective ACKs 会在它们允许的情况下防止停顿

接收方确认正确接收的不连续数据包块

但显然，根据上面 HTTP/3 规范中的引用，情况并非如此。那么，我的问题是，为什么 head-of-line 阻塞会持续存在，即使是不连续的确认？

解决方法

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