关于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开发人员的经验，我发现在我称之为＃34; train＆＃34;的组中管理HTTP / 2帧非常方便。对于除HEADERS，PUSH_PROMISE和CONTINUATION之外的所有帧，列车仅由帧组成。对于HEADERS和PUSH_PROMISE，列车由该帧和任何后续的CONTINUATION帧组成。然后将列车置于具有以下等级的优先级队列中（首先具有最高优先级）：

1. PING帧：您希望对等方准确地确定延迟，因此您可以尽快处理这些帧，并尽快发送答案。
2. SETTINGS，WINDOW_UPDATE，RST_STREAM，GO_AWAY
3. PUSH_PROMISE和HEADERS列车。 HTTP / 2规范允许两种（实际上是三种）HEADERS帧类型：作为HTTP头部发送的帧和预告片。我在这里谈论第一个。
4. 数据帧。如果要实现优先级，则可能需要在此处进一步确定框架的优先级。

每当频道可用于发送时，您都会在优先级队列中发送优先级最高的列车。