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

Question

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

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

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

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

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 帧组成。然后您将您的火车放入具有以下级别的优先级队列中（首先具有最高优先级）：

1. PING 帧：您希望对等方准确地确定延迟，因此您会在收到这些帧后尽快处理它们并尽快发送答案。
2. 设置、WINDOW_UPDATE、RST_STREAM、GO_AWAY
3. PUSH_PROMISE 和 HEADERS 火车。 HTTP/2 规范允许两种（实际上是三种）类型的 HEADERS 帧：作为 HTTP 标头和尾部发送的帧。这里我说的是第一个。
4. 数据帧。如果您正在实施优先级，您可能希望在此处进一步确定框架的优先级。

并且只要通道可用于发送，您就会发送优先级队列中优先级最高的火车。