HTTP/2利用流来实现多路复用，这引入了对TCP连接的使用争夺，会造成流被阻塞。流量控制方案确保在同一连接上的多个流之间不会造成破坏性的干扰。流量控制会用于各个独立的流，也会用于整个连接。

HTTP/2通过使用WINDOW_UPDATE帧来进行流量控制。

流量控制的原则

HTTP/2“流”的流量控制的目标是：在不改变协议的情况下允许使用多种流量控制算法。HTTP/2的流量控制具有以下特征：

1. 流量控制是特定于一个连接的。每种类型的流量控制都是在单独的一跳的两个端点之间的，并不是在整个端到端的路径上的。（这里的一跳指的是HTTP连接的一跳，而不是IP路由的一跳）
2. 流量控制是基于WINDOW_UPDATE帧的。接收方公布自己打算在每个流以及整个连接上分别接收多少字节。这是一个以信用为基础的方案。
3. 流量控制是有方向的，由接收者全面控制。接收方可以为每个流和整个连接设置任意的窗口大小。发送方必须尊重接收方设置的流量控制限制。客户方、服务端和中间代理作为接收方时都独立地公布各自的流量控制窗口，作为发送方时都遵守对端的流量控制设置。
4. 无论是新流还是整个连接，流量控制窗口的初始值是65535字节。
5. 帧的类型决定了流量控制是否适用于帧。目前，只有DATA帧服从流量控制，所有其它类型的帧并不消耗流量控制窗口的空间。这保证了重要的控制帧不会被流量控制阻塞。
6. 流量控制不能被禁用。
7. HTTP/2只定义了WINDOW_UPDATE帧的格式和语义，并没有规定接收方如何决定何时发送帧、发送什么样的值，也没有规定发送方如何选择发送包。具体实现可以选择任何满足需求的算法。

具体实现也负责：

• 管理如何基于优先级发送请求和响应。
• 选择如何避免请求的队首阻塞。
• 管理新流的创建。

为这些选择的算法可以与任何流量控制算法交互。

恰当地使用流量控制

流量控制的目的是保护在资源约束下运转的端点。例如，一个代理需要在许多个连接之间共享内存，并且，可能有缓慢的上游连接和快速的下游连接。流量控制解决了接收方不能处理一个流的数据，但是希望能够继续处理同一连接上其它流的数据的问题。

不需要这种能力的部署可以通告一个最大尺寸(2^31-1)的流量控制窗口，并且，当收到任何数据时，都可以通过发送WINDOW_UPDATE帧来维持这个窗口。这有效禁用了接收方的流量控制。反之，发送方必须一直遵守接收方通告的流量控制窗口。

资源（例如内存）有限的部署可以引入流量控制来限制内存消耗量。然而，如果在不知道带宽延迟乘积的情况下启用流量控制，可能无法最大化利用可用的网络资源。

即使是对当前的带宽延迟乘积有充分的了解，流量控制的实现也可能非常困难。当使用流量控制的时候，接收方必须及时地从TCP接收缓冲中读取数据。如果不这样做，当类似WINDOW_UPDATE的关键帧没有被读取和使用时，可能会导致死锁。