0

HTTP/3规范指出

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

虽然我在累积 ACK 的背景下理解这一点，但我曾假设选择性 ACK可以防止停顿，因为它们允许

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

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

4

1 回答 1

1

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

于 2021-05-31T12:30:39.463 回答