HTTP3.0 以及 QUIC协议
2.1 HTTP2.0和TCP的爱恨纠葛
HTTP2.0是2015年推出的，还是比较年轻的，其重要的二进制分帧协议、多路复用、头部压缩、服务端推送等重要优化使HTTP协议真正上了一个新台阶。
那么肯定要问HTTP2.0虽然性能已经不错了，还有什么不足吗?
熟悉HTTP2.0协议的同学应该知道，这些缺点基本都是由于TCP协议引起的，水能载舟亦能覆舟，其实TCP也很无辜呀!
在我们眼里，TCP是面向连接、可靠的传输层协议，当前几乎所有重要的协议和应用都是基于TCP来实现的。
网络环境的改变速度很快，但是TCP协议相对缓慢，正是这种矛盾促使谷歌做出了一个看似出乎意料的决定-基于UDP来开发新一代HTTP协议。
2.2 谷歌为什么选择UDP
我们单纯地看看TCP协议的不足和UDP的一些优点：
综合而知，谷歌决定在UDP基础上改造一个具备TCP协议优点的新协议也就顺理成章了，这个新协议就是QUIC协议。
2.3 QUIC协议和HTTP3.0
QUIC其实是Quick UDP Internet Connections的缩写，直译为快速UDP互联网连接。
QUIC提高了当前正在使用TCP的面向连接的Web应用程序的性能。它在两个端点之间使用用户数据报协议(UDP)建立多个复用连接来实现此目的。
QUIC的次要目标包括减少连接和传输延迟，在每个方向进行带宽估计以避免拥塞。它还将拥塞控制算法移动到用户空间，而不是内核空间，此外使用前向纠错(FEC)进行扩展，以在出现错误时进一步提高性能。
HTTP3.0又称为HTTP Over QUIC，其弃用TCP协议，改为使用基于UDP协议的QUIC协议来实现。
- QUIC协议详解
择其善者而从之，其不善者而改之。
HTTP3.0既然选择了QUIC协议，也就意味着HTTP3.0基本继承了HTTP2.0的强大功能，并且进一步解决了HTTP2.0存在的一些问题，同时必然引入了新的问题。
队头阻塞问题
HTTP2.0协议的多路复用机制解决了HTTP层的队头阻塞问题，但是在TCP层仍然存在队头阻塞问题。
TCP协议在收到数据包之后，这部分数据可能是乱序到达的，但是TCP必须将所有数据收集排序整合后给上层使用，如果其中某个包丢失了，就必须等待重传，从而出现某个丢包数据阻塞整个连接的数据使用。
QUIC协议是基于UDP协议实现的，在一条链接上可以有多个流，流与流之间是互不影响的，当一个流出现丢包影响范围非常小，从而解决队头阻塞问题。
0RTT（round-trip time)
非首次连接才可以做到
首次连接和非首次连接
前向安全问题
使用前向纠错码
连接迁移
抛弃TCP协议使用的五元组（SIP+SPort+DIP+DPort+协议号）,使用64位随机数字建立连接
补充
补充：HTTP/3 把传输层从 TCP 换成基于 UDP 的 QUIC，从根本上解决了 TCP 队头阻塞问题，并显著减少了握手延迟。
核心改进：
- 0-RTT 握手：首次握手需要 1-RTT 完成 TLS 协商；非首次连接可在客户端发出请求的同时携带加密数据，实现 0-RTT。
- 连接迁移：使用 64 位随机 Connection ID 标识连接，不依赖四元组，切换网络（WiFi ↔ 4G）不会断连。
- 多流无队头阻塞：QUIC 在一条连接上承载多个独立 stream，单个流丢包不影响其他流；HTTP/2 的多路复用仍受 TCP 队头阻塞影响。
- 前向纠错 (FEC)：携带校验包，丢包时可直接恢复，不必全部重传。
- 用户态拥塞控制：拥塞算法不再依赖内核，更新迭代快、可针对场景调优。
- 内置 TLS 1.3：加密握手过程更紧凑。
补充：浏览器启用 HTTP/3 需要服务端支持
Alt-Svc: h3=":443"通告，部分 CDN 已默认开启。
