从HTTP1.0到3.0的版本变迁

HTTP 1.0

短连接：每发起一次HTTP请求就必须建立TCP连接，即三次握手。性能较差。
无host头域：HTTP1.0中默认认为一个服务器中只有唯一的一个IP地址，所以省略了主机名（hostname）。这也就意味着其不支持虚拟主机的情况，多个虚拟主机共享一个IP地址。
不支持断点续传：如果某次数据传到90%断了，下次还是从0开始上传。

支持长连接和管道（pipeline）网络传输：建立一个TCP连接后，可以在这个TCP连接上发送多个HTTP请求。只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去。减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启Connection： keep-alive可以减少整体的响应时间。但注意，客户端在接收服务端返回的数据时，还是按照发送顺序接收的。如果第一个请求一直没有返回数据，会造成后续的请求也无法返回，造成队头阻塞。
支持Host头域。
在请求头引入range头域：允许请求资源的某个部分，即状态码206。

支持头部压缩：HTTP1.x版本中头部含有大量信息，且每次发送请求时，即使头部完全一致，也会重新发送，造成了不必要的带宽浪费。而在HTTP2.0中，使用encoder进行了头部压缩。协议会通过HPACK算法，在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。
二进制格式传输：HTTP1.x是文本形式传输，由于文本形式的多样性，在兼容性上考虑颇多，存在一些缺陷。而HTTP2.0采用二进制传输，只关注0和1的组合，更加健壮，也提高了传输的效率（无需将文本转成二进制在进行处理了）。
多路复用：HTTP2采用了二进制帧格式的数据结构，可以在一个TCP连接中并发多个请求或响应，而不用像HTTP1.x那样必须将发送顺序和响应顺序一一对应。
数据流：HTTP2 的数据包不是按HTTP1那样按管道顺序发送的，在HTTP2中每个请求或返回的所有数据包就是一个数据流。客户端可以指定数据流的优先级（HTTP1.x没有优先级）让服务端先返回。
服务器推送：HTTP2 还在一定程度上改善了传统的「请求 - 应答」工作模式，服务不再是被动地响应，也可以主动向客户端发送消息。

举例来说，在浏览器刚请求 HTML 的时候，就提前把可能会用到的 JS、CSS 文件等静态资源主动发给客户端，减少延时的等待，也就是服务器推送（Server Push，也叫 Cache Push）。

HTTP3.0的核心是QUIC协议。HTTP2.x由于多个HTTP请求复用一个TCP连接，就导致了一旦出现丢包。后续的所有HTTP请求都需要等待这个包重传成功才行。在HTTP3.0中，HTTP下层协议换成了基于UDP协议的QUIC协议来解决了该问题，它有如下一些特征：

QUIC 是基于HTTP2.0 + TLS + UDP的部分特性，形成自己的一套机制可以保证传输的可靠性的。比如：HTTP2.0中在应用层可以发送多个http请求，但在传输层TCP中是共享一个滑动窗口，就导致了TCP中分组丢失时，会将所有HTTP请求都阻塞了。而QUIC协议中，给每个请求流都分配一个独立的滑动窗口，当某个流发生丢包时，只会阻塞这个流，其他流不会受到影响。
TLS3 升级成了最新的 1.3 版本，头部压缩算法也升级成了 QPack。
HTTPS 要建立一个连接，要花费 6 次交互，先是建立三次握手，然后是 TLS/1.3 的三次握手。QUIC 直接把以往的 TCP 和 TLS/1.3 的 6 次交互合并成了 3 次，减少了交互次数。