HTTP/2 未来已来，HTTP/3 未来？

Posted 2021-04-02 wangyanglinux 宝典

作为 IT 从业者，HTTP 协议对于大家来说都不是陌生的东西，遥想四年前在教室中给学生们讲解 HTTP/2 版本协议这个新家伙的时候，还是那么激情。如今，HTTP/2 已经走入寻常企业家是时候推出 HTTP/3 了。没错，google 又再一次的引领了行业！

1

HTTP/3 是什么？

ps：对于基本功底不是很扎实，或者错过了 HTTP/2 协议的同学建议观看 https://svcloudt.com/ 寻找答案

如上图所示，HTTP/3 是基于 QUIC 的协议。而 QUIC 协议是 Google 提出的一套开源协议，它基于 UDP 来实现，直接竞争对手是 TCP 协议。那么，如果想去解决 HTTP/3 的特性，也就等同于解决 QUIC，来我们一起看一看。

2

QUIC 为何？

What is QUIC?

Quick UDP Internet Connection(QUIC) 协议是 Google 公司提出的基于 UDP 的高效可靠协议。说它高效，是因为使用了无连接的 UDP 而不是迭代周期更长的需要修改系统内核网络栈的 TCP 协议。说它可靠，是因为将改进了的可靠 TCP 的协议特征用到了 QUIC 上。同时，也复用和改进了 HTTP2 的典型特征，譬如二进制分帧，多路复用，header 压缩等。

How QUIC works?

① 建立连接

• 基于 TCP+TLS 的 HTTP2 建连：出于 HTTP 的明文和无法验证服务器的真实性，在 TCP 的基础上引入了 TLS 协议，目前广泛使用的 HTTPS 是基于 TCP+TLS 协议，HTTP2 也被主流浏览器默认支持 TLS。但对于建立连接的耗时而言，TCP 本身就需要握手时延，而 TLS 协议为了使得客户端和服务器端在不安全的网络通信中协商出后续安全通信所需的加密私钥，更是要经过额外 2 次 RTT ( RoundTrip Time 往返时间 )

• 基于 QUIC 的建立：为了保证安全，QUIC 也是加密传输数据的，所以在 QUIC 的建立连接过程中也需要双方协商出一个加密私钥。但与 TLS 不同，QUIC 采用的加密算法仅需要一个 RTT 就能实现密钥交换，并且该算法也被用于目前正在草案阶段的 TLS1.3 协议，这就是 Diffie-Hellman 密钥交换算法。如下图所示，可以看到，客户端和服务端各自保留了自己的私钥 a 和 b，通过交换各自的公钥 B 和 A，以及基底 G 和很大的质数 P，双方就能计算出相等的私钥 S，这个 S 就是加密传输的对称密钥。另外，根据离散对数的不可逆，即使拿到 G,P,和质数 B，也很难推导出私钥 b（ 同理私钥 a ），也就保证了计算密钥的安全

• 客户端发起 Inchoate client hello

• 服务器返回 Rejection，包括密钥交换算法的公钥信息，算法信息，证书信息等被放到 server config 中传给客户端

• 客户端发起 client hello，包括客户端公钥信息

• 此时，双方各自计算出了对称密钥。QUIC 的 1RTT 建连过程结束，平均只耗时 100ms 以内。后续发起连接的过程中，一旦客户端缓存或持久化了 server config，就可以复用并结合本地生成的私钥进行加密数据传输了，不需要再次握手，从而实现 0RTT 建立连接

② 协商升级

客户端发出tcp请求

服务端如果支持 quic 可以通过响应头 alt-svc 告知客户端

客户端同时发起 tcp 连接和 quic 连接竞赛

一旦 quic 建立连接获胜则采用 quic 协议发送请求

如遇网络或服务器不支持 quic/udp，客户端标记 quic 为 broken

传输中的请求通过tcp重发

5min 后尝试重试 quic，下一次尝试增大到 10min

一旦再次成功采用 quic 并把 broken 标记取消

其中，支持 quic 的 alt-svc 头部信息如下图示，ma 为有效时间（单位秒），v 为支持的 quic 版本信息

