HTTP / 2逐跳流控制如何完成？

Question

正如规范所说：

流控制特定于连接。 两种类型的流控制都在单跳的端点之间，而不是在整个端到端路径上。

并在6.9 WINDOW_UPDATE中

两种类型的流控制都是逐跳的 ，即仅在两个端点之间。 中介程序不会在依赖连接之间转发WINDOW_UPDATE帧 。 但是，任何接收者进行的数据传输限制都可能间接导致流控制信息向原始发送者传播。

但这怎么可能呢？ 似乎要求所有中介机构都了解h2或h2c协议，我有两个问题：

1. HTTP / 2是一个相对较新的标准，我已经看到许多网站启用了它（包括我的博客）。 虽然我可以毫无问题地访问这些网站，但这是否意味着沿途的每个中间设备（如路由器和集线器等）都已经实现了自己的HTTP / 2堆栈和流控制算法（因为RFC7540并未规定流控制算法）？

2. 大多数网站使用h2而不是h2c ，后者会加密应用程序层数据。 HTTP / 2的流控制是通过接收方发送WINDOW_UPDATE帧（也是应用程序层数据）来完成的，那么中间设备如何知道这些数据是什么？ 如果他们无法解密数据并看到“ Window Size Increment部分，那么他们如何在不转发WINDOW_UPDATE帧的同时完成流控制？

Answer 1

首先，进行一些更正。

令牌h2c引用明文HTTP / 2（因此c在h2c ）。 在第二个项目符号中，您说大多数网站都使用它，但实际上很少使用它，因为浏览器没有实现它。 绝大多数网站都使用h2 。

令牌h2指的是加密的h2c或等效于TLS的h2c 。

当客户端和服务器协商说h2 ，客户端发送的字节将被加密，并一直加密到服务器。 这意味着中介没有机会解密流量（谢谢）。

在这种情况下，HTTP / 2规范所指的“跃点”是客户端和服务器之间的整个网络段。

但是，HTTP / 2规范需要通用，并且不必担心在定义诸如HTTP / 2之类的有线协议时浏览器和Web服务器如何交互。

想象一下这样一种情况，客户端使用h2向server1执行HTTP / 2请求，而server1需要调用server2来满足该请求，这次是使用h2c 。 例如， server1可以是前端“代理”，它根据某些逻辑将请求转发到“右”后端服务器。

在这种情况下，您有2个跃点：c​​lient-server1和server1-server2。

每个跃点都应用自己的流量控制。

例如，假设客户端将一个大文件上传到服务器。 通常，客户端流控制发送窗口很小，例如默认的65535个八位位组。 客户端最多只能发送65535个八位位组，然后再停止上传。

这65535个八位位组由server1接收。 现在， server1成为客户端以便与server2进行通信。 想象一下，当server1的客户端与server2通信时，已经为它配置了一个较小的流控制窗口，例如16384个八位位组。

在此示例中， server1在16384个八位位组之后停止上载到server2 ，并且必须设法保留其余的65535-16384个八位位组，以等待server2通知（通过WINDOW_UPDATE帧）已使用了上载的数据。

当server1的客户端从server2接收到WINDOW_UPDATE时，它可以向server2发送更多数据； 而且，它还必须决定是否向客户端发送WINDOW_UPDATE（因为它与客户端的流控制窗口现在可以再容纳16384个八位字节了）还是还要再等待一点。 例如，它可以向server2发送另一个16384个八位位组，并且只有在从server2接收到第二个WINDOW_UPDATE时，才可以决定向客户端发送WINDOW_UPDATE（更新为16384 + 16384个八位位组）。

从上面的示例中可以看到，客户端和server1之间的流控制与server1和server2之间的流控制相关但独立。

您可能还需要阅读此答案 ，以获取有关流控制策略实现的讨论。

Answer 2

它取决于啤酒花/中间体的含义。

如果中介位于较低级别（TCP网关，NAT，交换机等），则它们对HTTP / 2透明，因为HTTP / 2流控制是在HTTP / 2客户端和服务器之间端对端应用的。 他们之间的单个跃点可能使用较低级别的流量控制机制。

如果您的中介是HTTP代理，则基本上有两个单独的HTTP请求正在进行，每个请求都应用它自己的流控制。 代理应用程序负责在保留流控制属性的同时连接这些单独的跃点。 例如，不立即读取第二跳的整个响应，然后将其转发到第一跳，而是通过流传输适当的数据块。

如果使用HTTP代理，您甚至会遇到将HTTP / 1.1代理到HTTP / 2的情况，反之亦然。 在这些情况下，它们代理将使用HTTP / 2流控制机制来确保该跃点的流控制，并使用TCP流控制来提供另一跃点上的流控制。 如果协议类型正确封装在代理应用程序中（这意味着它将提供尊重Request和Response类型的流控制的流操作），则代理不同协议类型之间的流应该不会太难。