HTTP/1.1、HTTP/2、HTTP/3 演变

大家好，欢迎来到IT知识分享网。

HTTP 基本概念

HTTP 是超文本传输协议，也就是HyperText Transfer Protocol。

HTTP 常见的状态码有哪些？

1xx 类状态码属于提示信息，是协议处理中的⼀种中间状态，实际⽤到的⽐较少。

2xx 类状态码表示服务器成功处理了客户端的请求，也是我们最愿意看到的状态。

• 「200 OK」是最常⻅的成功状态码，表示⼀切正常。如果是⾮ HEAD 请求，服务器返回的响应头都会有 body 数据。
• 「204 No Content」也是常⻅的成功状态码，与 200 OK 基本相同，但响应头没有 body 数据。
• 「206 Partial Content」是应⽤于 HTTP 分块下载或断点续传，表示响应返回的 body 数据并不是资源的全部，⽽是其中的⼀部分，也是服务器处理成功的状态。

3xx 类状态码表示客户端请求的资源发⽣了变动，需要客户端⽤新的 URL 重新发送请求获取资源，也就是重定向。

• 「301 Moved Permanently」表示永久重定向，说明请求的资源已经不存在了，需改⽤新的 URL再次访问。
• 「302 Found」表示临时重定向，说明请求的资源还在，但暂时需要⽤另⼀个 URL 来访问。301 和 302 都会在响应头⾥使⽤字段 Location ，指明后续要跳转的 URL，浏览器会⾃动重定向新的 URL。
• 「304 Not Modified」不具有跳转的含义，表示资源未修改，重定向已存在的缓冲⽂件，也称缓存重定向，也就是告诉客户端可以继续使⽤缓存资源，⽤于缓存控制。

4xx 类状态码表示客户端发送的报⽂有误，服务器⽆法处理，也就是错误码的含义。

• 「400 Bad Request」表示客户端请求的报⽂有错误，但只是个笼统的错误。
• 「403 Forbidden」表示服务器禁⽌访问资源，并不是客户端的请求出错。
• 「404 Not Found」表示请求的资源在服务器上不存在或未找到，所以⽆法提供给客户端。

5xx 类状态码表示客户端请求报⽂正确，但是服务器处理时内部发⽣了错误，属于服务器端的错误码。

• 「500 Internal Server Error」与 400 类型，是个笼统通⽤的错误码，服务器发⽣了什么错误，我们并不知道。
• 「501 Not Implemented」表示客户端请求的功能还不⽀持，类似“即将开业，敬请期待”的意思。
• 「502 Bad Gateway」通常是服务器作为⽹关或代理时返回的错误码，表示服务器⾃身⼯作正常，访问后端服务器发⽣了错误。
• 「503 Service Unavailable」表示服务器当前很忙，暂时⽆法响应客户端，类似“⽹络服务正忙，请稍后重试”的意思。

HTTP 缓存技术

HTTP 缓存有两种实现方式，分别是强制缓存和协商缓存。

强缓存指的是只要浏览器判断缓存没有过期，则直接使用浏览器的本地缓存，决定是否使用缓存的主动性在于浏览器这边。

当我们在浏览器使用开发者工具的时候，你可能会看到过某些请求的响应码是 304，这个是告诉浏览器可以使用本地缓存的资源，通常这种通过服务端告知客户端是否可以使用缓存的方式被称为协商缓存。

当使⽤ ETag 字段实现的协商缓存的过程：

• 当浏览器第⼀次请求访问服务器资源时，服务器会在返回这个资源的同时，在 Response 头部加上 ETag 唯⼀标识，这个唯⼀标识的值是根据当前请求的资源⽣成的；
• 当浏览器再次请求访问服务器中的该资源时，⾸先会先检查强制缓存是否过期：
• 如果没有过期，则直接使⽤本地缓存；
• 如果缓存过期了，会在 Request 头部加上 If-None-Match 字段，该字段的值就是 ETag 唯⼀标识；
• 服务器再次收到请求后，会根据请求中的 If-None-Match 值与当前请求的资源⽣成的唯⼀标识进⾏⽐较：
• 如果值相等，则返回 304 Not Modified，不会返回资源；
• 如果不相等，则返回 200 状态码和返回资源，并在 Response 头部加上新的 ETag 唯⼀标识；
• 如果浏览器收到 304 的请求响应状态码，则会从本地缓存中加载资源，否则更新资源。

