HTTP 协议的的进化史：HTTP/1、HTTP/2、HTTP/3
HTTP 协议的的进化史：HTTP/1、HTTP/2、HTTP/3
接下来将对HTTP协议的发展脉络进行梳理。
HTTP/0.9——单行协议
HTTP/0.9是HTTP协议的最早版本，于1991年由万维网协会和互联网工程任务组制定。这个版本非常简单，主要用于学术交流，主要用于在网络之间传输HTML超文本的内容，因此也被称为超文本协议。
请求：
GET /index.html响应：
<html>
Welcome to the example.re homepage!
</html>
HTTP/0.9的特点包括：
1、只支持GET方法请求：请求由单行指令构成，以唯一可用方法 GET 开头，其后跟目标资源的路径（一旦连接到服务器，协议、服务器、端口号这些都不是必须的）
2、无请求头和状态码：HTTP/0.9没有定义请求头和状态码，也没有明确的版本号，只是后来为了与其他版本区分才被定义成0.9。
3、纯文本内容：这个版本只支持纯文本内容的传输，并且支持用HTML语言格式化，但无法插入图片或其他类型的内容。
这意味着只有 HTML 文件可以传送，无法传输其他类型的文件。
4、不支持持久连接：HTTP/0.9的每个事务都是独立的，每个请求都需要经历TCP三次握手建立连接，请求处理完成后，连接就会释放，即不支持持久连接。
这样的协议有两个问题：
（1）性能问题。
对于每个资源文件（htlm，html中的JS、CSS、img等资源）都建立一个新的TCP连接，不仅耗时，还消耗系统资源，特别是在资源文件数量众多时，这种影响更为明显。每来一个请求就开一个TCP连接是非常耗时的。虽然可以同时开多个连接，并发地发送请求，但连接数毕竟是有限的。
（2）服务器推送问题。
5、不支持分块传输：HTTP/0.9不支持分块传输，这是一种用于将大量数据以小块形式发送的机制。
6、有限的错误处理：HTTP/0.9的错误处理能力有限，无法在响应中指示错误。即没有状态码或错误代码。一旦出现问题，一个特殊的包含问题描述信息的 HTML 文件将被发回，供人们查看。
HTTP/1.0——构建可扩展性
由于 HTTP/0.9 协议的应用十分有限，浏览器和服务器迅速扩展内容使其用途更广，根据RFC 1945，HTTP/1.0版本引入了几个重要的特性：
1、支持多种请求方法：HTTP/1.0支持多种请求方法，包括GET、POST和HEAD。
2、头部（Headers）：HTTP/1.0引入了头部概念，这使得客户端和服务器之间的通信更为复杂和灵活。请求头部可以包含诸如Accept字段，用于告诉服务端可以接收的文件类型；响应头部可以包含Content-Type字段，来告诉浏览器返回文件的类型。头部字段不仅用于解决不同类型文件传输的问题，也可以实现其他很多功能，如缓存、认证信息等。
3、状态码（Status Codes）：HTTP/1.0引入了状态码的使用，允许进行更复杂的错误处理和报告。常见的状态码包括200（成功）、404（未找到）和500（服务器内部错误）等。
4、持久连接（Persistent Connections）：HTTP/1.0支持持久连接，允许在一个TCP连接上发送多个请求和响应，减少了连接建立和关闭的开销，从而提高了性能。需要注意的是，虽然HTTP/1.0标准中引入了持久连接的概念，但它是默认关闭的，需要通过在响应头中包含Connection: keep-alive来显式启用。
5、内容协商（Content Negotiation）：HTTP/1.0引入了内容协商的概念，允许客户端请求特定格式和语言的内容。
6、改进的缓存机制：HTTP/1.0引入了改进的缓存机制，使得资源缓存更为有效和高效。
7、HTTP请求由三部分组成：请求行、头部和正文。请求行包含关于请求资源的信息，如其URL。头部包含关于请求或响应的附加信息，如内容类型或语言。最后，正文包含需要与请求或响应一起发送的数据。
9、支持携带http协议版本：协议版本信息现在会随着每个请求发送（HTTP/1.0 被追加到了 GET 行）。
HTTP/1.1——标准化的协议
HTTP/1.0 多种不同的实现方式在实际运用中显得有些混乱。自 1995 年开始，即 HTTP/1.0 文档发布的下一年，就开始修订 HTTP 的第一个标准化版本。在 1997 年初，HTTP1.1 标准发布，就在 HTTP/1.0 发布的几个月后。
HTTP/1.1 消除了大量歧义内容并引入了多项改进：
1、默认持久连接：在同一个连接上可以发送多个请求和响应，无需为每个请求重新建立连接。这显著提高了网络利用率，并减少了因频繁建立连接而产生的开销，节省了多次打开 TCP 连接加载网页文档资源的时间。HTTP/1.0 仍提供了长连接选项，即在请求头中加入Connection: Keep-alive。同样的，在 HTTP/1.1 中，如果不希望使用长连接选项，也可以在请求头中加入Connection: close，这样会通知服务器端关闭连接。
2、引入管道化（Pipeline）机制：允许在一个持久连接上同时发送多个请求。这进一步提高了通信效率，需要注意的是，服务器必须按照客户端请求的先后顺序依次回送相应的结果，即Pipeline 有个致命问题，就是Head-of-Line Blocking翻译成中文叫作“队头阻塞”。也正因为如此，为了避免Pipeline带来的副作用，很多浏览器默认把Pipeline关闭了。
3、支持响应分块：HTTP/1.1 引入了范围请求（range request）机制，以避免带宽的浪费。当客户端想请求一个文件的一部分，或者需要继续下载一个已经下载了部分但被终止的文件，HTTP/1.1 可以在请求中加入Range头部，以请求（并只能请求字节型数据）数据的一部分。服务器端可以忽略Range头部，也可以返回若干Range响应。
如果一个响应包含部分数据的话，那么将带有206 (Partial Content)状态码。该状态码的意义在于避免了 HTTP/1.0 代理缓存错误地把该响应认为是一个完整的数据响应，从而把他当作为一个请求的响应缓存。
在范围响应中，Content-Range头部标志指示出了该数据块的偏移量和数据块的长度。
HTTP 1.1的这种特性只适用于断点下载。要实现断点上传，就需要自行实现了。
4、引入额外的缓存控制机制：HTTP/1.1 的缓存机制在 HTTP/1.0 的基础上，大大增加了灵活性和扩展性。基本工作原理和 HTTP/1.0 保持不变，而是增加了更多细致的特性。
5、引入内容协商机制，包括语言、编码、类型等。并允许客户端和服务器之间约定以最合适的内容进行交换。
6、Host头处理：凭借 Host 头，能够使不同域名配置在同一个 IP 地址的服务器上。
7、大量增加状态码：HTTP/1.0 仅定义了 16 种状态码。HTTP/1.1 中新加入了大量的状态码，光是错误响应状态码就新增了 24 种。
HTTP/2——为了更优异的表现
HTTP是一种请求-响应协议（等待响应会阻塞发送，导致在当前请求完成之前，无法发送另一个请求），在面临Pipeline不可用和浏览器对同一域名连接数限制（对于同一个域名，浏览器限制只能开6～8个连接。但一个网页可能要发几十个HTTP请求，却只有6～8 个连接可用，所以可通过多域名打破这种限制）的情况下，提高网页渲染性能和并发度是一个挑战。
随着时间的推移，已经有各种突破HTTP/1.1的性能限制的技术，这些技术分为以下两类：
（1）使用多个HTTP连接。
打开多个连接是解决HTTP/1.1阻塞问题的最简单方法，这样可以同时开启多个HTTP请求。另外，与管道化技术不同，该技术不会导致HOL阻塞，因为每个HTTP连接都独立于其他HTTP连接。因此，大多数浏览器可以为每个域名打开6个连接。为了进一步突破6个连接的限制，可以使用多个域名，每个域名负责一部分连接。
使用多个HTTP连接听起来不错，但它也有缺点。当开启多个HTTP连接时，客户端和服务器都有额外的开销：打开TCP连接需要时间，维护连接需要更多的内存和CPU资源。
（2）合并HTTP请求。
为此，在 2010 年早期，谷歌通过实践了一个实验性的 SPDY 协议。这种在客户端和服务器端交换数据的替代方案引起了在浏览器和服务器上工作的开发人员的兴趣。明确了响应数量的增加和解决复杂的数据传输，SPDY 成为了 HTTP/2 协议的基础。
新版本的协议与原来的协议有很大的不同，新增了如下功能：
1、二进制传输：使用二进制格式替换文本格式
HTTP/1和HTTP/2的主要区别之一是，HTTP/2是一个二进制的、基于数据包的协议，而HTTP/1是完全基于文本的。使用基于文本的协议，要先发完请求，并接收完响应之后，才能开始下一个请求。HTTP/2变成了一个完全的二进制协议，HTTP消息被分成清晰定义的数据帧发送。所有的HTTP/2消息都使用分块的编码技术，这是标准行为，不需要显式地设置。这里的帧和支撑HTTP连接的TCP数据包类似。当收到所有的数据帧后，可以将它们组合为完整的HTTP消息。
2、多路复用代替同步请求
HTTP/1是一种同步的、独占的请求-响应协议。客户端发送HTTP/1消息，然后服务器返回HTTP/1响应。
HTTP/2允许在单个连接上同时执行多个请求，每个HTTP请求或响应使用不同的流。通过使用二进制分帧层，给每个帧分配一个流标识符，以支持同时发出多个独立请求。当接收到该流的所有帧时，接收方可以将帧组合成完整消息。帧是同时发送多个消息的关键。每个帧都有标签表明它属于哪个消息（流），这样在一个连接上就可以同时有两个、三个甚至上百个消息。不像在HTTP/1中，大多数浏览器只能并发6个请求。
为了防止流ID冲突，客户端发起的请求使用奇数流ID，服务器发起的请求使用偶数流ID。
3、流的优先级和流量控制
4、 首部压缩
5、服务端推送
6、与HTTP/1.1兼容
HTTP/2虽然带来了许多性能上的提升，但它也有一些缺点： 1、 丢包场景下的性能下降：HTTP/2使用多路复用，通常同一域名下只需要一个TCP连接。但当这个连接中出现了丢包的情况，会导致整个TCP连接都要开始等待重传，从而影响后面的所有数据传输，使得HTTP/2的表现情况反倒不如HTTP/1。 2、 对服务器配置的要求较高：为了充分利用HTTP/2的性能优势，服务器需要进行相应的配置和优化，这可能会增加服务器的复杂性和维护成本。
HTTP/3——基于 QUIC 的 HTTP
HTTP/3（超文本传输协议第3版）是HTTP协议的第三个版本，旨在解决HTTP/2中存在的问题并进一步提高网络传输性能。HTTP/3的主要特点是使用QUIC协议替代了传统的TCP协议。QUIC（Quick UDP Internet Connections）是一种基于UDP（用户数据报协议）的传输协议。
HTTP/3的主要优势如下：
- 减少连接延迟：由于QUIC是基于UDP的，因此在建立连接时不需要进行TCP的三次握手，从而减少了连接延迟。
- 改进拥塞控制：QUIC采用了独立的拥塞控制算法，可以根据网络状况动态调整传输速度，避免拥塞和数据丢失。
- 消除队头阻塞：在HTTP/2中，多路复用可能导致队头阻塞问题，即一个请求的延迟影响其他请求的处理。QUIC通过将每个请求封装在独立的流中，消除了这个问题。
- 前向纠错（FEC）：QUIC支持前向纠错技术，可以在数据传输过程中检测和修复错误，提高数据传输的可靠性。
- 更好的安全性：QUIC内置了TLS 1.3加密，提供了比HTTP/2更强的安全性。
参考：1、https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP
2、HTTP/2 in Action
3、https://robotecture.com/the-evolution-of-http-how-the-internet-became-what-it-is-today/
4、https://http.dev/1.1