关于HTTP0.9、1.0、1.1、2.0、3.0

http协议

http0.9

当时的需求很简单，就是用来传输体积很小的HTML文件，所以HTTP/0.9的实现有以下三个特点：

• 在http0.9的时候，只是传输少量数据，客户端传输数据只有请求行，没有请求头和请求体
• 而服务器也不必返回响应头，直接返回数据
• 文件内容是以ASCII字符流来传输的，因为都是HTML格式的文件，所以使用ASCII字节码 来传输是最合适的。

http1.0

在浏览器中展示的不单是HTML文件了，还包括了JavaScript、CSS、图片、音频、视频等不同类型的文件。因此http/1.0呼之欲出，支持多种类型的文件下载是HTTP/1.0的一个核心诉求，而且文件格式不仅仅局限于ASCII编码， 还有很多其他类型编码的文件。
解决多类型的方法就是请求头和响应头带上一些信息，客户端回通过请求头信息告诉服务器返回什么类型的文件、采取什么形式的压缩、提供什么语言的文件以及文件的具体编码。服务器通常会根据请求头来准备相应的数据，但有时候如果不支持的话，比如浏览器请求的压缩类型是gzip，但是服务器不支持gzip，只支持br压缩，那么它会通过响应头中的content-encoding字段告诉浏览器最终的压缩类型，也就是说最终浏览器需要根据响应头的信息来处理数据。
http1.0的一些新特性

• 有的请求服务器可能无法处理，或者处理出错，这时候就需要告诉浏览器服务器最终处理该请求的情况，这就引入了状态码。状态码是通过响应行的方式来通知浏览器的。
• 为了减轻服务器的压力，在HTTP/1.0中提供了Cache机制，用来缓存已经下载过的数据。
• 服务器需要统计客戶端的基础信息，比如Windows和macOS的用戶数量分别是多少，所以HTTP/1.0的请求头中还加入了用戶代理的字段。
  1.0的缺点，每次请求都需要建立一次TCP连接，这样每次请求都会产生一个RTT，而且TCP慢启动的特性导致数据传输慢.

http1.1

最大特点持久化连接
在一个TCP连接上可以传输多个HTTP 请求，只要浏览器或者服务器没有明确断开连接，那么该TCP连接会一直保持。
持久连接在HTTP/1.1中是默认开启的，所以你不需要专门为了持久连接去HTTP请求头设置信息，如果你不想要采用持久连接，可以在HTTP请求头中加上Connection: close。目前浏览器中对于同一个域名，默认允许同时建立6个TCP持久连接。也就是说在1.1可以同时并行6个请求
提供虚拟主机
在HTTP/1.0中，每个域名绑定了一个唯一的IP地址，因此一个服务器只能支持一个域名。但是随着虚拟主机技术的发展，需要实现在一台物理主机上绑定多个虚拟主机，每个虚拟主机都有自己的单独的域名，这些单独的域名都公用同一个IP地址。
因此，HTTP/1.1的请求头中增加了Host字段，用来表示当前的域名地址，这样服务器就可以根据不同的Host值做不同的处理。
1.1的缺点：
①由于同一个域名可以建立6个TCP连接，会导致竞争带宽的问题，
②而TCP慢启动的策略，就像汽车的启动过程，当带宽充足，每条连接的发送接受速度都会慢慢提升，而一旦带宽不足时，这些TCP连接又会减慢发送或者接收的速度。这样就会出现一个问题，因为有的TCP连接下载的是一些关键资源，如CSS文件、JavaScript文件等，而有的TCP连接下载的是图片、视频等普通的资源文件，但是多条TCP连接之间又不能协商让哪些关键资源优先下载，这样就有可能影响那些关键资源的下载速度了。
③对头阻塞，如果有一个丢包了，整个连接都会暂停等待丢包的被客户端重新发送，这个等待时间会浪费带宽资源，服务器按请求的顺序响应
④请求 / 响应头部（Header）未经压缩就发送，首部信息越多延迟越大。
⑤没有优先级控制，会导致首页加载慢
支持管道网络传输
只要第一个请求发出去，不必等响应回来，直接可以发送第二个请求。

管线化-应对对头阻塞

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

http2.0

多路复用