HTTP/1.1、HTTP/2、HTTP/3 演变

HTTP/1.1 提⾼了什么性能？

HTTP/1.1 相⽐ HTTP/1.0 性能上的改进：

• 使⽤⻓连接的⽅式改善了 HTTP/1.0 短连接造成的性能开销。
• ⽀持管道（pipeline）⽹络传输，只要第⼀个请求发出去了，不必等其回来，就可以发第⼆个请求出去，可以减少整体的响应时间。

但 HTTP/1.1 还是有性能瓶颈：

• 请求 / 响应头部（Header）未经压缩就发送，⾸部信息越多延迟越⼤。只能压缩 Body 的部分；
• 发送冗⻓的⾸部。每次互相发送相同的⾸部造成的浪费较多；
• 服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端⼀直请求不到数据，也就是队头阻塞；
• 没有请求优先级控制；
• 请求只能从客户端开始，服务器只能被动响应。

HTTP/2 做了什么优化？

HTTP/2 协议是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的。

那 HTTP/2 相比 HTTP/1.1 性能上的改进：

• 头部压缩
• 二进制格式
• 并发传输
• 服务器主动推送资源

1. 头部压缩

HTTP/2 会压缩头（Header）如果你同时发出多个请求，他们的头是⼀样的或是相似的，那么，协议会帮你消除重复的部分。这就是所谓的 HPACK 算法：在客户端和服务器同时维护⼀张头信息表，所有字段都会存⼊这个表，⽣成⼀个索引号，以后就不发送同样字段了，只发送索引号，这样就提⾼速度了。

2. ⼆进制格式

HTTP/2 不再像 HTTP/1.1 ⾥的纯⽂本形式的报⽂，⽽是全⾯采⽤了⼆进制格式，头信息和数据体都是⼆进制，并且统称为帧（frame）：头信息帧（Headers Frame）和数据帧（Data Frame）。

3. 并发传输

我们都知道 HTTP/1.1 的实现是基于请求-响应模型的。同一个连接中，HTTP 完成一个事务（请求与响应），才能处理下一个事务，也就是说在发出请求等待响应的过程中，是没办法做其他事情的，如果响应迟迟不来，那么后续的请求是无法发送的，也造成了队头阻塞的问题。

而 HTTP/2 就很牛逼了，引出了 Stream 概念，多个 Stream 复用在一条 TCP 连接。

从上图可以看到，1 个 TCP 连接包含多个 Stream，Stream ⾥可以包含 1 个或多个 Message，Message 对应 HTTP/1 中的请求或响应，由 HTTP 头部和包体构成。Message ⾥包含⼀条或者多个Frame，Frame 是 HTTP/2 最⼩单位，以⼆进制压缩格式存放 HTTP/1 中的内容（头部和包体）。

多个 Stream 跑在一条 TCP 连接，同一个 HTTP 请求与响应是跑在同一个 Stream 中，HTTP 消息可以由多个 Frame 构成， 一个 Frame 可以由多个 TCP 报文构成。

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

⽐如下图，服务端并⾏交错地发送了两个响应： Stream 1 和 Stream 3，这两个 Stream 都是跑在⼀个 TCP 连接上，客户端收到后，会根据相同的 Stream ID 有序组装成 HTTP 消息。

客户端和服务器双⽅都可以建⽴ Stream， Stream ID 也是有区别的，客户端建⽴的 Stream 必须是奇数号，⽽服务器建⽴的 Stream 必须是偶数号。

