tcp一直以来是http协议的基础，但是从http3.0开始，tcp协议被彻底弃用了。主要因为tcp协议存在以下几个问题：
tcp在传输过程中，会把数据拆分成一个个按照顺序排列的数据包，这些数据包在传输到接收端之后，接收端再按照顺序，将这些数据包组成一个原始数据，这样就完成了数据传输。但如果其中一个数据包没有按照顺序到达的话，接收方会一直等待数据包的返回，这个时候会阻塞后续的请求。这种情况就发生了TCP队头阻塞的问题。而且在http2中引入了多路复用的技术，多个请求是基于一个TCP连接的，影响面积更大。
TCP的可靠连接是基于三次握手和四次挥手实现的，三次握手的过程是有时间消耗的，TCP的三次握手是客户端和服务端之间需要有三次交互，需要消耗额外1.5RTT，客户端和服务端比较远的情况下，如果一个RTT达到300~400ms，那么握手的过程就显得很慢了。
TCP一直存在着如上两个无法解决的问题，于是http3.0彻底弃用了TCP，基于UDP + Diffie-Hellman算法实现了QUIC协议，这个协议不仅可以提供像TCP一样的可靠性，还能实现快速握手，也不会发生队头阻塞的问题.
QUIC 的加密协议采用了 TLS 协议的最新版本 TLS 1.3，相对之前的 TLS 1.1-1.2，TLS1.3 允许客户端无需等待 TLS 握手完成就开始发送应用程序数据的操作，可以支持1 RTT 和 0 RTT，从而达到快速建立连接的效果。
HTTP/2.0 虽然解决了队头阻塞问题，但是其建立的连接还是基于 TCP，无法解决请求阻塞问题。
而 UDP 本身没有建立连接这个概念，并且 QUIC 使用的 stream 之间是相互隔离的，不会阻塞其他 stream 数据的处理，所以使用 UDP 并不会造成队头阻塞。
虽然 QUIC 没有使用 TCP 协议，但是它也保证了可靠性，QUIC 实现可靠性的机制是使用了 Packet Number，这个序列号可以认为是 synchronize sequence number 的替代者，这个序列号也是递增的。与 syn 所不同的是，不管服务器有没有接收到数据包，这个 Packet Number 都会 + 1，而 syn 是只有服务器发送 ack 响应之后，syn 才会 + 1。
比如有一个 PN = 10 的数据包在发送的过程中由于某些原因迟迟没到服务器，那么客户端会重传一个 PN = 11 的数据包，经过一段时间后客户端收到 PN = 10 的响应后再回送响应报文，此时的 RTT 就是 PN = 10 这个数据包在网络中的生存时间，这样计算相对比较准确。
虽然 QUIC 保证了数据包的可靠性，但是数据的可靠性是如何保证的呢？
QUIC 引入了一个 stream offset 的概念，一个 stream 可以传输多个 stream offset，每个 stream offset 其实就是一个 PN 标识的数据，即使某个 PN 标识的数据丢失，PN + 1 后，它重传的仍旧是 PN 所标识的数据，等到所有 PN 标识的数据发送到服务器，就会进行重组，以此来保证数据可靠性。到达服务器的 stream offset 会按照顺序进行组装，这同时也保证了数据的顺序性。
众所周知，TCP 协议的具体实现是由操作系统内核来完成的，应用程序只能使用，不能对内核进行修改，随着移动端和越来越多的设备接入互联网，性能逐渐成为一个非常重要的衡量指标。虽然移动网络发展的非常快，但是用户端的更新却非常缓慢，我仍然看见有很多地区很多计算机还仍旧使用 xp 系统，尽管它早已发展了很多年。服务端系统不依赖用户升级，但是由于操作系统升级涉及到底层软件和运行库的更新，所以也比较保守和缓慢。
QUIC 协议的一个重要特点就是可插拔性，能够动态更新和升级，QUIC 在应用层实现了拥塞控制算法，不需要操作系统和内核的支持，遇到拥塞控制算法切换时，只需要在服务器重新加载一边即可，不需要停机和重启。
而 QUIC 也实现了流量控制，QUIC 的流量控制也是使用了窗口更新 window_update，来告诉对端它可以接受的字节数。
TCP 协议头部没有经过加密和认证，所以在传输的过程中很可能被篡改，与之不同的是，QUIC 中的报文头部都是经过认证，报文也经过加密处理。这样只要对 QUIC 的报文有任何修改，接收端都能够及时发现，保证了安全性。
总的来说，QUIC 具有下面这些优势
- 使用 UDP 协议，不需要三次连接进行握手，而且也会缩短 TLS 建立连接的时间。
- 解决了队头阻塞问题。
- 实现动态可插拔，在应用层实现了拥塞控制算法，可以随时切换。
- 报文头和报文体分别进行认证和加密处理，保障安全性。
- 连接能够平滑迁移。