http 不同版本之间的概念

V1.0 —— 一个请求建立一个连接，结束则关闭

浏览器与服务器只保持短暂的连接，每次请求都需要与服务器建立一个TCP连接， 服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。

缺点：每个请求都要连接、断开的操作， 性能上缺陷

解决方案：如果需要建立长连接，需要设置一个非标准的Connection字段 Connection：keep-alive .

V1.1 一个连接用于多个请求, 基于http pipelining技术

默认支持长连接(Connection: keep-alive)，即在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。

参考http1.1中的http pilining 参考：
https://www.zhihu.com/question/444343281/answer/2161660020

增加了更多的请求头和响应头来完善功能

1）引入了更多的缓存控制策略，eg:If-Unmodified-Since , If-Match , If-None-Match等缓存头来控制缓存策略

2）引入Range，允许值请求资源某个部分

3）引入host，实现了在一台Web服务器上可以在同一个地址和端口号上使用不提供的主机名来创建多个虚拟Web站点并且还添加了其他的请求方法： put、delete、options...

1)长连接：引入了持久连接，即TCP连接默认不关闭，可以被多个请求复用

2)管道化： 在同一个TCP连接里面， 客户端可以头痛是发送多个请求，虽然允许复用TCP连接，但是统一个TCP连接里面，所有的数据通信时按次序进行的，服务器只有处理完一个请求，才会接着处理下一个请求。 如果前面的处理特别慢，后面就会有许多请求排队等着。

3)新增请求方法， 请求头、 响应头、状态码

4)缓存处理：新增字段cache-control；当浏览器请求资源时，先看是否有缓存的资源，如果有缓存，直接取，不会再发请求，如果没有缓存，则发送请求
通过设置字段cache-control来控制

5)断点传输/节约宽带：在上传/下载资源时，如果资源过大，将其分割为多个部分，分别上传/下载，如果遇到网络故障，可以从已经上传/下载好的地方继续请求，不用从头开始，提高效率；在 Header 里两个参数实现的，客户端发请求时对应的是 Range 服务器端响应时对应的是 Content-Range

6. Host 请求头：早期 HTTP/1.0 中认为每台服务器都绑定一个唯一的 IP 地址并提供单一的服务，请求消息中的 URL 并没有传递主机名。而随着虚拟主机的出现，一台物理服务器上可以存在多个虚拟主机，并且它们共享同一个 IP 地址。为了支持虚拟主机，HTTP/1.1 中添加了 host 请求头，请求消息和响应消息中应声明这个字段，若请求消息中缺少该字段时服务端会响应一个 404 错误状态码。
   

V2.0 性能上的提升

1. 多路复用
2. 二进制分帧
3. 首部压缩
4. 服务器推送

1) 多路复用

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

因为流 ID 的存在， 通过同一个 HTTP 请求可以实现多个 HTTP 请求传输，客户端和服务器可以通过流 ID 来标识究竟是哪个流从而定位到是哪个 HTTP 请求。

2）二进制分帧

1> 最小单位： 帧

2> 二进制传输格式， 而非1.1的文本格式，解析起来更高效；将请求和响应数据分割为更小的帧，并且它们采用二进制编码

3> 同域名下所有通信都在单个连接上完成，该连接可以承载任意数量的双向数据流。

4> 每个数据流都以消息的形式发送，而消息又由一个或多个帧组成。 多个帧之间可以乱序发送，根据帧首部的流表示可以重新组装， 这也是多路复用同时发送数据的实现条件。

3）首部压缩

在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键值对， 对于相同的数据，不再通过每次请求和响应发送。

首部表 在v2.0的连续存续期内始终存在，由客户端和服务器共同渐进地更新。

请求1发送了所有的头部字段， 请求2只需要发送差异数据，减少了冗余数据，降低开销

4）服务器推送

允许服务器推送资源给客户端

即为：服务器会顺便把一些客户端需要的资源一起推送到客户端，如在响应一个页面请求中，就可以随同页面的其他资源， 免得客户端再次创建连接发送请求到服务器端获取。 —— 非常适合加载静态资源。

v3.0 —— QUIC协议

QUIC （quick UDP internet connections）一种基于UDP的低延迟传输协议。

主要目的：解决采用传输层TCP协议存在的问题，同时满足传输层和应用层对多连接、低延迟等的需求。 融合了TCP、TLS、HTTP/2等协议的特性，并基于UDP传输。

主要的提升：

1）低延迟连接：当客户端第一次连接服务器时，QUIC 只需要 1 RTT（Round-Trid Time）延迟就可以建立安全可靠的连接（采用 TLS 1.3 版本），相比于 TCP + TLS 的 3 次 RTT 要更加快捷。之后，客户端可以在本地缓存加密的认证信息，当再次与服务器建立连接时可以实现 0 RTT 的连接建立延迟。

2）复用了HTTP/2协议的多路复用功能：由于 QUIC 基于 UDP，所以也避免了 HTTP/2存在的队头阻塞问题。

3）基于用户域运行：基于 UDP 协议的 QUIC 运行在用户域而不是系统内核，这使得 QUIC 协议可以快速的更新和部署，从而很好地解决了 TPC 协议部署及更新的困难。

3）报文经过加密和认证：除了少量的报文，其它所有的 QUIC 报文头部都经过了认证，报文主体经过了加密。只要有攻击者篡改 QUIC 报文，接收端都能及时发现。

4）具有向前纠错机制：每个数据包携带了除了本身内容外的部分其他数据包的内容，使得在出现少量丢包的情况下，尽量地减少其它包的重传次数，其通过牺牲单个包所携带的有效数据大小换来更少的重传次数，这在丢包数量较小的场景下能够带来一定程度的性能提升。

需要自定义的内容

总结：

V0.9

仅仅支持Get， 近能够访问HTMl格式资源

V1.0:

浏览器与服务器只保持短暂的连接， 浏览器的每次请求都需要与服务器建立一个TCP连接

V1.1

1)默认长连接

2)管道化, 同时可以多个请求

4)缓存处理：cache-control

5)断点传输：资源一部分一部分上传

V2.0

1. 采用二进制格式而非文本格式
2. 完全多路复用，而非有序并阻塞的、只需一个连接即可实现并行
3. 使用报头压缩，降低开销
4. 服务器推送

主要解决问题：

HTTP2.0解决了HTTP1.1队首阻塞问题，同时不需要通过HTTP1.x的pipeline机制用多条TCP连接实现并行请求与响应；减少了TCP连接数对服务器性能的影响，同时将页面的多个数据通过已给数据连接进行传输，加快页面的传输速度。

还存在的问题:

1. http2.0 是基于TCP协议的，TCP协议在处理包时是有严格顺序的。TCP对头阻塞壹基金 TCP协议存在的额固有问题(慢启动、拥塞串口尺寸的设置等)
   
   => 虽然http没有了对头阻塞的问题，但是TCP还是有的。所以对头阻塞问题没有完全解决，倘若TCP丢包率过大，则HTTP/2的表现还不如HTTP/1.1。 —— TCP换成UDP

v3.0 —— QUIC协议

主要解决TCP中的对头阻塞的问题。。

1> 自定义连接机制

2> 自定义重传机制

3> 无阻塞的多路复用

4> 自定义流量控制

本文由mdnice多平台发布