HTTP 3
HTTP/2 存在的问题
队头阻塞
TCP传输过程中会把数据拆分为一个个按照顺序排列的数据包，这些数据包通过网络传输到了接收端，接收端再按照顺序将这些数据包组合成原始数据，这样就完成了数据传输。但是如果其中的某一个数据包没有按照顺序到达，接收端会一直保持连接等待数据包返回，这时候就会阻塞后续请求。这就发生了TCP队头阻塞。
HTTP2 是基于 TCP 协议的，因此也存在这个问题
TCP握手时长
TCP 三次握手的过程客户端和服务器之间需要交互三次，那么也就是说需要消耗 1.5 RTT。
另外，如果使用的是安全的 HTTPS 协议，就还需要使用 TLS 协议进行安全数据传输，这个过程又要消耗 1.5 RTT
升级 TCP ？
基于上面我们提到的这些问题，升级 TCP 协议是否可行？
这就涉及到一个 协议僵化 的问题。大部分现有网络上的交换机、路由器、操作系统都不支持直接升级，更换设备的成本巨大。
QUIC协议
Google 2013年开发的基于 UDP 的协议，全称 Quick UDP Internet Connection
有以下特点：
基于
UDP的传输层协议：它使用UDP端口号来识别指定机器上的特定服务器。可靠性：虽然
UDP是不可靠传输协议，但是QUIC在UDP的基础上做了些改造，使得他提供了和TCP类似的可靠性。它提供了数据包重传、拥塞控制、调整传输节奏以及其他一些TCP中存在的特性。实现了无序、并发字节流：
QUIC的单个数据流可以保证有序交付，但多个数据流之间可能乱序快速握手：
QUIC提供0-RTT和1-RTT的连接建立，比三次握手快首次建立连接时实际上就是三次握手，只是在第三次握手时直接带上了数据，耗时
1-RTT后续建立连接时会直接使用缓存的密钥，密钥未过期时，直接发送数据即可，耗时
0-RTT
使用
TLS 1.3传输层安全协议：降低TLS握手延迟至1RTT
缺点
一样存在 协议僵化 的问题。因为 UDP 一直以来的定位都是不可靠连接，很多中间设备对 UDP 的支持程度并不高，有的甚至会过滤一些端口的 UDP 包，导致丢包
参考
Last updated