探寻HTTP革新 — 为什么HTTP/3是未来的前沿？

最近，公司在面试新的小伙伴时，其中有一道面试题就是关于"HTTP"的，这是一个表面上看似简单但实际上颇具挑战性的问题："你对 HTTP 协议了解多少？能不能把你知道的都详细说一下？"

问题虽简单，但其实主打一个看你知道多少、掌握多少！而且由于 HTTP 的知识点很多，很多内容反复记忆，但过后还是会忘掉。导致面试时有印象，但就是说不上来。于是我写了这篇文章，可以更好的理解和消化。

这篇文章将从 HTTP/3 出发，探讨它在成为未来前沿技术的过程中，解决了存在的哪些问题，以及带来了哪些创新。为了加深记忆，我们将沿着 HTTP 的发展历史，逐一分析关键版本及其面临的技术挑战。

文章的篇幅可能较长，借助目录效果更好，大家可以先收藏起来~~

HTTP/1.0 到 HTTP/1.1：性能瓶颈的挑战

HTTP/1.0 是最初的 HTTP 协议版本，其工作原理是建立连接、发送请求、接收响应。然而，每次请求和响应都需要建立一个新的连接，这导致了较高的连接建立和关闭开销，影响了整体响应速度。

HTTP/1.1 的改进和引入的特性

为了克服 HTTP/1.0 的性能瓶颈，HTTP/1.1 引入了以下关键特性：

持久连接（Persistent Connections）： 允许在单个连接上传输多个请求和响应，不用每个请求都重新建立连接。这有效地降低了连接建立和关闭的开销，提高了性能。
管道化（Pipeline）： 允许在一个连接上同时发送多个请求，减少延迟。这有助于减少延迟，更充分地利用网络带宽。
引入 Host 头字段： 使服务器可以为多个域名提供服务，提高资源复用性。这对虚拟主机和共享主机的支持非常重要，提高了网络资源的复用性。
缓存控制： 引入了缓存控制机制，包括 Cache-Control 头字段。
Range 头字段： 引入了 Range 头字段，允许客户端请求资源的部分内容。这对于支持断点续传和部分内容传输非常重要。
新增状态码： 如201 Created、202 Accepted等，丰富了通信状态的表示。

HTTP/1.1 中仍然存在的性能瓶颈

尽管 HTTP/1.1 在多个方面对 HTTP/1.0 进行了改进，但随着网络资源的增长， HTTP/1.1 逐渐显露出无法满足现代需求的瓶颈。特别是在一些对性能要求较高的应用场景（例如聊天、视频直播）。

头部阻塞： HTTP/1.1 使用管道化来同时发送多个请求，但由于头部信息的传输是有序的，如果前面的请求出现延迟，会导致后续请求被阻塞，称为头部阻塞问题。
无状态： 大量头部字段（如User Agent、Cookie、Accept、Server等，多达几百字节甚至几千字节）增加了传输成本，而实际的请求体 Body 数据相对较少（仅几十字节），造成不必要的开销。
明文传输： 数据以明文方式传输，客户端与服务端无法进行有效验证，存在安全性隐患。
不支持服务器推送： 需要客户端主动发起请求才能获取资源，而不能由服务器主动向客户端推送资源。这导致了一些额外的往返时间，降低了性能。

总之，HTTP/1.1 也不是完美的，还存在许多问题（主要体现在性能不高和安全不足）！但是大家请记住，HTTP/1.1 从1997 年发布以来，我们使用了很长时间，它真正被逐渐弃用的原因是：互联网从网页文本，过渡到富媒体（图片、声音、视屏等），无法满足高性能互联网的发展。然后出现了 HTTP/2。

HTTP/2 的创新：解决 HTTP/1.1 中的问题

为了应对 HTTP/1.1 中的这些问题，Google 在 2015 年引入了名为 SPDY（发音为 "speedy"）的协议，作为 HTTP/2 的基础。

HTTP/2 在 SPDY 的基础上进行了标准化，继续改进和优化了协议。其主要目标是通过引入二进制协议 、多路复用 、头部压缩 、服务器推送等特性，从而提高页面加载速度、减少延迟。下面我们就来详细说一下：

1、二进制分帧传输

HTTP/2 引入了二进制分帧传输，这一特性在数据传输 和头部压缩 方面有着显著的优势（相较于 HTTP/1.1 的纯文本形式的报文，HTTP/2 采用了二进制传输，并将请求和响应数据分割成更小的帧）。

每个 HTTP/2 帧都有特定的目的，比如"HEADERS"帧用于存放头部数据，"DATA"帧则存放实体数据。这种分帧的方式使得"Header+Body"的报文结构完全消失，协议中只看到一个个的数据帧，这有助于减少传输的数据量。

