HTTP / 0.9

HTTP/0.9 是于 1991 年提出的，主要用于学术交流，需求很简单——用来在网络之间传递 HTML 超文本的内容，所以被称为超文本传输协议。

整体来看，它的实现也很简单，采用了基于请求响应的模式，从客户端发出请求，服务器返回数据。

HTTP/0.9 的实现有以下三个特点。

• 第一个是只有一个请求行，并没有 HTTP 请求头和请求体，因为只需要一个请求行就可以完整表达客户端的需求了。

• 第二个是服务器也没有返回头信息，这是因为服务器端并不需要告诉客户端太多信息，只需要返回数据就可以了。

• 第三个是返回的文件内容是以 ASCII 字符流来传输的，因为都是 HTML 格式的文件，所以使用 ASCII 字节码来传输是最合适的。

HTTP / 1.0

被浏览器推动发展。1994 年底出现了拨号上网服务，同年网景又推出一款浏览器，从此万维网就不局限于学术交流了，而是进入了高速的发展阶段。

首先在浏览器中展示的不单是 HTML 文件了，还包括了 JavaScript、CSS、图片、音频、视频等不同类型的文件。因此支持多种类型的文件下载是 HTTP/1.0 的一个核心诉求，而且文件格式不仅仅局限于 ASCII 编码，还有很多其他类型编码的文件。

HTTP/1.0 引入了请求头和响应头，它们都是以为 Key-Value 形式保存的，在 HTTP 发送请求时，会带上请求头信息，服务器返回数据时，会先返回响应头信息。

但 HTTP/1.0 并不是一个“标准” ，只是记录已有实践和模式的一份参考文档，不具有实际的约束力，相当于一个“备忘录”。

HTTP / 1.1

1999 年, http / 1.1正式发布。从版本号我们就可以看到，HTTP/1.1 是对 HTTP/1.0 的小幅度修正。但一个重要的区别是：它是一个“正式的标准”，而不是一份可有可无的“参考文档”。HTTP/1.1 主要的变更点有：

改进持久连接

HTTP/1.0 每进行一次 HTTP 通信，都需要经历建立 TCP 连接、传输 HTTP 数据和断开 TCP 连接三个阶段。

因为随着互联网的发展，一个页面也不再是简单的html页面，他可以引入很多外部资源。这样如果每次下载外部资源就需要建立连接，传输数据，释放连接。那么将可能会产生很大的延迟。

为了解决这个问题，HTTP/1.1 中增加了持久连接的方法，它的特点是在一个 TCP 连接上可以传输多个 HTTP 请求，只要浏览器或者服务器没有明确断开连接，那么该 TCP 连接会一直保持。

HTTP 的持久连接可以有效减少 TCP 建立连接和断开连接的次数，这样的好处是减少了服务器额外的负担，并提升整体 HTTP 的请求时长。

浏览器中对于同一个域名，默认允许同时建立 6 个 TCP 持久连接。

不成熟的 HTTP 管线化

持久连接虽然能减少 TCP 的建立和断开次数，但是它需要等待前面的请求返回之后，才能进行下一次请求。如果 TCP 通道中的某个请求因为某些原因没有及时返回，那么就会阻塞后面的所有请求，这就是著名的队头阻塞的问题。

HTTP/1.1 中试图通过管线化的技术来解决队头阻塞的问题。HTTP/1.1 中的管线化是指将多个 HTTP 请求整批提交给服务器的技术，虽然可以整批发送请求，不过服务器依然需要根据请求顺序来回复浏览器的请求。 但是最后依旧是放弃了。

允许响应数据分块（chunked）

服务器会将数据分割成若干个任意大小的数据块，每个数据块发送时会附上上个数据块的长度，最后使用一个零长度的块作为发送数据完成的标志。这样就提供了对动态内容的支持。

具体过程，请看这里

增加cookie

可以保存用户登录状态。

具体请看这里

HTTP / 2

根据google提出的SPDY 协议，指定新版本的http协议。在2015年发布。HTTP/2 的制定充分考虑了现今互联网的现状：宽带、移动、不安全。

由于HTTP / 1.1对带宽的利用有问题，主要原因是

• TCP的慢启动 一旦一个 TCP 连接建立之后，就进入了发送数据状态，刚开始 TCP 协议会采用一个非常慢的速度去发送数据，然后慢慢加快发送数据的速度，直到发送数据的速度达到一个理想状态，我们把这个过程称为慢启动。 慢启动是 TCP 为了减少网络拥塞的一种策略，在应用层面是无法改变的。

• 同时开启了多条 TCP 连接，那么这些连接会竞争固定的带宽

带宽是指每秒最大能发送或者接收的字节数。

