Http1.1 vs http2.0 vs http3.0

各协议的对比

http1.1	http2.0	http3.0
缓存处理	二进制帧	无队头阻塞
部分资源获取	服务器主动推送资源	更快的连接迁移
支持长连接	并发传输	建立连接速度更快
减少服务器的http响应数据大小	头部压缩
减少http请求次数	兼容http/1.1

一、http1.1

缓存处理

当客户端首次发送http请求给服务端时，客户端会将收到的不经常变化
的响应进行缓存。当下一次访问时，通过查找本地的缓存，从而进行数据的获取。如下图。

当数据更新，会一直访问缓存中的旧数据，我们应该怎么做？

1. 给缓存设置一个过期时间，当客户端请求数据时，会对比过期时间。如果过期了就去请求服务端，如果没有，就会走缓存。
2. 上面的方案会造成一个缺点，就是当服务端的数据没有变化。但是，过期时间到了，我们却重新
获取资源，导致服务端重新发送资源。因此，可以增加一个Etag字段，来表明服务端的数据是否更
改。如果没有更改，服务端返回304响应（不包含数据体）。因此，客户端会重新去缓存中获取数据。如下图。

减少http请求次数

方案一 减少重定向次数

301 Move Permanently： 资源被永久重定向。
302 Found：资源被临时重定向了。

http1.0处理方案：
访问了重定向资源时，该服务器会返回重定向后的地址，然后客户端再拿到新的地址并重新发起http请求。如下图

缺点：请求次数过多

http1.1处理方案：
通过代理服务器完成重定向的工作，如下图

方案二 合并请求

客户端通过将小的请求合并成一次大的请求，以减少重复发起HTTP请求。但是当大资源中的某一个小资源发生变化后，客户端必须重新下载整个完整的大资源文件，这显然带来了额外的网络消耗。如下图

方案三 延迟发送请求

不要一口气吃成大胖子，一般 HTML 里会含有很多 HTTP 的 URL，当前不需要的资源，我们没必要也获取过来，于是可以通过「按需获取」的方式，来减少第一时间的 HTTP 请求次数。

请求网页的时候，没必要把全部资源都获取到，而是只获取当前用户所看到的页面资源，当用户向下滑动页面的时候，再向服务器获取接下来的资源，这样就达到了延迟发送请求的效果。

减少服务器的http响应数据大小

当服务端给客服端返回响应时，可以通过对响应中的内容进行压缩

无损压缩： 无损压缩是指资源经过压缩后，信息不被破坏，还能完全恢复到压缩前的原样，适合用在文本文件、程序可执行文件、程序源代码。

有损压缩： 有损压缩主要将次要的数据舍弃，牺牲一些质量来减少数据量、提高压缩比，这种方法经常用于压缩多媒体数据，比如音频、视频、图片。

二、Http2.0

头部压缩

http1.1 对数据部分进行了压缩，2.0对头部进行了压缩。然而，http头部包含了大量的重复信息，因此可以使用HPACK算法来进行压缩。HPACK算法主要包含三个组成部分：
静态字典、动态字典、Huffman编码（用来将数据进行压缩，降低字符占的位数）。
静态字典: HTTP/2 为高频出现在头部的字符串和字段建立了一张静态表，它是写入到 HTTP/2 框架里的，不会变化的，静态表里共有 61 组，如下图。
动态字典：静态表只包含了 61 种高频出现在头部的字符串，不在静态表范围内的头部字符串就要自行构建动态表，它的 Index 从 62 起步，会在编码解码的时候随时更新。

因此，可以通过索引代替原来的值，从而减少数据大小。

动态表编码： 比如，第一次发送时头部中的「User-Agent 」字段数据有上百个字节，经过 Huffman 编码发送出去后，客户端和服务器双方都会更新自己的动态表，添加一个新的 Index 号 62。那么在下一次发送的时候，就不用重复发这个字段的数据了，只用发 1 个字节的 Index 号就好了，因为双方都可以根据自己的动态表获取到字段的数据

缺点： 1.经常变化的字段信息或者只使用一次的字段，会导致动态表利用率不生效。
2. 动态链表扩大之后会导致内存占用升高，因此当动态链表到达了一定的大小时，会断开http/2.0连接释放内存。

二进制帧

http/2通过把文本格式数据转换成二进制格式传输数据，极大提高了http的请求效率。

http/2.0 把响应分为HEADS帧和DATA帧。
比如状态码200，1.1中需要花三个字节‘2’，‘0’，‘0’，现在只要花一个字节（1000 1000）。从静态表中找到index为8的索引，一个字节就能表示。

二进制帧的格式：如下图

帧类型后面的一个字节是标志位，可以保存 8 个标志位，用于携带简单的控制信息，比如：

