http协议的演进史

HTTP是什么

HTTP是超文本传输协议。
超文本：HTTP的传输内容，文字/视频/图片等的混合体
传输：是一个在计算机世界里专门用来在两点之间传输数据的约定和规范
协议：行为约定和规范

综上，HTTP是一个在计算机世界专门在两点之间传输文字，图片，视频等超文本数据的约定和规范

HTTP1.0、HTTP1.1、HTTP2、HTTP3演变

HTTP1.0 --> HTTP1.1

HTTP/1.0每进行一次HTTP通信，都需要经历建立TCP连接、传输HTTP数据和断开TCP连接三个阶段。为了解决这个问题，HTTP/1.1中增加了持久连接的方法，它的特点是在一个TCP连接上可以传输多个HTTP 请求，只要浏览器或者服务器没有明确断开连接，那么该TCP连接会一直保持。使用长连接的方式改善了 HTTP/1.0 短连接造成的性能开销。

HTTP1.1瓶颈

• 请求 / 响应头部（Header）未经压缩就发送，首部信息越多延迟越大。只能压缩 Body 的部分；
• 发送冗长的首部。每次互相发送相同的首部造成的浪费较多；
• 对头阻塞问题。
  当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一同被阻塞了，会招致客户端一直请求不到数据。
  HTTP/1.1 采用了长连接的方式，这使得管道（pipeline）网络传输成为了可能。 即可在同一个 TCP 连接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。 举例来说，客户端需要请求两个资源。以前的做法是，在同一个 TCP 连接里面，先发送 A 请求，然后等待服务器做出回应，收到后再发出 B 请求。那么，管道机制则是允许浏览器同时发出 A 请求和 B 请求。但是服务器必须按照接收请求的顺序发送对这些管道化请求的响应。如果服务端在处理 A 请求时耗时比较长，那么后续的请求的处理都会被阻塞住，这称为「队头堵塞」。所以，HTTP/1.1 管道解决了请求的队头阻塞，但是没有解决响应的队头阻塞。注意： HTTP/1.1 管道化技术不是默认开启，而且浏览器基本都没有支持。
• 没有请求优先级控制；
• 请求只能从客户端开始，服务器只能被动响应

HTTP1.1的性能瓶颈，我们可以做如下的优化

1. 尽量避免发送 HTTP 请求；
   本地增加缓存
   内嵌js/css
   …
2. 在需要发送 HTTP 请求时，考虑如何减少请求次数；
   合并资源
   图片base64
   按需加载资源
   …
3. 减少服务器的 HTTP 响应的数据大小；
   gzip压缩资源
   …

HTTP1.1 --> HTTP2

• 头部压缩（解决了http1.1的前两条瓶颈问题）
  HTTP/2 会压缩头（Header）如果你同时发出多个请求，他们的头是一样的或是相似的，那么，协议会帮你消除重复的部分。

  这就是所谓的 HPACK 算法：在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。

  HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文，而是全面采用了二进制格式，头信息和数据体都是二进制，并且统称为帧。节省传输报文大小

• 并发传输（解决了http1.1的队头阻塞的问题）
  针对不同的 HTTP 请求用独一无二的 Stream ID 来区分，接收端可以通过 Stream ID 有序组装成 HTTP 消息，不同 Stream 的帧是可以乱序发送的，因此可以并发不同的 Stream ，也就是 HTTP/2 可以并行交错地发送请求和响应。

• 服务器推送
  HTTP2还在一定程度上改变了传统的“请求-应答”工作模式，服务器不再是完全被动地响应请求，也可以新建“流”主动向客户端发送消息。比如，在浏览器刚请求HTML的时候就提前把可能会用到的JS、CSS文件发给客户端，减少等待的延迟，这被称为"服务器推送"（ Server Push，也叫 Cache push）
  http://www.ruanyifeng.com/blog/2018/03/http2_server_push.html

HTTP2性能瓶颈

• 队头阻塞
  HTTP/2 通过 Stream 的并发能力，解决了 HTTP/1 队头阻塞的问题，看似很完美了，但是 HTTP/2 还是存在“队头阻塞”的问题，只不过问题不是在 HTTP 这一层面，而是在 TCP 这一层

  HTTP/2 是基于 TCP 协议来传输数据的，TCP 是字节流协议，TCP 层必须保证收到的字节数据是完整且连续的，这样内核才会将缓冲区里的数据返回给 HTTP 应用，那么当「前 1 个字节数据」没有到达时，后收到的字节数据只能存放在内核缓冲区里，只有等到这 1 个字节数据到达时，HTTP/2 应用层才能从内核中拿到数据，这就是 HTTP/2 队头阻塞问题。所以，一旦发生了丢包现象，就会触发 TCP 的重传机制，这样在一个 TCP 连接中的所有的 HTTP 请求都必须等待这个丢了的包被重传回来。

• TCP 和 TLS 握手时延，TCP 三次握手和 TLS 四次握手，共有 3-RTT 的时延；

• 连接迁移需要重新连接，移动设备从 4G 网络环境切换到 WiFi 时，由于 TCP 是基于四元组来确认一条 TCP 连接的，那么网络环境变化后，就会导致 IP 地址或端口变化，于是 TCP 只能断开连接，然后再重新建立连接，切换网络环境的成本高；

HTTP2 --> HTTP3

HTTP/3 就将传输层从 TCP 替换成了 UDP，并在 UDP 协议上开发了 QUIC 协议，来保证数据的可靠传输。

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

• 更快的连接建立
  因为 QUIC 内部包含 TLS 1.3，因此仅需 1 个 RTT 就可以「同时」完成建立连接与 TLS 密钥协商，甚至在第二次连接的时候，应用数据包可以和 QUIC 握手信息（连接信息 + TLS 信息）一起发送，达到 0-RTT 的效果。

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