⽐如下图，Stream 1 是客户端向服务端请求的资源，属于客户端建⽴的 Stream，所以该 Stream 的ID 是奇数（数字 1）；Stream 2 和 4 都是服务端主动向客户端推送的资源，属于服务端建⽴的Stream，所以这两个 Stream 的 ID 是偶数（数字 2 和 4）。

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

在 Nginx 中，可以通过
http2_max_concurrent_Streams 配置来设置 Stream 的上限，默认是 128个。

HTTP/2 通过 Stream 实现的并发，⽐ HTTP/1.1 通过 TCP 连接实现并发要⽜逼的多，因为当HTTP/2 实现 100 个并发 Stream 时，只需要建⽴⼀次 TCP 连接，⽽ HTTP/1.1 需要建⽴ 100 个TCP 连接，每个 TCP 连接都要经过 TCP 握⼿、慢启动以及 TLS 握⼿过程，这些都是很耗时的。

HTTP/2 还可以对每个 Stream 设置不同优先级，帧头中的「标志位」可以设置优先级，⽐如客户端访问 HTML/CSS 和图⽚资源时，希望服务器先传递 HTML/CSS，再传图⽚，那么就可以通过设置Stream 的优先级来实现，以此提⾼⽤户体验。

4、服务器推送

HTTP/2 还在⼀定程度上改善了传统的「请求 – 应答」⼯作模式，服务端不再是被动地响应，可以主动向客户端发送消息。

比如，客户端通过 HTTP/1.1 请求从服务器那获取到了 HTML 文件，而 HTML 可能还需要依赖 CSS 来渲染页面，这时客户端还要再发起获取 CSS 文件的请求，需要两次消息往返，如下图左边部分：

如上图右边部分，在 HTTP/2 中，客户端在访问 HTML 时，服务器可以直接主动推送 CSS 文件，减少了消息传递的次数。

在 Nginx 中，如果你希望客户端访问 /test.html 时，服务器直接推送 /test.css，那么可以这么配置：

location /test.html { http2_push /test.css; }

服务器推送资源时，会先发送 PUSH_PROMISE 帧，告诉客户端接下来在哪个 Stream 发送资源，然后用偶数号 Stream 发送资源给客户端。

HTTP/2 有什么缺陷？

HTTP/2 通过 Stream 的并发能⼒，解决了 HTTP/1 队头阻塞的问题，看似很完美了，但是 HTTP/2还是存在“队头阻塞”的问题，只不过问题不是在 HTTP 这⼀层⾯，⽽是在 TCP 这⼀层。

HTTP/2 是基于 TCP 协议来传输数据的，TCP 是字节流协议，TCP 层必须保证收到的字节数据是完整且连续的，这样内核才会将缓冲区⾥的数据返回给 HTTP 应⽤，那么当「前 1 个字节数据」没有到达时，后收到的字节数据只能存放在内核缓冲区⾥，只有等到这 1 个字节数据到达时，HTTP/2 应⽤层才能从内核中拿到数据，这就是 HTTP/2 队头阻塞问题。

所以，一旦发生了丢包现象，就会触发 TCP 的重传机制，这样在一个 TCP 连接中的所有的 HTTP 请求都必须等待这个丢了的包被重传回来。

HTTP/3 做了哪些优化？

HTTP/2 队头阻塞的问题是因为 TCP，所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP！

UDP 发送是不管顺序，也不管丢包的，所以不会出现像 HTTP/2 队头阻塞的问题。⼤家都知道 UDP是不可靠传输的，但基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输。

QUIC 有以下 3 个特点。

• ⽆队头阻塞
• 更快的连接建⽴
• 连接迁移

1、⽆队头阻塞

QUIC 协议也有类似 HTTP/2 Stream 与多路复⽤的概念，也是可以在同⼀条连接上并发传输多个Stream，Stream 可以认为就是⼀条 HTTP 请求。

QUIC 有⾃⼰的⼀套机制可以保证传输的可靠性的。当某个流发⽣丢包时，只会阻塞这个流，其他流不会受到影响，因此不存在队头阻塞问题。这与 HTTP/2 不同，HTTP/2 只要某个流中的数据包丢失了，其他流也会因此受影响。