系统同时建立了多条 TCP 连接，当带宽充足时，每条连接发送或者接收速度会慢慢向上增加；而一旦带宽不足时，这些 TCP 连接又会减慢发送或者接收的速度。

这样就会出现一个问题，因为有的 TCP 连接下载的是一些关键资源，如 CSS 文件、JavaScript 文件等，而有的 TCP 连接下载的是图片、视频等普通的资源文件，但是多条 TCP 连接之间又不能协商让哪些关键资源优先下载，这样就有可能影响那些关键资源的下载速度了。

• HTTP/1.1 队头阻塞的问题 HTTP/1.1 中使用持久连接时，虽然能公用一个 TCP 管道，但是在一个管道中同一时刻只能处理一个请求，在当前的请求没有结束之前，其他的请求只能处于阻塞状态。这意味着我们不能随意在一个管道中发送请求和接收内容。

慢启动和 TCP 连接之间相互竞争带宽是由于 TCP 本身的机制导致的，而队头阻塞是由于 HTTP/1.1 的机制导致的。

那么该如何去解决这些问题呢？

HTTP/2 的思路就是一个域名只使用一个 TCP 长连接来传输数据来解决慢启动和TCP连接之间相互竞争带宽。

HTTP/2 需要实现资源的并行请求，也就是任何时候都可以将请求发送给服务器，而并不需要等待其他请求的完成，然后服务器也可以随时返回处理好的请求资源给浏览器。来解决对头阻塞问题。

该图就是 HTTP/2 最核心、最重要且最具颠覆性的多路复用机制。从图中你会发现每个请求都有一个对应的 ID，如 stream1 表示 index.html 的请求，stream2 表示 foo.css 的请求。这样在浏览器端，就可以随时将请求发送给服务器了。

HTTP/2 使用了多路复用技术，可以将请求分成一帧一帧的数据去传输，这样带来了一个额外的好处，就是当收到一个优先级高的请求时，比如接收到 JavaScript 或者 CSS 关键资源的请求，服务器可以暂停之前的请求来优先处理关键资源的请求。

HTTP / 2实现多路复用的过程

• 首先，浏览器准备好请求数据，包括了请求行、请求头等信息，如果是 POST 方法，那么还要有请求体。

• 这些数据经过二进制分帧层处理之后，会被转换为一个个带有请求 ID 编号的帧，通过协议栈将这些帧发送给服务器。

• 服务器接收到所有帧之后，会将所有相同 ID 的帧合并为一条完整的请求信息。

• 然后服务器处理该条请求，并将处理的响应行、响应头和响应体分别发送至二进制分帧层。

• 同样，二进制分帧层会将这些响应数据转换为一个个带有请求 ID 编号的帧，经过协议栈发送给浏览器。

• 浏览器接收到响应帧之后，会根据 ID 编号将帧的数据提交给对应的请求。 多路复用是 HTTP/2 的最核心功能，它能实现资源的并行传输。

流

他就是二进制帧的双向传输序列。等价于http1的一次请求应答。

HTTP/2 的流有哪些特点呢？

• 流是可并发的，一个 HTTP/2 连接上可以同时发出多个流传输数据，也就是并发多请求，实现“多路复用”；

• 客户端和服务器都可以创建流，双方互不干扰；

• 流是双向的，一个流里面客户端和服务器都可以发送或接收数据帧，也就是一个“请求 - 应答”来回；

• 流之间没有固定关系，彼此独立，但流内部的帧是有严格顺序的；

• 流可以设置优先级，让服务器优先处理，比如先传 HTML/CSS，后传图片，优化用户体验；

• 流 ID 不能重用，只能顺序递增，客户端发起的 ID 是奇数，服务器端发起的 ID 是偶数；

• 在流上发送“RST_STREAM”帧可以随时终止流，取消接收或发送；

• 第 0 号流比较特殊，不能关闭，也不能发送数据帧，只能发送控制帧，用于流量控制。

其他优化

头部压缩

HTTP / 1中只使用了content-encoding字段规定请求体中的编码方式，但是并不能对报文头部进行压缩。

所以HTTP / 2中开发了专门的HPACK算法，在客户端和服务器两端建立“字典”，用索引号表示重复的字符串，还釆用哈夫曼编码来压缩整数和字符串，可以达到 50%~90% 的高压缩率。

“HPACK”算法是专门为压缩 HTTP 头部定制的算法，与 gzip、zlib 等压缩算法不同，它是一个“有状态”的算法，需要客户端和服务器各自维护一份“索引表”，也可以说是“字典”（这有点类似 brotli），压缩和解压缩就是查表和更新表的操作。

