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

Question

正如spec所说：

  

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

并在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，或等同于h2c的TLS。

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

在这种情况下，HTTP / 2规范引用的“hop”是客户端和服务器之间的整个网段。

然而，HTTP / 2规范必须是通用的，而不必担心在定义有线协议（如HTTP / 2）时浏览器和Web服务器如何交互。

想象一下客户端使用server1向h2执行HTTP / 2请求的情况，而server1需要调用server2来完成请求，这次使用h2c。例如，server1可能是一个前端“代理”，它根据某些逻辑将请求转发给“正确的”后端服务器。

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

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

例如，假设客户端将大文件上载到服务器。 通常，客户端流控制发送窗口很小，比如默认的65535个八位字节。在停止上传之前，客户端最多只能发送65535个八位字节。

这些65535个八位字节由server1接收。现在server1成为客户，以便与server2进行通信。让我们假设server1的客户端在与server2通信时配置了一个小得多的流量控制窗口，比如只有16384个八位字节。

在此示例中，server1在16384个八位字节后将上传停止到server2，并且必须设法保留等待server2通知的剩余65535-16384个八位字节（通过WINDOW_UPDATE）框架）上传的数据已被消费。

当server1的客户端从server2收到WINDOW_UPDATE时，它可以向server2发送更多数据;而且，它必须决定是否向客户端发送WINDOW_UPDATE（因为它的流控制窗口与客户端现在有额外的16384个八位字节的空间）或等待一点。 例如，它可以向server2发送另外16384个八位字节，并且只有在从server2接收到第二个WINDOW_UPDATE时才能决定向客户端发送WINDOW_UPDATE（更新为16384 + 16384个八位字节）。 / p>

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

您可能还想阅读this answer以了解有关流量控制策略实施的讨论。

Answer 2

这取决于啤酒花/中介的含义。

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

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

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