所以，QUIC 连接上的多个 Stream 之间并没有依赖，都是独⽴的，某个流发⽣丢包了，只会影响该流，其他流不受影响。

2、更快的连接建⽴

对于 HTTP/1 和 HTTP/2 协议，TCP 和 TLS 是分层的，分别属于内核实现的传输层、openssl 库实现的表示层，因此它们难以合并在⼀起，需要分批次来握⼿，先 TCP 握⼿，再 TLS 握⼿。

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

但是 HTTP/3 的 QUIC 协议并不是与 TLS 分层，⽽是 QUIC 内部包含了 TLS，它在⾃⼰的帧会携带TLS ⾥的“记录”，再加上 QUIC 使⽤的是 TLS/1.3，因此仅需 1 个 RTT 就可以「同时」完成建⽴连接与密钥协商，如下图：

3、连接迁移

基于 TCP 传输协议的 HTTP 协议，由于是通过四元组（源 IP、源端口、目的 IP、目的端口）确定一条 TCP 连接

那么当移动设备的⽹络从 4G 切换到 WIFI 时，意味着 IP 地址变化了，那么就必须要断开连接，然后重新建⽴连接。⽽建⽴连接的过程包含 TCP 三次握⼿和 TLS 四次握⼿的时延，以及 TCP 慢启动的减速过程，给⽤户的感觉就是⽹络突然卡顿了⼀下，因此连接的迁移成本是很⾼的。

⽽ QUIC 协议没有⽤四元组的⽅式来“绑定”连接，⽽是通过连接 ID 来标记通信的两个端点，客户端和服务器可以各⾃选择⼀组 ID 来标记⾃⼰，因此即使移动设备的⽹络变化后，导致 IP 地址变化了，只要仍保有上下⽂信息（⽐如连接 ID、TLS 密钥等），就可以“⽆缝”地复⽤原连接，消除重连的成本，没有丝毫卡顿感，达到了连接迁移的功能。

所以， QUIC 是⼀个在 UDP 之上的伪 TCP + TLS + HTTP/2 的多路复⽤的协议。

HTTP 与 HTTPS

HTTP 与 HTTPS 有哪些区别？

• HTTP 是超⽂本传输协议，信息是明⽂传输，存在安全⻛险的问题。HTTPS 则解决 HTTP 不安全的缺陷，在 TCP 和 HTTP ⽹络层之间加⼊了 SSL/TLS 安全协议，使得报⽂能够加密传输。
• HTTP 连接建⽴相对简单， TCP 三次握⼿之后便可进⾏ HTTP 的报⽂传输。⽽ HTTPS 在 TCP 三次握⼿之后，还需进⾏ SSL/TLS 的握⼿过程，才可进⼊加密报⽂传输。
• 两者的默认端⼝不⼀样，HTTP 默认端⼝号是 80，HTTPS 默认端⼝号是 443。
• HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。

HTTPS 解决的问题？

HTTP 由于是明⽂传输，所以安全上存在以下三个⻛险：

窃听⻛险，⽐如通信链路上可以获取通信内容，⽤户号容易没。

篡改⻛险，⽐如强制植⼊垃圾⼴告，视觉污染，⽤户眼容易瞎。

冒充⻛险，⽐如冒充淘宝⽹站，⽤户钱容易没。

HTTPS 在 HTTP 与 TCP 层之间加入了 SSL/TLS 协议，可以很好的解决了上述的风险：

信息加密：交互信息无法被窃取，但你的号会因为「自身忘记」账号而没。

校验机制：无法篡改通信内容，篡改了就不能正常显示，但百度「竞价排名」依然可以搜索垃圾广告。

身份证书：证明淘宝是真的淘宝网，但你的钱还是会因为「剁手」而没。

HTTPS 是如何解决上面的三个风险的？

混合加密的方式实现信息的机密性，解决了窃听的风险。