为了方便管理和压缩，HTTP/2 废除了原有的起始行概念， 把起始行里面的请求方法、URI、状态码等统一转换成了头字段的形式，并且给这些“不是头字段的头字段”起了个特别的名字——伪头字段（pseudo-header fields）。而起始行里的版本号和错误原因短语因为没什么大用，顺便也给废除了。

为了与“真头字段”区分开来，这些“伪头字段”会在名字前加一个“:”，比如“:authority” “:method” “:status”，分别表示的是域名、请求方法和状态码。

现在 HTTP 报文头就简单了，全都是“Key-Value”形式的字段，于是 HTTP/2 就为一些最常用的头字段定义了一个只读的“静态表”（Static Table）。

二进制格式

报文将不采用纯文本的形式，而是采用二进制格式。

把原来的“Header+Body”的消息“打散”为数个小片的二进制“帧”（Frame），用“HEADERS”帧存放头数据、“DATA”帧存放实体数据。 就是上面实现多路复用的前提条件。

在 HTTP/2 连接上，虽然帧是乱序收发的，但只要它们都拥有相同的流 ID，就都属于一个流，而且在这个流里帧不是无序的，而是有着严格的先后顺序。

流是可并发的，一个 HTTP/2 连接上可以同时发出多个流传输数据，也就是并发多请求，实现“多路复用”。

流就相当于http / 1中的一个请求-应答

帧结构

报文头里最后 4 个字节是流标识符，也就是帧所属的“流”，接收方使用它就可以从乱序的帧里识别出具有相同流 ID 的帧序列，按顺序组装起来就实现了虚拟的“流”。

HTTP / 3

根据google提出的QUIC协议。2018 年，互联网标准化组织 IETF 提议将“HTTP over QUIC”更名为“HTTP/3”。

HTTP / 2解决了HTTP / 1.1应用层面的对头阻塞。但是TCP自己也存在对头阻塞问题。

在 TCP 传输过程中，由于单个数据包的丢失而造成的阻塞称为 TCP 上的队头阻塞。

如果在数据传输的过程中，有一个数据因为网络故障或者其他原因而丢包了，那么整个 TCP 的连接就会处于暂停状态，需要等待丢失的数据包被重新传输过来。你可以把 TCP 连接看成是一个按照顺序传输数据的管道，管道中的任意一个数据丢失了，那之后的数据都需要等待该数据的重新传输。

通过该图，我们知道在 HTTP/2 中，多个请求是跑在一个 TCP 管道中的，如果其中任意一路数据流中出现了丢包的情况，那么就会阻塞该 TCP 连接中的所有请求。这不同于 HTTP/1.1，使用 HTTP/1.1 时，浏览器为每个域名开启了 6 个 TCP 连接，如果其中的 1 个 TCP 连接发生了队头阻塞，那么其他的 5 个连接依然可以继续传输数据。

基于众多TCP自身的问题（TCP队头阻塞，TCP建立连接的延时，TCP协议僵化），HTTP / 3 基于UDP协议，重新构建一个QUIC协议。

• 实现了类似 TCP 的流量控制、传输可靠性的功能。虽然 UDP 不提供可靠性的传输，但 QUIC 在 UDP 的基础之上增加了一层来保证数据可靠性传输。它提供了数据包重传、拥塞控制以及其他一些 TCP 中存在的特性。

• 集成了 TLS 加密功能。目前 QUIC 使用的是 TLS1.3，相较于早期版本 TLS1.3 有更多的优点，其中最重要的一点是减少了握手所花费的 RTT 个数。

• 实现了 HTTP/2 中的多路复用功能。和 TCP 不同，QUIC 实现了在同一物理连接上可以有多个独立的逻辑数据流（如下图）。

• 实现了数据流的单独传输，就解决了 TCP 中队头阻塞的问题。QUIC 协议的多路复用实现了快速握手功能。由于 QUIC 是基于 UDP 的，所以 QUIC 可以实现使用 0-RTT 或者 1-RTT 来建立连接，这意味着 QUIC 可以用最快的速度来发送和接收数据，这样可以大大提升首次打开页面的速度。其他优化，请访问这里

一些思考

1. http是如何解决队头阻塞问题的？ 1.http协议要求请求-响应必须一来一回，上一个请求没有处理完，下一个请求是不能发出去的。一个tcp连接上的http请求必然是串行。

2. 管道模式可以顺序发出多个请求，但响应也必须顺序响应。这些都是http/1.1里规定的。

3. 再对比http/2，一个tcp连接里有多个流，每个流就是一个请求，所以多个请求可以并发，“复用”在了一个连接里。

总结自

极客时间李兵老师浏览器工作原理与实践 time.geekbang.org/column/arti…

HTTP/3原理与实践 mp.weixin.qq.com/s/iF0wbV5o7…