此外连接传输时，同域名下的所有通信都在单个连接上完成，而这个连接可以同时承载任意数量的双向数据流 。每个数据流都以消息的形式发送，消息又由一个或多个帧组成。这种设计允许多个帧之间乱序发送 ，并通过帧首部的流标识重新组装，提高了性能和灵活性。

整体上来看，二进制分帧传输使得 HTTP/2 在处理并发请求和优化数据传输方面具有显著的优势。

2、头部压缩

HTTP/2 引入了HPACK算法，以提高头部信息的传输效率。该算法在客户端和服务器端维护字典，使用索引号标识重复字符串，并运用哈夫曼编码压缩整数和字符串，从而实现了卓越的 50% ～ 90% 高压缩率。

在具体实现中，客户端和服务器端使用首部表来追踪和存储之前传输的键-值对。这个首部表在 HTTP/2 连接的生命周期内一直存在，由客户端和服务器双方逐步更新。每当有新的首部键-值对出现时，它要么被添加到当前表的末尾，要么替换表中之前的对应值。

通过这种方式，HTTP/2 避免了对相同数据的重复传输，进一步提高了通信的效率。

3、多路复用

HTTP/2 还引入了多路复用技术，有效解决了传统 HTTP/1.1 中浏览器对同一域名下并发连接数的限制问题。这项技术允许在同一连接上同时处理多个双向数据流，极大地提高了并行性和传输效率。以下是一些关键特点：

解决并发请求限制： HTTP/2 允许同一域名下的所有通信在单个连接上完成，摆脱了 HTTP/1.1 中浏览器对并发连接数的限制。这意味着多个请求和响应可以同时进行，不再受到连接数的瓶颈。
全速传输： 通过在一个 TCP 连接上承载所有请求和响应，HTTP/2 实现了全速传输。避免了多个连接之间的竞争和排队，最大程度地充分利用了连接资源，提高了数据传输的效率。
帧的分割与消息组装： HTTP/2 将请求和响应数据分割为更小的帧，采用二进制传输。每个数据流都以消息的形式发送，由一个或多个帧组成。这种分帧的方式使得多个帧之间可以乱序发送，根据帧首部的流标识可以重新组装，从而提高了性能和灵活性。
优先级和流的控制： HTTP/2 引入了流的优先级概念，允许每个请求带有一个优先级值。这使得客户端和服务器可以在处理不同流时采取不同的策略，以最优的方式发送流、消息和帧，进一步优化通信过程。

在 HTTP/2 中，每个请求都可以带一个 31bit 的优先值，0表示最高优先级，数值越大优先级越低。有了这个优先值，客户端和服务器就可以在处理不同的流时采取不同的策略，以最优的方式发送流、消息和帧。

4、服务端推送（Server Push）

HTTP/2 引入了服务器推送功能，这项创新允许服务器在不等待客户端请求的情况下主动向客户端推送资源 ，显著减少了通信时间，提高用户体验。这一特性充分利用了管道化连接 和多路复用的优势，使得服务器能够同时向客户端推送多个资源，从而提高网页的响应速度和加载性能。

这种推送机制改变了传统的"请求-应答"工作模式，使得服务器不再完全被动地响应请求，而可以主动创建"流"并向客户端发送消息。

5、提高安全性

为了提高安全性，HTTP/2 的设计考虑到了兼容性，并延续了 HTTP/1 的"明文"特点，即可以选择以明文传输数据。虽然 HTTP/2 的数据格式是二进制的，但在明文传输时仍然不强制使用加密通信，使其与 HTTP/1 保持一致。

然而，由于互联网安全的日益重要，HTTPS 已经成为趋势。主流的浏览器如 Chrome、Firefox 等明确宣布只支持加密的 HTTP/2。因此，实际上，互联网上通常见到的 HTTP/2 都是通过 HTTPS 协议传输，运行在 TLS 协议上。

HTTP/2 协议定义了两个字符串标识符来区分明文和加密：

1、"h2"，表示加密的 HTTP/2；

2、"h2c"，表示明文的 HTTP/2。

这种设计在实践中鼓励了更广泛的加密使用，提高了通信的安全性。因此，尽管 HTTP/2 本身允许明文传输，但实际上，为了最大程度地提高安全性，推荐使用加密的 HTTP/2，即通过 HTTPS 传输。

HTTP 与 HTTPS 的区别

既然说到了 HTTPS，那么我们这里简单了解下 HTTP 与 HTTPS 的区别。