摘要算法的方式来实现完整性，它能够为数据生成独一无二的「指纹」，指纹用于校验数据的完整性，解决了篡改的风险。

将服务器公钥放入到数字证书中，解决了冒充的风险

1. 混合加密

通过混合加密的方式可以保证信息的机密性，解决了窃听的风险。

HTTPS 采⽤的是对称加密和⾮对称加密结合的「混合加密」⽅式：

• 在通信建⽴前采⽤⾮对称加密的⽅式交换「会话秘钥」，后续就不再使⽤⾮对称加密。
• 在通信过程中全部使⽤对称加密的「会话秘钥」的⽅式加密明⽂数据。

采⽤「混合加密」的⽅式的原因：

• 对称加密只使⽤⼀个密钥，运算速度快，密钥必须保密，⽆法做到安全的密钥交换。
• ⾮对称加密使⽤两个密钥：公钥和私钥，公钥可以任意分发⽽私钥保密，解决了密钥交换问题但速度慢。

2. 摘要算法 + 数字签名

为了保证传输的内容不被篡改，我们需要对内容计算出⼀个「指纹」，然后同内容⼀起传输给对⽅。

对⽅收到后，先是对内容也计算出⼀个「指纹」，然后跟发送⽅发送的「指纹」做⼀个⽐较，如果「指纹」相同，说明内容没有被篡改，否则就可以判断出内容被篡改了。

那么，在计算机⾥会⽤摘要算法（哈希函数）来计算出内容的哈希值，也就是内容的「指纹」，这个哈希值是唯⼀的，且⽆法通过哈希值推导出内容。

通过哈希算法可以确保内容不会被篡改，但是并不能保证「内容 + 哈希值」不会被中间人替换，因为这里缺少对客户端收到的消息是否来源于服务端的证明。

那为了避免这种情况，计算机⾥会⽤⾮对称加密算法来解决，共有两个密钥：

• ⼀个是公钥，这个是可以公开给所有⼈的；
• ⼀个是私钥，这个必须由本⼈管理，不可泄露。

这两个密钥可以双向加解密的，⽐如可以⽤公钥加密内容，然后⽤私钥解密，也可以⽤私钥加密内容，公钥解密内容。

流程的不同，意味着⽬的也不相同：

• 公钥加密，私钥解密。这个⽬的是为了保证内容传输的安全，因为被公钥加密的内容，其他⼈是⽆法解密的，只有持有私钥的⼈，才能解密出实际的内容；
• 私钥加密，公钥解密。这个⽬的是为了保证消息不会被冒充，因为私钥是不可泄露的，如果公钥能正常解密出私钥加密的内容，就能证明这个消息是来源于持有私钥身份的⼈发送的。

⼀般我们不会⽤⾮对称加密来加密实际的传输内容，因为⾮对称加密的计算⽐较耗费性能的。

所以⾮对称加密的⽤途主要在于通过「私钥加密，公钥解密」的⽅式，来确认消息的身份，我们常说的数字签名算法，就是⽤的是这种⽅式，不过私钥加密内容不是内容本身，⽽是对内容的哈希值加密。

私钥是由服务端保管，然后服务端会向客户端颁发对应的公钥。如果客户端收到的信息，能被公钥解密，就说明该消息是由服务器发送的。

3. 数字证书

前⾯我们知道：

• 可以通过哈希算法来保证消息的完整性；
• 可以通过数字签名来保证消息的来源可靠性（能确认消息是由持有私钥的⼀⽅发送的）；

但是这还远远不够，还缺少身份验证的环节，万⼀公钥是被伪造的呢？

CA （数字证书认证机构），将服务器公钥放在数字证书（由数字证书认证机构颁发）中，只要证书是可信的，公钥就是可信的

HTTPS 建立连接

SSL/TLS 协议基本流程：

• 客户端向服务器索要并验证服务器的公钥。
• 双⽅协商⽣产「会话秘钥」。
• 双⽅采⽤「会话秘钥」进⾏加密通信。