除了 alt-svc header，http2.0 下服务端还可以通过支持 alt-svc frame 来让客户端在第一次请求的时候就走新协议，比通过 header 让浏览器第二次才能请求新协议更高效

③ 连接迁移

TCP 使用四元组（ 源IP，源端口，目的IP，目的端口 ）来标识一条连接，当四元组中的 IP 或 端口 任一个发生变化了连接就需要重新建立，从而不具备连接迁移的能力。而 QUIC 使用了 connection id 对连接进行唯一标识。即使网络从 4G 变成了 wifi，只要两次连接中的 connection id 不变，并且客户端或者服务器能通过校验，就不需要重新建立连接，连接迁移就能成功。（此时应该有掌声）

④ 改进的多路复用

在 SPDY 协议出现以前，每个 HTTP 请求都需要建立一条 TCP 连接，那么如果希望请求并行，就需要同时开启多条 TCP 连接（ 都是有建连代价的 ）。而大多数浏览器对于同一个域名可以建立的最大 TCP 连接数是有限制的，所以，如果超出限制，更多的请求资源是无法并行的。SPDY 协议以来提出的多路复用，是让所有请求基于一条 TCP 连接，解决了上述的问题但同时引入了新的问题——队头阻塞，如果某个资源的某个包丢失了，因为 TCP 是保证时序的，就会在接收端形成队头阻塞，TCP 此时无法区分各个资源的包是否关联，因此会停止处理所有资源直到丢包恢复。

QUIC 也有多路复用，但是 QUIC 是基于 UDP 的，UDP 不需要保证包的时序，只会在接收包的时候对包进行重组，因而不存在等待丢包恢复的队头阻塞问题，这样某个资源的包丢失只会影响自身不会影响到其他资源的继续传输，所以是改进的多路复用。

⑤ 双级流量控制

QUIC 是多路复用的，多条 stream 可以建立在一条 connection 上，所以 QUIC 的流量控制不仅基于单个 stream，还基于 connection。stream 级别的流控能够控制单 stream 的数据发送情况。另外，接收窗口的收缩取决于最大接收字节的偏移而不是所有已接受字节的总和，它不像 tcp 流控，不会受到丢失数据的影响

⑥ 拥塞控制

我们知道 TCP 有多种拥塞控制算法，当遇到网络拥塞会通过减包等方式来避免网络环境恶化。但是，UDP 本身是没有拥塞控制的，一旦不加约束的使用会导致侵占其他 “守规矩” 的网络协议的带宽。所以，为了避免上述情况，基于 UDP 的 QUIC 协议借鉴了 TCP 的一些优秀的拥塞控制算法，如默认使用 Cubic，同时，为了避免 AIMD 机制带来的带宽利用率低，采用了 packet pacing 来探测网络带宽。思路是，QUIC 会通过追踪包的到达时间来预测当前带宽的使用情况，以决定是否提高，保持或者减少发送包的速率来避免网络拥塞。

⑦ 丢包恢复

类似拥塞控制，除了基于 TCP 的一些丢包恢复机制，如：TLP，FACK。QUIC 的丢包恢复也在一些方面做了改进。比如：通过引入严格递增的 sequence number 使得计算 RTT 更加精确。更精确的 RTT 也意味更精确的 RTO 和超时重传机制。还比如我们知道 TCP 中有个 SACK 选项，该选项打开时用于记录传输过程中一些没有被确认的数据的范围，便于后续定向重传多组丢失数据，而不是全部重传，所以更多的范围便于更多的选择重传，也意味着更少的重传包频率。但 TCP 最多支持 3 个 SACK 范围，而 QUIC 能支持 255 个。除了上述基于 TCP 的改进的丢包恢复特性以外，早期的 QUIC 版本还有一个丢包恢复机制，就是 FEC（Forward Error Correction），这个特性虽然目前处于正在改造阶段（可能会浪费带宽并且作用不是很明显），但是依然是一个有意思的解决方案。FEC 的思路是通过在一组包（一般是 10 个）中，通过增加一个 FEC 包，并用 FEC 和每个包进行 XOR，如果一旦有丢包，那么将 FEC 包和其余包 XOR，得到的 FEC 包就是那个丢包，所以一组包最多只能恢复一个丢包。

