随着数据不断被处理，接收方就有能力处理更多数据。当满足 (flow control receive offset - consumed bytes) < (max receive window / 2) 时，接收方会发送 WINDOW_UPDATE frame 告诉发送方你可以再多发送些数据过来。这时 flow control receive offset 就会偏移，接收窗口增大，发送方可以发送更多数据到接收方。
Stream 级别对防止接收端接收过多数据作用有限，更需要借助 Connection 级别的流量控制。理解了 Stream 流量那么也很好理解 Connection 流控。Stream 中，接收窗口(flow control receive window) = 最大接收窗口(max receive window) - 已接收数据(highest received byte offset) ，而对 Connection 来说：接收窗口 = Stream1 接收窗口 Stream2 接收窗口 ... StreamN 接收窗口 。
2. HTTP/3 实践2.1 X5 内核与 STGWX5 内核是腾讯开发的适用于安卓系统的浏览器内核，为了解决传统安卓系统浏览器内核适配成本高、不安全、不稳定等问题而开发的统一的浏览器内核。STGW 是 Secure Tencent Gateway 的缩写，意思是腾讯安全云网关。两者早在前两年便支持了 QUIC 协议。
那作为运行在 X5 上的业务，我们该如何接入 QUIC 呢？得益于 X5 和 STGW，业务在接入 QUIC 时所需要做的改动非常小，只需要两步。
Step 1. 在 STGW 上开启白名单，允许业务域名接入 QUIC 协议；
Step 2. 业务资源的 Response Header 添加 alt-svc 属性，示例：alt-svc: quic=":443"; ma=2592000; v="44,43,39"。
接入 QUIC 时，STGW 的优势非常明显，由 STGW 与支持 QUIC 的客户端(这里是 X5)进行通信，而业务后台与 STGW 仍然使用 HTTP/1.1 通信，QUIC 所需要的 Server Config 等缓存信息也都是由 STGW 维护。
2.2 协商升级与竞速业务域名加入了 STGW 的白名单，业务资源的 Response Header 也添加了 alt-svc 属性，那 QUIC 是如何建立连接的呢？这里有个关键的步骤：协商升级。客户端不确定服务器是否支持 QUIC，如果贸然地请求建立 QUIC 连接可能会失败，所以需要经历协商升级过程才能决定是否使用 QUIC。
首次请求时，客户端会使用 HTTP/1.1 或者 HTTP/2，如果服务器支持 QUIC，则在响应的数据中返回 alt-svc 头部，告诉客户端下次请求可以走 QUIC。alt-svc 主要包含以下信息：
- quic：监听的端口；
- ma：有效时间，单位是秒，承诺在这段时间内都支持 QUIC；
- 版本号：QUIC 的迭代很快，这里列出所有支持的版本号。
确认服务器支持 QUIC 之后，客户端向服务端同时发起 QUIC 连接和 TCP 连接，比较两个连接的速度，然后选择较快的协议，这个过程叫“竞速”，一般都是 QUIC 获胜。
2.3 QUIC 性能表现
