在设计之初，Google就希望使用这个协议来取代HTTPS/HTTP协议，使网页传输速度加快。2015年6月，QUIC的网络草案被正式提交至互联网工程任务组。2018 年 10 月，互联网工程任务组 HTTP 及 QUIC 工作小组正式将基于 QUIC 协议的 HTTP（英语：HTTP over QUIC）重命名为HTTP/3。
所以，我们现在所提到的HTTP/3，其实就是HTTP over QUIC，即基于QUIC协议实现的HTTP。
QUIC协议必须要实现HTTP2.0在TCP协议上的重要功能，同时解决遗留问题，我们来看看QUIC是如何实现的。
队头阻塞问题
回顾:所有的数据通信是按次序进行的。服务器只有处理完一个回应，才会进行下一个回应。也就是如果一个响应返回延迟了，那么其后续的响应都会被延迟，直到队头的响应送达。
在HTTP/2协议中的多路复用机制解决了HTTP层的队头阻塞问题,但是在TCP层仍然存在队头阻塞问题.
TCP协议在收到数据包之后，这部分数据可能是乱序到达的，但是TCP必须将所有数据收集排序整合后给上层使用，如果其中某个包丢失了，就必须等待重传，从而出现某个丢包数据阻塞整个连接的数据使用。
但是,QUIC协议是基于UDP协议实现的，在一条链接上可以有多个流，流与流之间是互不影响的，当一个流出现丢包影响范围非常小，从而解决队头阻塞问题。
建链时间长问题
衡量网络建链的常用指标是RTT Round-Trip Time，也就是数据包一来一回的时间消耗。
一般来说HTTPS协议要建立完整链接包括:TCP握手和TLS握手，总计需要至少2-3个RTT，普通的HTTP协议也需要至少1个RTT才可以完成握手。
然而，QUIC协议可以实现在第一个包就可以包含有效的应用数据，从而实现0RTT
这在连接时延上有很大优势,可以节约数百毫秒的时间
但是对于双方完全陌生的情况下,为了保证传输的安全,我们需要进行一次连接
使用QUIC协议的客户端和服务端要使用1RTT进行密钥协商，使用的密钥协商算法是DH(Diffie-Hellman)迪菲-赫尔曼算法。
当密钥协商完之后,客户端会存储服务端发送来的config包,后续再连接时可以直接使用,从而跳过这个1RTT,实现0RTT的业务数据交互.
但是客户端保存config是有时间期限的，在config失效之后仍然需要进行首次连接时的密钥交换。
移动互联网领域表现不佳问题
网络切换几乎无时无刻不在发生。
TCP协议使用五元组来表示一条唯一的连接，当我们从4G环境切换到wifi环境时，手机的IP地址就会发生变化，这时必须创建新的TCP连接才能继续传输数据。
QUIC协议基于UDP实现摒弃了五元组的概念，使用64位的随机数作为连接的ID，并使用该ID表示连接。
基于QUIC协议之下，我们在日常wifi和4G切换时，或者不同基站之间切换都不会重连，从而提高业务层的体验。
UDP链接的安全问题
通俗来说，前向安全指的是密钥泄漏也不会让之前加密的数据被泄漏，影响的只有当前，对之前的数据无影响。
前面提到QUIC协议首次连接时先后生成了两个加密密钥，由于config被客户端存储了，如果期间服务端私钥泄漏，那么可以根据K = mod p计算出密钥K。
如果一直使用这个密钥进行加解密，那么就可以用K解密所有历史消息，因此后续又生成了新密钥，使用其进行加解密，当时完成交互时则销毁，从而实现了前向安全。
丢包处理