HTTP3
HTTP/2的问题：
- 队头阻塞
- TCP与TLS的握手时延迟
- 网络迁移需要重新连接
队头阻塞
HTTP/2 多个请求是泡在同一个TCP链接中的，那么当TCP丢包的时候，就会阻塞该TCP连接中所有的请求。
TCP与TLS的握手延迟
发送HTTP请求的时候，需要经历TCP三次握手和TLS四次握手的过程，因此共需要三个RTT的时延才能发出请求数据。
TCP由于具有拥塞控制的特性，所以刚建立连接的TCP会有个慢启动的过程，他会对TCP链接产生“减速”效果。
网络迁移需要重新连接
一个TCP连接是由四元组（源IP地址，源端口号，目标IP，目标端口号）确定的，这意味着如果IP地址与端口号改变了，就会导致需要TCP和TLS重新握手，这不利于移动设备切换网络的场景，比如4G网络切换成了WIFI。
这些问题都是TCP协议内部固有的问题，无论应用层面怎么修改都没有办法，要解决这个问题，就必须把传输层协议替换为UDP。
QUIC协议的特点：
UDP是一个简单、不可靠的传输协议，而且是UDP包之间是无序的，也没有依赖关系。而且，UDP是不需要连接的，也就不需要握手和挥手过程，所以天然就是比TCP快。
当然HTTP/3不仅仅只是简单将传输协议替换成了UDP，还基于UDP在应用层上实现了QUIC协议，它类似于TCP连接的拥塞窗口、流量控制的网络特性，相当于将不可靠传输的UDP协议变为可靠的了。
无队头阻塞
QUIC协议也有类似于HTTP/2 Stream 与 多路复用的概念，也是可以在同一条连接上并发传输多个Stream，Stream可以认为就是一条HTTP请求。
由于QUIC使用的阐述协议是UDP，UDP不关心数据包的顺序，如果数据包丢失，UDP也不关心。不过QUIC协议会保证数据包的可靠性，每一个数据包都有一个序号唯一标示。当某一个流中的一个数据包丢失的时候，即使该留的其他数据包到达了，数据也没有办法被HTTP/3读取出来，直到QUIC接收到重传丢失的报文，数据才会交给HTTP/3。
QUIC连接上的多个Stream之间没有依赖，所以一个丢失了，也不会去影响别的流。
更快的链接连接建立
对于HTTP/1和HTTP/2协议，TCP和TLS是分层的，分别属于内核实现的穿出层、openssl库实现的表示层面，因此他们难以合并在一起，需要分批次来握手，先TCP握手，然后再TLS握手。
HTTP/3在传输数据前虽然需要QUIC协议握手，这个过程只需要1RTT，握手的目的是为确认双方的连接ID，链接迁移就是机遇连接ID实现的。但是HTTP/3的QUIC协议并不是与TLS分层，而是QUIC内部包含了TLS，他在自己的帧会携带TLS。“HTTP/3 当会话恢复时，有效负载数据与第一个数据包一起发送，可以做到 0-RTT。
连接迁移
给予TCP传输协议的 HTTP 协议，由于是通过四元组（源IP，源端口、目标IP、目标端口）确定一条TCP连接，那么当移动设备的网络从4G切换到WIFI的时候本地IP会发生改变，那么就必须要重新建立连接。而QUIC协议没有使用四元组协议来绑定这些信息。而是通过连接ID来标记通信的两个端点，客户端和服务器可以各自选择一组ID来标记自己，因此即使移动设别的网络改变的时候，只要保存好上下文信息，就可以“无缝”地复用原连接，消除重连的成本，达到了连接前一的功能。