前两步也就是 SSL/TLS 的建⽴过程，也就是 TLS 握⼿阶段。

TLS 的「握⼿阶段」涉及四次通信，使⽤不同的密钥交换算法，TLS 握⼿流程也会不⼀样的，现在常⽤的密钥交换算法有两种：RSA 算法 和 ECDHE 算法 。

基于 RSA 算法的 TLS 握⼿过程⽐较容易理解，所以这⾥先⽤这个给⼤家展示 TLS 握⼿过程，如下图：

TLS 协议建⽴的详细流程：

1. ClientHello

⾸先，由客户端向服务器发起加密通信请求，也就是 ClientHello 请求。在这⼀步，客户端主要向服务器发送以下信息：

（1）客户端⽀持的 TLS 协议版本，如 TLS 1.2 版本。

（2）客户端⽣产的随机数（ Client Random ），后⾯⽤于⽣成「会话秘钥」条件之⼀。

（3）客户端⽀持的密码套件列表，如 RSA 加密算法。

2. SeverHello

服务器收到客户端请求后，向客户端发出响应，也就是 SeverHello 。服务器回应的内容有如下内容：

（1）确认 TLS 协议版本，如果浏览器不⽀持，则关闭加密通信。

（2）服务器⽣产的随机数（ Server Random ），也是后⾯⽤于⽣产「会话秘钥」条件之⼀。

（3）确认的密码套件列表，如 RSA 加密算法。

（4）服务器的数字证书。

3.客户端回应

客户端收到服务器的回应之后，⾸先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性。

如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使⽤它加密报⽂，向服务器发送如下信息：

（1）⼀个随机数（ pre-master key ）。该随机数会被服务器公钥加密。

（2）加密通信算法改变通知，表示随后的信息都将⽤「会话秘钥」加密通信。

（3）客户端握⼿结束通知，表示客户端的握⼿阶段已经结束。这⼀项同时把之前所有内容的发⽣的数据做个摘要，⽤来供服务端校验。上⾯第⼀项的随机数是整个握⼿阶段的第三个随机数，会发给服务端，所以这个随机数客户端和服务端都是⼀样的。

服务器和客户端有了这三个随机数（Client Random、Server Random、pre-master key），接着就⽤双⽅协商的加密算法，各⾃⽣成本次通信的「会话秘钥」。

4. 服务器的最后回应

服务器收到客户端的第三个随机数（ pre-master key ）之后，通过协商的加密算法，计算出本次通信的「会话秘钥」。

然后，向客户端发送最后的信息：

（1）加密通信算法改变通知，表示随后的信息都将⽤「会话秘钥」加密通信。

（2）服务器握⼿结束通知，表示服务器的握⼿阶段已经结束。这⼀项同时把之前所有内容的发⽣的数据做个摘要，⽤来供客户端校验。⾄此，整个 TLS 的握⼿阶段全部结束。接下来，客户端与服务器进⼊加密通信，就完全是使⽤普通的 HTTP 协议，只不过⽤「会话秘钥」加密内容。

客户端校验数字证书的流程

CA 签发证书的过程，如上图左边部分：

• ⾸先 CA 会把持有者的公钥、⽤途、颁发者、有效时间等信息打成⼀个包，然后对这些信息进⾏Hash 计算，得到⼀个 Hash 值；
• 然后 CA 会使⽤⾃⼰的私钥将该 Hash 值加密，⽣成 Certificate Signature，也就是 CA 对证书做了签名；
• 最后将 Certificate Signature 添加在⽂件证书上，形成数字证书；

客户端校验服务端的数字证书的过程，如上图右边部分：

• ⾸先客户端会使⽤同样的 Hash 算法获取该证书的 Hash 值 H1；
• 通常浏览器和操作系统中集成了 CA 的公钥信息，浏览器收到证书后可以使⽤ CA 的公钥解密Certificate Signature 内容，得到⼀个 Hash 值 H2 ；
• 最后⽐较 H1 和 H2，如果值相同，则为可信赖的证书，否则则认为证书不可信。