HTTPS 由两部分组成：HTTP + SSL/ TLS，也就是在HTTP上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过TLS（SSL已弃用，TLS是SSL的后续版本）进行加密，所以传输的数据都是加密后的数据。

特性	HTTP	HTTPS
加密	无加密	通过TLS/SSL协议加密传输数据
安全性	不安全，数据传输为明文	安全
协议端口	默认端口80	默认端口443
证书	不需要	需要SSL证书，由受信任的CA颁发
搜索引擎排名	不利于SEO	有利于SEO，搜索引擎通常更青睐使用HTTPS的网站
性能	通常略快	略慢，因为加密和解密过程会增加一些计算开销

TLS/SSL 是用于加密通信的协议，有两种加密方式：

对称加密： 客户端和服务端在握手过程中，会生成的随机密钥，而后结合一些其他信息，生成一个共享密钥。这个共享密钥用于加密和解密实际的数据传输，这个过程被称为对称加密算法（常见的对称加密算法包括AES）。
非对称加密： 在握手阶段，服务器会发送一个数字证书，其中包含了服务器的公钥。客户端使用服务器的公钥加密生成随机密钥，并发送给服务器。服务器再使用自己的私钥，解密客户端发送的随机密钥。这个过程被称为非对称加密算法。

注意：数字证书中包含了服务器的公钥和由证书颁发机构CA 签名的证书信息。而客户端可以通过CA的公钥验证证书的合法性，确保连接的安全性。

HTTP/2 出现的问题：队头阻塞

why，HTTP/2 怎么也还有问题？？？

在 HTTP/2 中，尽管引入了多路复用，显著提升了并行请求和响应的效率，但却带来了一个新的问题 ，即队头阻塞。队头阻塞是指在一个连接中，由于某个请求或响应的延迟，导致后续的请求或响应被阻塞的现象。

HTTP/2 中队头阻塞

多路复用的机制使得同时发送多个请求和接收多个响应成为可能，极大地加速了数据的传输。然而，这也引发了一个问题，即如果其中一个请求或响应遇到延迟，后续的请求和响应都将被阻塞。

这是因为，TCP 虽然能保证数据的可靠传输，但是当在 HTTP/2 传输中的某个数据包丢失时，TCP 协议要求等待该数据包被重新传输完成，这将导致整个连接中的其他请求和响应也受到影响（即使它们并不直接依赖于丢失的数据包）。

那么就会有伙伴问，HTTP/1.x 就没有这个问题吗？

还别说，HTTP/1.x 还真没有"队头阻塞"这个问题。HTTP/1.1 可以开启多个 TCP ，出现这个丢包问题时，只会影响其中的一个链接，其余的 TCP 连接还能正常传输数据。

HTTP/2 有没有可能的解决方案和讨论？

我们可以从流的优先级入手，HTTP/2 引入了流的优先级概念，允许为每个流设置权重，以决定其相对于其他流的优先级。首先来说利用流的优先级来看是有帮助的，但并未完全解决队头阻塞问题，因为优先级仍然受到整个连接的限制。

也可以采取分离连接的方式，一些解决方案尝试通过使用不同的连接来绕过队头阻塞。尽管这在某些场景下可行，但也增加了连接的数量和复杂性。

以上两种解决方式都不彻底，相比之下 HTTP3 却彻底的解决了队头阻塞问题。

HTTP/3 与 QUIC：未来的前沿

为了解决 HTTP/2 的缺陷，Google 推出了基于 UDP 协议的 QUIC 协议，通过在 UDP (弃用 TCP)上建立连接，使用多个独立的数据流来实现更好的并行传输。这使得队头阻塞问题得以解决，因为一个数据流的阻塞不会影响其他数据流的传输。

由此 HTTP/3 诞生了，它在 HTTP/2 的基础上实现了质的飞跃，特别是彻底解决了队头阻塞问题。

QUIC 作为 HTTP/3 的基础

QUIC 基于 UDP，而 UDP 是"无连接"的，根本就不需要"握手"和"挥手"，所以本身就比 TCP 响应快 。此外，HTTP/3 还引入了 类似 HTTP/2 的 "流"和"多路复用"。

QUIC 的设计初衷主要是解决传统 TCP 协议所面临的一些瓶颈和问题，如下：

连接建立延迟： QUIC 通过实现快速握手机制，大大降低了连接建立的时间，使通信能够更迅速地开始。
队头阻塞： QUIC 重新引入了多路复用的概念，允许同时传输多个数据流，从而避免了在 HTTP/2 中存在的队头阻塞问题。

我们具体说说快速握手机制，尤其是 QUIC 相比 TCP 在这块的本质区别？