将数据经过二进制分帧层处理后，数据会被转换为一个个带有请求id编号的帧，然后服务器收到所有帧后会将相同ID帧合并。然后服务器会将处理的相应行。响应头和响应体分别发送到二进制分帧层，经同样的步骤到客户端
优先级
HTTP/2提供了请求优先级，可以在发送请求时，标上该请求的优先级，这样服务器接 收到请求之后，会优先处理优先级高的请求。
将数据提前推送给浏览器
当用 戶请求一个HTML⻚面之后，服务器知道该HTML⻚面会引用几个重要的JavaScript文件和CSS文件，那么在 接收到HTML请求之后，附带将要使用的CSS文件和JavaScript文件一并发送给浏览器，这样当浏览器解析 完HTML文件之后，就能直接拿到需要的CSS文件和JavaScript文件，这样增加了首次页面的启动速度。

头部压缩

采用HPACK算法在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，当发送多个请求，其请求头类似的话，协议会消除重复的部分，这样就提高速度了。

• Method 表达方式冗余：例如 HTTP 的 method 有 GET 、POST等不下数十种方法，每次请求都需要用多个不等长度的字符来表示请求method，浪费，Client和Server两端约定数字index 0代表GET，数字index 1代表POST。
• Cookie的冗余，一次完整的登录，Cookie可能又臭又长，但在整个HTTP生命周期，Cookie又不变，每次发送一个请求，都带一个几百字节Cookie浪费带宽，可以约定这个cookie为某个动态生成的index，这样，除了第一次需要发送完整的cookie，后面几次都可以用这个index代替cookie。

2.0的缺陷

• 多个请求是跑在一个TCP管道中的，如果其中任意一路数据流中出现了丢包的情况，那么就会阻塞该TCP连接中的所有请求。随着丢包率的增加，HTTP/2的传输效率也会越来越差。有测试数据表明，当系统达到了2%的丢包率 时，HTTP/1.1的传输效率反而比HTTP/2表现得更好。
• TCP建立连接的时延，如果使用HTTPS的话，还需要使用TLS协议进行 安全传输，而使用TLS也需要一个握手过程，这样就需要有两个握手延迟过程，进行TLS连接，TLS有两个版本TLS1.2和TLS1.3，每个版本建立连接所花的时间不同，大致是需要1〜2个RTT。
• TCP协议僵化，为了互联网正常工作，我们搭建的很多设备，这些设备很难更新，，如果有了新协议或者升级了TCP协议，那么新协议的数据经过这些中间设备，由于他们不理解包的内容，这些数据会被丢弃。

http3

为了解决TCP建立连接时延，我们需要UDP，并弥补UDP不可靠的问题
QUIC协议（全称Quick UDP Internet Connections，快速UDP互联网连接）
HTTP/2存在一些比较严重的与TCP协议相关的缺陷，但由于TCP协议僵化，我们几乎不可能通过修改TCP协 议自身来解决这些问题，那么解决问题的思路是绕过TCP协议，发明一个TCP和UDP之外的新的传输协议。

• 实现了类似TCP的流量控制、传输可靠性的功能。虽然UDP不提供可靠性的传输，但QUIC在UDP的基础 之上增加了一层来保证数据可靠性传输。它提供了数据包重传、拥塞控制以及其他一些TCP中存在的特性。
• 集成了TLS加密功能。目前QUIC使用的是TLS1.3，相较于早期版本，TLS1.3有更多的优点，其中最重要的 一点是减少了握手所花费的RTT个数。
• 实现了HTTP/2中的多路复用功能和TCP不同，QUIC实现了在同一物理连接上可以有多个独立的逻辑数据流。实现了数据流的单独传输，就解决了TCP中队头阻塞的问题。
• 实现了快速握手功能。由于QUIC是基于UDP的，所以QUIC可以实现使用0-RTT或者1-RTT来建立连接， 这意味着QUIC可以用最快的速度来发送和接收数据，这样可以大大提升首次打开⻚面的速度。
  3.0缺点
• 由于改动了底层协议，推广起来还很难
• 对于很多网络设备，根本不知道什么是 QUIC，只会当做 UDP，这样会出现很多问题。所以 HTTP/3 现在普及的进度非常的缓慢