HTTP

HTTP 0.9

1. 用于简单的 HTML 传输
2. 只有 get 请求
3. 没有请求头和请求行
4. 服务器不会返回 header 等的描述信息
5. 使用 ASCII 码进行传输

HTTP 1.0

1. 新增多种请求方式、请求头、响应头
   1. 请求头: accept. aceept-encoding. accept-Charset. aceept-language
   2. 响应头: content-type. content-encoding. charset.
2. 新增状态码
3. 新增缓存
   1. expires. last-modifiedlif -modified-since

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

HTTP 1.1

1. 持久连接

   1. 在一个 TCP 连接上可以传输多个 HTTP 请求，只要浏览器或者服务器没有明确断开连接，那么该 TCP 连接会一直保持，持久连接在 HTTP1.1 中是默认开启的，如果你不想用持久连接,可队在请术头中设置 Connection: close

2. 引入管道机制

   1. 持久连接虽然能减少 TCP 的建立和断开次数，但是它需要等待前面的请求返回之后，才能进行下一次请术。如果 TCP 通道中的某个请术请求某些原因没有及时返回，那么就会阻塞后面的所有请求，这就是著名的队头阻塞的问题。HTTP1.1 中的管线控制是指将多个 HTTP 请术整批提交给服务器，服务器根据请求顺序来回复浏览器的请求。

3. 新增 host 域名

   1. 在 HTTP1.0 中，每个域名绑定了一个唯—的 IP 地址，因此—个服务器只能支持—个域名。但是随着虚拟主机技术的发展，需要实现在一台物理主机上绑定多个虚拟主机。每个虚拟主机都有自己的单独的域名，这些单独的域名都共用同—个 IP 地址。因此 HTTP1.1 中的请求头中增加了 Host 字段，用来表示当前的域名地址，这样服务器就可以根据不同的 Host 值做不同的处理;

4. 分块传输

   1. 在设计 HTTP 1.0 时，需要在响应头中设置完整的数据大小如 Content-Length:901，这样浏览器就可以根据设置的数据大小来接收数据。不过随着服务器端的技术发展,很多页面的内容都是动态生成的。因此在传输数据之前并不和道最终的数据大小。而来用分块传输编码，服务器会将数据分成若干数据块，每个数据块发送时会附上上个数据块的长度，最后使用一个零长度的块作为发送数据完成的标志。

5. 引入了客户端 Cookie 机制和安全机制

存在问题

对带宽的利用不理想

1. TCP 的慢启动： TCP 连接建立之后，就会发送数据状态，刚开始 TCP 协议会采用一个非常慢的速度去发送数据。然后慢慢加快发送数据的速度，直到发送数据的速度达到一个理想状态，我们把这个过程称为慢启动。耗费的时间比正常的时间要多很多，这样推迟了宝贵的首次渲染页面的时长，慢启动是 TCP 为了减少网络拥塞的一种策略，我们是没有办法改变的

2. 资源竞态： 浏览器为每个域名最多同时维护 6 个 TCP 持久连接同时开启了多条 TCP 连接。那么这些连接会竞争固定的带宽：当带宽充足的时候，每条连接发送或者接受的速度逐渐增加，当发现带宽不足是，又会减慢速度。这样就会出现—个问题，因为有的 TCP 连接下载的是—些关键资源：如 CSS 文件、 JavaScript 文件等，而有的 TCP 连接下载的是图片、视频等普通的资源文件，但是多条 TCP 连接之间又不能协商让哪些关键资源优先下载，这样就有可能影响那些关键资源的下载速度了。

3. 队头堵塞： 等待的过程带宽、CPU 都被白白浪费了。在浏览器处理生成页面的过程中，是非常希望能提前接收到数据的，这样就可以对这些数椐做预处理操作：比如提前接收到了图片，那么就可以提前进行编解码操作，等到需要使用该图片的时候，就可以直接给出处理后的数据了，这样能让用户感受到整体速度的提升

   • TCP 队头堵塞

     TCP 中的队头阻塞的产生是由 TCP 自身的实现机制决定的，无法避免。想要在应用程序当中避免 TCP 队头阻塞带来的影响，只有舍弃 TCP 协议。
     比如 google 推出的 quic 协议，在某种程度上可以说避免了 TCP 中的队头阻塞，因为它根本不使用 TCP 协议，而是在 UDP 协议的基础上实现了可靠传输。而 UDP 是面向数据报的协议，数据报之间不会有阻塞约束。

     • 发生在一个 TCP 分节丢失，导致其后续分节不按序到达接收端的时候。该后续分节将被接收端一直保持直到丢失的第一个分节被发送端重传并到达接收端为止。该后续分节的延迟递送确保接收应用进程能够按照发送端的发送顺序接收数据。这种为了达到完全有序而引入的延迟机制非常有用，但也有不利之处。

     • 假设在单个 TCP 连接上发送语义独立的消息，比如说服务器可能发送 3 幅不同的图像供 Web 浏览器显示。为了营造这几幅图像在用户屏幕上并行显示的效果，服务器先发送第一幅图像的一个断片，再发送第二幅图像的一个断片，然后再发送第三幅图像的一个断片；服务器重复这个过程，直到这 3 幅图像全部成功地发送到浏览器为止

     • 要是第一幅图像的某个断片内容的 TCP 分节丢失了，客户端将保持已到达的不按序的所有数据，直到丢失的分节重传成功。这样不仅延缓了第一幅图像数据的递送，也延缓了第二幅和第三幅图像数据的递送。

   • HTTP 队头阻塞

     对于 HTTP1.1 中管道化导致的请求/响应级别的队头阻塞，可以使用 HTTP2 解决。HTTP2 不使用管道化的方式，而是引入了帧、消息和数据流等概念，每个请求/响应被称为消息，每个消息都被拆分成若干个帧进行传输，每个帧都分配一个序号。每个帧在传输是属于一个数据流，而一个连接上可以存在多个流，各个帧在流和连接上独立传输，到达之后在组装成消息，这样就避免了请求/响应阻塞。

     • 客户端需要保持未收到响应的请求，当连接意外中断时，需要重新发送这部分请求

     • 只有幂等的请求才能进行管道化，也就是只有 GET 和 HEAD 请求才能管道化

HTTP 2.0

1. 多路复用： HTTP/2 复用 TCP 连接，在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，而且不用按照顺序一一对应，这样就避免了”队头堵塞”

2. 服务器推送： HTTP 2 还可以直接将数据提前推送到浏览器

3. 头部压缩： 使用 HPACK 算法对 header 的数据进行压缩，这样数据体积小了，在网络上传输就会更快。

4. 二进制分帧： 客户端发送的请术经过二进制分帧层之后，被转换成为一个个带有请求 ID 编号的帧(协议栈）然后发送给服务端：服务端接收到所有请求后，会将相同 ID 的帧会并为—条完整的请求信息。然后服务端处理该条请求，并将相应内容通过二进制分帧层转换成为一个个带有请求 ID 的帧，发送给客户端：浏览器接收到响应帧之后，会根据 ID 编号将帧的数据提交给对应的请求。

5. 可以设置请求的优先级： 在发送请术时.标上该请求的优先级,这样服务器接收到请求之后，会优先处理优先级高的请求。

HTTP 3.0

1. 基于 UDP 协议实现了类似于 TCP 的多路复用数据流、传输可靠性等功能，这套功能被称为 QUIC 协议

2. 无连接的

3. 丢失的包，没有超时重传

4. 错误包会被丢弃，不会触发重传

5. 接收端不会重排数据报顺序，没有队首阻塞