与 TCP 连接的本质相比，HTTP/3 使用 QUIC 协议，这是一种基于 UDP 的协议，旨在提供更快、更灵活的连接。QUIC 使用 TLS 1.3 进行加密和身份验证，并支持 0-RTT 和 1-RTT 连接建立方式（RTT指往返时间，即数据包从源发送到目标，然后再从目标返回到源所需的总时间）。

0-RTT，客户端可以使用之前连接中缓存的会话密钥来加密和发送数据，而不需要等待服务器的确认（这意味着客户端可以在第一次连接时立即开始发送数据）。
1-RTT，客户端和服务器需要进行一次往返的 TLS 握手过程来协商和确认会话密钥。这种方式比 0-RTT 更安全，因为它可以防止某些类型的中间人攻击。但是，与 TCP 连接相比，1-RTT连接仍然具有更快的连接建立速度，

因为 TCP 连接则是一种基于字节流的连接，需要进行一个复杂的三向握手过程，确保双方都已准备好进行数据传输。这个过程至少需要三次往返时间（3-RTT），因此在高延迟的网络环境中，TCP连接的建立可能会比较慢。

HTTP/3 新特性

HTTP/3 基于 QUIC 协议，带来了流量控制、快速握手、TLS加密等以下新特性：

流量控制和传输可靠性：QUIC 实现了类似 TCP 的流量控制和传输可靠性的功能，即使在 UDP 的基础上，仍然提供了数据包重传、拥塞控制等特性。
快速握手：基于 UDP 的 QUIC 允许使用 0-RTT 或 1-RTT 来建立连接，极大地提高了握手速度。0-RTT（零轮询时间）建连是 QUIC 相对于 HTTP/2 最显著的性能优势。
TLS 加密集成：QUIC 集成了 TLS 加密，采用 TLS 1.3 版本，减少了握手所花费的 RTT 个数。
多路复用解决队头阻塞 ：与 TCP 不同，QUIC 允许在同一物理连接上存在多个独立的逻辑数据流，彻底解决了 TCP 中的队头阻塞问题。。

这4个特性，显著提升了整体的网络性能。这对于提升用户体验、降低跳失率等方面有着积极的影响。比如说，在加载大量资源时的性能，HTTP/3 在整体性能上表现更为优越，特别是在高延迟和高负载的网络情况下。

为什么HTTP/3是未来的前沿？

1、更快的加载速度

并发传输：HTTP/3 通过 QUIC 协议实现了真正的并发传输，这意味着多个请求可以在同一个连接上同时进行，没有了 HTTP/2 中的流依赖问题。这大大提高了网页加载速度，特别是当网页包含多个资源时。
减少延迟：由于 QUIC 使用了 UDP 而非 TCP，它避免了 TCP 中的一些复杂机制（如慢启动、拥塞避免等），从而减少了传输延迟。

2、流量控制

动态调整数据传输速率：HTTP/3 提供了流量控制机制，允许发送方和接收方根据网络状况动态调整数据传输的速率。这有助于防止网络拥塞，提高数据传输的稳定性。

3、更低的延迟

0-RTT 握手：通过缓存先前的连接信息，HTTP/3 支持 0-RTT 握手，这意味着客户端可以在不等待服务器响应的情况下立即发送数据。这对于实时应用（如在线游戏、视频会议等）尤为重要，因为它们对延迟非常敏感。

4、提高网络效率

数据包重传和拥塞控制：HTTP/3 引入了更高效的数据包重传机制和拥塞控制算法。这些机制能够更准确地检测网络状况，并在数据包丢失或网络拥塞时做出快速响应，从而提高了数据传输的可靠性。

综上所述，HTTP/3 通过引入 QUIC 协议和 TLS 1.3 加密技术，显著提高了网页加载速度、降低了延迟、并提高了网络效率。这些优势使得 HTTP/3 成为未来互联网通信的重要协议之一。

总结

从 HTTP 问世以来，HTTP 的演进一直在努力解决性能瓶颈和安全问题：

从 HTTP/1.0 到 HTTP/1.1： 初始版本，每个请求需要新连接，性能受限。HTTP/1.1 引入持久连接和管道化，减少延迟，增加 Host 头字段，支持多网站托管。
HTTP/2 的创新： 针对 HTTP/1.1 中的问题，HTTP/2提出了多路复用、头部压缩、二进制协议等新特性，显著提高性能。但在面临丢包时，仍存在队头阻塞问题。
HTTP/3 与 QUIC 的崭新时代： 基于 QUIC 协议，彻底解决了HTTP/2 中的队头阻塞问题，提供更快加载速度和更高可靠性。

希望这篇文章对你有所帮助！！！内容可能还有所欠缺，欢迎在评论区，一起讨论。