http2 - 关于 HTTP/2 RFC 实现的流量控制问题

Question

我正在构建一个 http/2 客户端，我有一个关于 rfc 以及我应该如何处理实现的问题，特别是在流控制方面。

我知道流量控制使用基于信用的窗口大小系统，但我有点不确定如何处理耗尽窗口的情况。

我是否只是无限期地阻塞，直到 WINDOW_UPDATE 框架释放东西？或者合理的超时时间是多少？

当窗口耗尽时，我会暂停发送所有帧吗？ RFC 声明流中帧的顺序非常重要，尤其是对于 header 和数据帧，但它没有明确声明在窗口耗尽时应该暂停所有帧。这对我来说有点模棱两可，因为数据帧是唯一计入窗口大小的。那么我应该阻止发送所有帧还是只发送标题/数据？对于连接流控制上下文与流流控制上下文，此答案是否不同？

Answer 1

连接中的所有数据帧都有一个流控制窗口，然后每个流都有一个流控制窗口。

1.- 如果连接窗口已用完，则暂停发送任何流的 DATA 帧，直到获得 WINDOWS_UPDATE。您可以实现超时。如果超时到期，唯一的补救方法是关闭连接并重试。

2.- 如果流连接窗口已用尽，则仅暂停该流。

在所有情况下，您只暂停 DATA 帧。其他类型的帧不受流量控制的影响。

如果您正在实现客户端，而不是服务器，则您更关心自己发送 WINDOW_UPDATE 帧。除非你做了很多 POST 和 PUT，即将数据发送到服务器。

根据我作为 HTTP/2 server 的开发人员的经验，我发现在我称为“火车”的组中管理 HTTP/2 帧很方便。对于除 HEADERS、PUSH_PROMISE 和 CONTINUATION 之外的所有帧，火车仅由帧组成。对于 HEADERS 和 PUSH_PROMISE，火车由该帧和任何后续的 CONTINUATION 帧组成。然后您将您的火车放入具有以下级别的优先级队列(首先具有最高优先级):

PING 帧:您希望对等方准确确定延迟，因此您在收到这些帧时尽快处理它们，并尽快发送答案。

设置、WINDOW_UPDATE、RST_STREAM、GO_AWAY

PUSH_PROMISE 和 HEADERS 列车。 HTTP/2 规范允许两种(实际上是三种)类型的 HEADERS 帧:作为 HTTP header 和尾部发送的帧。这里我说的是第一个。

数据帧。如果您正在实现优先级划分，您可能希望在此处进一步确定框架的优先级。

并且每当 channel 可用于发送时，您将发送优先级队列中最高优先级的列车。