⑧ 除了上述的主要特性，QUIC 还支持一些其它的特性

通过header stream保证流顺序

底层保证连接持久

客户端同时发起 tcp 连接和 quic 连接竞赛

一旦 quic 建立连接获胜则采用 quic 协议发送请求

握手时压缩证书避免放大攻击

⑨ 业界应用情况

Google 超过 50% 的请求来自 QUIC

目前 Youtube 有 20% 的流量来自 QUIC

微博移动端全面支持 QUIC 协议

⑩ QQ 会员页面灰度测试的效果

3

HTTP/3 的优点及其不足？

优势

HTTP/3 使用 stream 进一步扩展了 HTTP/2 的多路复用。在 HTTP/3 模式下，一般传输多少个文件就会产生对应数量的 stream。当这些文件中的其中一个发生丢包时，你只需要重传丢包文件的对应 stream 即可

HTTP/3 不再是基于 TCP 建立的，而是通过 UDP 建立，在用户空间保证传输的可靠性，相比 TCP，UDP 之上的 QUIC 协议提高了连接建立的速度，降低了延迟

通过引入 Connection ID，使得 HTTP/3 支持连接迁移以及 NAT 的重绑定

HTTP/3 含有一个包括验证、加密、数据及负载的 built-in 的 TLS 安全机制

拥塞控制。TCP 是在内核区实现的，而 HTTP/3 将拥塞控制移出了内核，通过用户空间来实现。这样做的好处就是不再需要等待内核更新可以实现很方便的进行快速迭代

头部压缩。HTTP/2 使用的 HPACK，HTTP/3 更换成了兼容 HPACK 的 QPACK 压缩方案。QPACK 优化了对乱序发送的支持，也优化了压缩率

缺陷

HTTP/3 建立传输用的是 UDP 协议，而在 HTTP/3 出现前 UDP 的通常出现地点是类似《计算机网络》这样的书面理论，即便是实际应用也大多和网络攻击一起出现，这就导致 UDP 的名声不太好。名声差了自然在硬件上的支持也捉襟见肘，大部分互联网服务也就理所当然的对 UDP 的访问进行限制

4

准备好迎接 HTTP/3 了吗？

但是毫无疑问的，HTTP/3 是目前最前沿的互联网标准，它的缺点可以通过不断的改进来完善。相比与 HTTP/3 本身的缺陷问题，作为一项新技术最致命的问题是能否获得足够多的有效支持，从而进行大范围推广。

那么当前的环境已经有迎接 HTTP/3 的能力了么？

HTTP/3 作为互联网的标准革新之一，在支持方面无非两点，一个是服务端，一个是客户端。

• 先来看一下客户端，大家所熟悉的浏览器 Chrome 以及常用 Curl 命令行工具都已经支持 HTTP/3 特性。在 Chrome 的开发者工具一栏里你可以看到一项显示为“HTTP/2+quic/99”，这就是 Chrome 已经支持 HTTP/3 的证据。毕竟 HTTP/3 的组成离不开 QUIC 协议。而在 Curl 命令行工具[https://github.com/curl/curl] 的最新版本， 你只需在常规的命令末尾添加“--HTTP/3”即可使用 HTTP/3，如果目标服务器支持，它会自然的返回“HTTP/3 200”。确认了客户端的支持，我们接下来看一下服务端。

• 自 2013 年 QUIC 被正式公开以来，到 2020 年已经发展了差不多7年，目前网上已经有了不少热门开源的项目，除去带头大哥 Google 在完成了对自身搜索引擎的支持，还同时拉上了 Gmail 、YouTube 等站点。但对于国内的绝大部分站点来说，HTTP/3 之路，似乎还停留在东土大唐，即使 nginx 已经公开声明：“我们已经支持 QUIC 协议“。

我们可以看到，虽然目前环境还没有全面迭代到 HTTP/3 ，但是 HTTP/3 的发展是不可阻拦的。

详细演示说明，也可以查看又拍云进行学习演示，后期此公众号也会出详细的演示安装教程！

https://help.upyun.com/knowledge-base/cdn-http3/

END