http/1.0 http/1.1 http/2.0 http/3.0

http：超文本传输协议，是用于传输诸如HTML的超媒体文档的应用层协议，它被设计用于Web浏览器和Web服务器之间的通信，但它也可以用于其他目的。
http/1 http/2底层都是基于TCP协议，http/3是google基于UDP协议做了一个QUIC

http/1.0

• 可以发送get | post | head请求
• 新增多种数据类型，Content-type: text/plain | text/html | text/css ...

缺点：每次请求只能发送一个请求，数据发送完毕，连接就会关闭，如果还要请求其他资源，则重新建立连接，性能较差

http/1.1

• 持久连接：TCP连接默认不关闭，可以多个请求复用，长连接的连接时长可以通过请求头中的 keep-alive 来设置。
• 管道机制：在同一个TCP请求中客户端可以同时发送多个请求，但服务器会根据请求的顺序进行响应，“先发送一定要保证先接收”，同时使用字段Content-Length: 3495来区分多个响应，Content-length表示这个响应式多少字节的，该字段后面就表示是另一个响应。但是该字段不是必须的，可以使用分块传输编码，请求或响应中包含Transfer-Encoding字段，则说明数据块数量未定。
• 新增put | head | options | delete请求
• 新增host字段指定服务器域名

缺点：客户端发送多个请求，但是服务器只能按顺序执行，当执行完上一个请求才会去执行下一个请求，回应特别慢，性能也不好。
队头阻塞：http协议是基于“请求——应答”模式，管道机制，允许在同一个TCP连接上发送多个请求而不必等待前一个请求的响应。然而，由于响应必须按请求的顺序返回，如果一个请求处理时间过长（例如由于服务器端的处理延迟），就会阻塞后续请求的处理和响应。

http/2.0

• 二进制分帧（在原来的基础上改进传输性能，实现低延迟和高吞吐量）：头信息和数据块都是用二进制，统称为“帧”，之前的都是文本。解析数据相对会变得容易许多

• 多路复用（从应用层解决了队头阻塞问题（并未完全解决！！））：在一个TCP连接里，客户端和服务器都可以同时发送和响应多个请求，不用按顺序一一对应，双向、实时
  在 HTTP/2 中，有了二进制分帧之后，HTTP/2 不再依赖 TCP 链接去实现多流并行了，像前边提到的，在 HTTP/2 中：

  • 同域名下所有通信都在单个连接上完成
  • 单个连接可以承载任意数量的双向数据流
  • 数据流以消息的形式发送，而消息又由一个或多个帧组成，多个帧之间可以乱序发送，因为根据帧首部的流标识可以重新组装
    这一特性，使性能有了极大提升：
  • 同个域名只需要占用一个 TCP 连接，使用一个连接并行发送多个请求和响应，消除了因多个 TCP 连接而带来的延时和内存消耗
  • 并行交错地发送多个请求，请求之间互不影响
  • 并行交错地发送多个响应，响应之间互不干扰
  • 在 HTTP/2 中，每个请求都可以带一个 31 bit 的优先值，数值越大优先级越低，0 表示最高优先级。有了这个优先值，客户端和服务器就可以在处理不同流时采取不同的策略，以最优的方式发送流、消息和帧。

• 数据流：所有请求或相应的包都叫数据流，每一个数据流都有独一无二的编号，客户端可以指定数据流的优先级，优先级越高的服务器会优先响应。

• 头部压缩：在 HTTP/1 中，我们使用文本的形式传输 header，在 header 携带 cookie 的情况下，可能每次都需要重复传输几百到几千字节。使用gzip或compress对头部信息进行压缩

• 服务器推送：服务器主动向客户端发送资源，主动推送也遵守同源策略，换句话说，服务器不能随便将第三方资源推送给客户端，而必须是经过双方确认才行。

缺点：

• 队头阻塞：因为 TCP 是字节流协议，TCP 层必须保证收到的字节数据是完整且有序的，如果序列号较低的 TCP 段在网络传输中丢失了，即使序列号较高的 TCP 段已经被接收了，应用层也无法从内核中读取到这部分数据，从 HTTP 视角看，就是请求被阻塞了。
  TCP的设计保证了数据包的顺序传递和完整性。当TCP连接中的某个数据包丢失时，接收方必须等待重传该数据包，并且在此之前，后续的数据包无法被处理。这种机制在高丢包率或高延迟的网络环境中，会导致明显的队头阻塞现象，即使HTTP/2的多路复用机制在应用层面是无阻塞的。
• TCP 与 TLS 的握手时延迟：TCP是个面向连接的协议, 即发送请求后需要收到ACK消息, 以确认对象已接受数据. 如果每次请求都要在收到上次请求的ACK消息后再请求, 那么效率无疑很低. 后来HTTP/1.1提出了Pipeline技术, 允许一个TCP连接同时发送多个请求. 这样就提升了传输效率
• 网络迁移需要重新连接：一个 TCP 连接是由四元组（源 IP 地址，源端口，目标 IP 地址，目标端口）确定的，这意味着如果 IP 地址或者端口变动了，就会导致需要 TCP 与 TLS 重新握手，这不利于移动设备切换网络的场景，比如 4G 网络环境切换成 WiFi。

http/3.0

完全解决了队头阻塞问题！！
HTTP/3 不仅仅只是简单将传输协议替换成了 UDP，还基于 UDP 协议在「应用层」实现了 QUIC 协议，它具有类似 TCP 的连接管理、拥塞窗口、流量控制的网络特性，相当于将不可靠传输的 UDP 协议变成“可靠”的了，所以不用担心数据包丢失的问题。

相比http/2优势：

• 无队头阻塞，QUIC 连接上的多个 Stream 之间并没有依赖，都是独立的，也不会有底层协议限制，某个流发生丢包了，只会影响该流，其他流不受影响；

• 建立连接速度快，对于 HTTP/1 和 HTTP/2 协议，TCP 和 TLS 是分层的，分别属于内核实现的传输层、OpenSSL 库实现的表示层，因此它们难以合并在一起，需要分批次来握手，先 TCP 握手，再 TLS 握手。

  HTTP/3 在传输数据前虽然需要 QUIC 协议握手，这个握手过程只需要 1 RTT，握手的目的是为确认双方的「连接 ID」，连接迁移就是基于连接 ID 实现的。

  但是 HTTP/3 的 QUIC 协议并不是与 TLS 分层，而是 QUIC 内部包含了 TLS，它在自己的帧会携带 TLS 里的“记录”，再加上 QUIC 使用的是 TLS 1.3，因此仅需 1 个 RTT 就可以「同时」完成建立连接与密钥协商，甚至在第二次连接的时候，应用数据包可以和 QUIC 握手信息（连接信息 + TLS 信息）一起发送，达到 0-RTT 的效果。

• 连接迁移，QUIC 协议没有用四元组的方式来“绑定”连接，而是通过「连接 ID 」来标记通信的两个端点，客户端和服务器可以各自选择一组 ID 来标记自己，因此即使移动设备的网络变化后，导致 IP 地址变化了，只要仍保有上下文信息（比如连接 ID、TLS 密钥等），就可以“无缝”地复用原连接，消除重连的成本；