HTTP协议的不足（HTTP/1.1）

同一时间，一个连接只能对应一个请求
- 针对同一个域名，大多数浏览器允许同时最多6个并发连接
只允许客户端主动发起请求
- 一个请求只能对应一个响应
同一个会话的多次请求中，头信息会被重复传输
- 通常会给每个传输增加500~800字节的开销
- 如果使用Cookie，增加的开销有时会达到上千字节
  SPDY
SPDY（speedy的缩写），是基于TCP的应用层协议，它强制要求使用SSL/TLS
- 2009年11月，Google宣布将SPDY作为提高网络速度的内部项目
SPDY与HTTP的关系
- SPDY并不用于取代HTTP，它只是修改了HTTP请求与响应的传输方式只需增加一个SPDY层，
- 现有的所有服务端应用均不用做任何修改SPDY是HTTP/2的前身
- 2015年9月，Google宣布移除对SPDY的支持，拥抱HTTP/2

HTTP/2

HTTP/2在底层传输做了很多的改进和优化，但在语意上完全与HTTP/1.1兼容
- 比如请求方法（如GET、POST）、Status Code、各种Headers等都没有改变
- 因此，要想升级到HTTP/2

√开发者不需要修改任何代码
√只需要升级服务器配置、升级浏览器

、

HTTP/2标准允许每个数据流都有一个关联的权重和依赖关系
- 可以向每个数据流分配一个介于1至256之间的整数
- 每个数据流与其他数据流之间可以存在显式依赖关系
客户端可以构建和传递“优先级树”，表明它倾向于如何接收响应
服务器可以使用此信息通过控制CPU、内存和其他资源的分配设定数据流处理的优先级
- 在资源数据可用之后，确保将高优先级响应以最优方式传输至客户端

HTTP/2使用HPACK压缩请求头和响应头
- 可以极大减少头部开销，进而提高性能
早期版本的HTTP/2和SPDY使用zlib压缩
- 可以将所传输头数据的大小减小85%~88%
- 但在2012年夏天，被攻击导致会话劫持
- 后被更安全的HPACK取代

Google觉得HTTP/2仍然不够快，于是就有了HTTP/3
- HTTP/3由Google开发，弃用TCP协议，改为使用基于UDP协议的QUIC协议实现
- QUIC（Quick UDP Internet Connections），译为：快速UDP网络连接，由Google开发，在2013年实现
- 于2018年从HTTP-over-QUIC改为HTTP/3

HTTP/3基于UDP，如何保证可靠传输？
- 由QUIC来保证
为何Google不开发一个新的不同于TCP、UDP的传输层协议？
- 目前世界上的网络设备基本只认TCP、UDP
- 如果要修改传输层，意味着操作系统的内核也要修改
- 另外，由IETF标准化的许多TCP新特性都因缺乏广泛支持而没有得到广泛的部署或使用因此，要想开发并应用一个新的传输层协议，是极其困难的一件事情
  HTTP/3的特性 - 连接迁移
TCP基于4要素（源IP、源端口、目标IP、目标端口）
- 切换网络时至少会有一个要素发生变化，导致连接发生变化
- 当连接发生变化时，如果还使用原来的TCP连接，则会导致连接失败，就得等原来的连接超时后重新建立连接口所以我们有时候发现切换到一个新网络时，即使新网络状况良好，但内容还是需要加载很久
- 如果实现得好，当检测到网络变化时立刻建立新的TCP连接，即使这样，建立新的连接还是需要几百毫秒的时间QUIC的连接不受4要素的影响，当4要素发生变化时，原连接依然维持
QUIC连接不以4要素作为标识，而是使用一组Connection ID（连接ID）来标识一个连接
- 即使IP或者端囗发生变化，只要Connection ID没有变化，那么连接依然可以维持
- 比如

√当设备连接到Wi-Fi时，将进行中的下载从蜂窝网络连接转移到更快速的Wi-Fi连接
√当Wi-Fi连接不再可用时，将连接转移到蜂窝网络连接

据Google和Facebook称，与基于TLS的HTTP/2相比，它们大规模部署的QUIC需要近2倍的CPU使用量
- Linux内核的UDP部分没有得到像TCP那样的优化，因为传统上没有使用UDP进行如此高速的信息传输
- TCP和TLS有硬件加速，而这对于UDP很罕见，对于QUIC则基本不存在
随着时间的推移，相信这个问题会逐步得到改善