【计算机网络】 ---- HTTP/1.1、HTTP/2、HTTP/3演变过程

1、HTTP/1.1

1.1 对比HTTP/1.0性能上的改进

1.1.1 TCP长连接方式

使用TCP长连接的方式改善了HTTP/1.0短连接造成的性能开销，HTTP可以在一次TCP连接中不断发送请求

1.1.2 支持管道传输

支持**管道(pipeline)**网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间 （串行排队）

1.1.3 支持只发送header而不发送body

先用header判断能否成功，再发数据，节约带宽。

1.1.4 host字段处理

在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）

1.2 HTTP/1.1性能瓶颈

• 请求/响应头部(Header)未经压缩就发送，首部信息越多延迟越大。HTTP/1.1只能压缩Body的部分；

  首部字段Content-Encoding会告知客户端服务器对实体的主体部分选用的内容编码方式。内容编码是指在不丢失实体信息的前提下所进行的压缩。 
  
  常见的4种内容编码的方式:
  - gzip
  - compress
  - deflate
  - identity
  
  但是首部信息不能被压缩。这就带来了HTTP头部巨大的问题，由于HTTP协议是无状态的，每一个请求都得携带HTTP头部，特别是对于有携带cookie的头部，而cookie的大小通常很大
  

• 发送冗长的首部。每次互相发送相同的首部造成的浪费较多

• 服务器是按请求的顺序响应的，如果服务器响应慢，会导致客户端一直请求不到数据，即队头阻塞；

• 没有请求优先级控制

• 请求只能从客户端开始，服务器只能被动响应

• 不支持服务器推送消息

• 并发连接有限，谷歌浏览器最大并发连接数是6个，而且每一个连接都要经过TCP和TLS握手耗时，以及TCP慢启动过程给流量带来的影响

1.3 HTTP/1.1 性能优化手段

• 尽量避免发送HTTP请求

  通过缓存技术来避免发送 HTTP 请求。客户端收到第⼀个请求的响应后，可以将其缓存在本地磁盘，下次请求的时候，如果缓存没过期，就直接读取本地缓存的响应数据。如果缓存过期，客户端发送请求的时候
  带上响应数据的摘要，服务器⽐对后发现资源没有变化，就发出不带包体的 304 响应，告诉客户端缓存的响应仍然
  有效。

• 减少HTTP请求的次数

  • 将原本由客户端处理的重定向请求，交给代理服务器处理，这样可以减少重定向请求的次数；

  • 将多个小资源合并成⼀个大资源再传输，能够减少 HTTP 请求次数以及 头部的重复传输，再来减少 TCP 连
    接数量，进⽽省去 TCP 握⼿和慢启动的网络消耗；

    将多张小图合并成⼀张大图供浏览器 JavaScript 来切割使⽤，这样可以将多个请求合并成⼀个请求，但是带来了新的问题，当某张小图片更新了，那么需要重新请求大图片，浪费了⼤量的网络带宽；
    
    将图⽚的⼆进制数据通过 base64 编码后，把编码数据嵌⼊到 HTML 或 CSS 文件中，以此来减少网络请求次数；
    
    将多个体积较小的 JavaScript ⽂件使⽤ webpack 等⼯具打包成⼀个体积更⼤的 JavaScript ⽂件，以⼀个请求替代了很多个请求，但是带来的问题，当某个 js ⽂件变化了，需要重新请求同⼀个包⾥的所有 js ⽂件；
    

  • 按需访问资源，只访问当前⽤户看得到/用得到的资源，当客户往下滑动，再访问接下来的资源，以此达到延迟请求，也就减少了同⼀时间的 HTTP请求次数

• 减少服务器的HTTP响应数据大小

  通过压缩响应资源，降低传输资源的大小，从而提高传输效率，所以应当选择更优秀的压缩算法。
  不管怎么优化 HTTP/1.1 协议都是有限的，不然也不会出现 HTTP/2 和 HTTP/3 协议

• 提升并发连接数量

  将同⼀个页面的资源分散到不同域名，提升并发连接上限，因为浏览器通常对同⼀域名的 HTTP 连接最⼤只能是 6 个；

2、HTTP/2

HTTP/2协议是基于HTTPS的，所以HTTP/2的安全性是有保障的

2.1 对比HTTP