• END_HEADERS 表示头数据结束标志，相当于 HTTP/1 里头后的空行（“\r\n”）；
• END_Stream 表示单方向数据发送结束，后续不会再有数据帧。
• PRIORITY 表示流的优先级；

帧头的最后 4 个字节是流标识符（Stream ID），但最高位被保留不用，只有 31 位可以使用，因此流标识符的最大值是 2^31，大约是 21 亿，它的作用是用来标识该 Frame 属于哪个 Stream，接收方可以根据这个信息从乱序的帧里找到相同 Stream ID 的帧，从而有序组装信息。

最后面就是帧数据了，它存放的是通过 HPACK 算法压缩过的 HTTP 头部和包体。

并发传输

http1.1中，只要服务器返回了响应，客户端才能接着发送。因此，当服务器一直不返回数据，客户端会有队头阻塞的问题。
http2.0中，利用stream流来复用tcp连接。因此，在同一个tcp连接中，可以并发建立大量的sream流。从而达到并发传输的效果。如下图

因此，我们可以得出个结论：多个 Stream 跑在一条 TCP 连接，同一个 HTTP 请求与响应是跑在同一个 Stream 中，HTTP 消息可以由多个 Frame 构成， 一个 Frame 可以由多个 TCP 报文构成。

在 HTTP/2 连接上，不同 Stream 的帧是可以乱序发送的（因此可以并发不同的 Stream ），因为每个帧的头部会携带 Stream ID 信息，所以接收端可以通过 Stream ID 有序组装成 HTTP 消息，而同一 Stream 内部的帧必须是严格有序的。

客户端和服务器双方都可以建立 Stream，因为服务端可以主动推送资源给客户端， 客户端建立的 Stream 必须是奇数号，而服务器建立的 Stream 必须是偶数号。

同一个连接中的 Stream ID 是不能复用的，只能顺序递增，所以当 Stream ID 耗尽时，需要发一个控制帧 GOAWAY，用来关闭 TCP 连接。

HTTP/2 通过 Stream 实现的并发，比 HTTP/1.1 通过 TCP 连接实现并发要牛逼的多，因为当 HTTP/2 实现 100 个并发 Stream 时，只需要建立一次 TCP 连接，而 HTTP/1.1 需要建立 100 个 TCP 连接，每个 TCP 连接都要经过 TCP 握手、慢启动以及 TLS 握手过程，这些都是很耗时的。

缺点：复用的是tcp连接，而tcp要求达到的报文必须有序，因此到报文无需时，会一直等待，导致队头阻塞。

服务器主动推送资源

服务器支持主动推送资源，大大提升了消息的传输性能，服务器推送资源时，会先发送 PUSH_PROMISE 帧，告诉客户端接下来在哪个 Stream 发送资源，然后用偶数号 Stream 发送资源给客户端。如下图

三、http3.0

由于http2.0底层采用的是tcp连接，所以服务端的队头阻塞无法解决，此外tcp建立的连接花费的RTT更多。最后呢，由于tcp的报文是（源 IP、源端口、目的 IP、目的端口）确定一条 TCP 连接，因此同一台设备切换网络需要重新建立tcp连接。

为了解决上述问题，http3.0采用了udp连接。但是，此udp连接是基于应用层的quic的协议，该协议实现了数据传输的安全、可靠性。

无队头阻塞

http3.0 由于基于udp，所以服务端的队头阻塞问题也解决了。因为upd是不可靠且无连接的，所以并不会要求等待此stream中的报文全部接收才会处理其他的stream。因此也就不会阻塞其他的stream流中的数据。所以，QUIC 连接上的多个 Stream 之间并没有依赖，都是独立的，某个流发生丢包了，只会影响该流，其他流不受影响。

更快的连接建立

因为http2.0中的，tcp建立连接（三次握手）以及TLS连接(四次握手)，需要花费3RTT时延。此外呢，tcp属于运输层，tls数据表示层，所以两者的链接很难合并到一起进行。需要先tcp，再TLS握手。

HTTP/3 在传输数据前虽然需要 QUIC 协议握手，这个握手过程只需要 1 RTT，握手的目的是为确认双方的「连接 ID」，连接迁移就是基于连接 ID 实现的。

quic协议也是属于应用层，所以TLS和quic可以合并在一起，同时发送。以到达缩短RTT的目标。

因为quic协议包含了tls，所以只需要一个RTT就可以与客户端建立连接以及密钥协商。如果把发送数据也同时发送，可以做到0RTT。

连接迁移

因为HTTP3.0底层采用的是QUIC协议，通过建立连接id来确认双方的连接，而不是IP端口号。因此即使移动设备的网络变化后，导致 IP 地址变化了，只要仍保有上下文信息（比如连接 ID、TLS 密钥等），就可以“无缝”地复用原连接，消除重连的成本，没有丝毫卡顿感，达到了连接迁移的功能。

引用：小林coding