http3

通过这个图片，我们可以很清楚的看到，HTTP2和HTTP3的传输层是完全不同的协议，HTTP3的传输层是UDP协议。我们知道UDP协议是个不可靠的协议，而TCP协议是可靠协议，怎样保证可靠的呢？

QUIC协议

在UDP协议之上，新增了QUIC协议。由于TCP协议相对于UDP协议控制比较复杂耗时，因此针对HTTP应用贴身开发了QUIC协议代替TCP协议中关于可靠、流量控制的部分。

QUIC协议特性：
1 QUIC协议提供类似于HTTP2的流功能
2 QUIC协议使用流ID取代IP和端口，这样就能实现连接迁移。例如说从4G信号切换到wifi，下层的IP和端口变了，但是由于QUIC的流ID没有变，这个连接不会变，可以继续使用这个连接。

然后我们看一下HTTP3在QUIC上有什么变化呢？HTTP3由HTTP2进化，HTTP2最大的变化就是基于二进制流的传输。那么到HTTP3，由于QUIC已经管理了流，HTTP3本身就减负了，将流管理下移QUIC，而本身就直接调用QUIC的接口就可以了。

使用UDP作为传输层进行通信
从协议本身保证了安全性，QUIC在建立连接的握手过程中就完成了TLS加密握手

不和具体底层连接绑定，QUIC为每个连接的两端分别分配了一个唯一ID，上层连接只认这对逻辑ID。网络切换或者断连时，只需要继续发送数据包即可完成连接的建立
使用QPACK进行头部压缩，因为HPACK要求传输过程有序，这会导致队头阻塞。而QPACK不存在这个问题

超文本传输协议（HyperText Transfer Protocol）是一种用于分布式、协作式和超媒体信息系统的应用层协议。自1990年代初以来，HTTP协议是整个Internet进行数据通信的基础。

发展

在 HTTP/1.0 中，每一个TCP请求或响应都会被分配一个新的连接，这就导致了连接启动缓慢，在此之后，如何规避 TCP 启动慢就一直是 HTTP协议改善的核心。此后，在HTTP/1.1中引入了keep-alive 的概念，其允许在同一个 TCP 连接中对多个请求或响应进行序列号，从而使得不需要为每个请求都设置新的连接，避免建立新连接带来的网络开销。但是这个版本的keep-alive 连接不支持同时发送多个请求，随着互联网的迅猛发展又带来了新的问题：如何让数据发送效率提高？
在2015年，HTTP发布了第二个版本，即HTTP/2，进行了重大更新。例如：
在建立连接后，可以多路复用；
在建立连接后，一次的请求与被响应，视为流；
数据传输分为二进制帧片段。
而 HTTP/3是HTTP协议的第三个主要版本。在HTTP/3中，将弃用TCP协议，改为使用基于UDP协议的QUIC协议实现
QUIC 是快速UDP网络连接的简称，由Google公司研发，该协议旨在取代TCP协议，使网页传输更快、更稳定、更安全。

为什么使用UDP+QUIC？

实际上，在此前的HTTP协议中一直是使用TCP作为传输协议。为什么在HTTP/3中要换成UDP呢？众所周知，TCP 是一种面向连接的、可靠的、基于字节流的传输层通信协议，在数据传输过程中其加入了序列号、对收到的报文进行排序以检测重复数据，数据重传、拥塞控制、使用校验和确保无错传输、流控制等。使用TCP 协议进行数据传输会经过三次握手，在连接创建过程中，很多参数要被初始化，例如序号被初始化以保证按序传输和连接的强壮性，其目的是保证数传输和断开的可靠，确保所有数据都被完全传输。因此很多对业务稳定性非常高的协议都一直采用TCP协议作为数据传输协议。
事实上，在HTTP/2 之前的版本中，都是采用TCP 进行数据传输的。而 HTTP/2 引入的多路复用技术改善了HTTP/1.1的keep-alive 带来的缺陷，但是当数据包丢失增加时，HTTP/2的性能会由于TCP处理包重传的方式（HOL阻塞）而下降，从而大大影响效率。因为所有的流都是共享同一个连接，当数据包丢失超出阈值，HTTP/2的运行效率可能还不如HTTP/1的效率高。

而UDP协议则比较简单，其特点如下：

无需建立连接，因此UDP不会引入建立连接的时延；
没有TCP 那么复杂的报头，例如重传、序列号等等；
速度快，但是不保证数据的完整性。

事实上，这与整个互联网快速发展的大背景有关系。随着移动互联网快速发展以及物联网以及5G技术的逐步兴起，网络交互的场景越来越丰富，大量的音频、视频、直播等数据在网络传上传输，用户对网络传输效率和 WEB 响应速度的要求也越来越高。HTTP/3 协议当然不能单独使用UDP协议，它必须在QUIC的配合下才可以使用UDP，其把数据的完整性校验这一环节放在了QUIC上，他的特点：

减少了 TCP 三次握手及 TLS 握手时间，使用TCP协议配合HTTPS，TLS 完全握手需要至少 2 个 RTT 才能建立，简化握手需要 1 个 RTT 的握手延迟，而QUIC在TLS握手时间上，由于建立在 UDP 的基础上，同时又实现了 0RTT 的安全握手，所以在大部分情况下，只需要 0 个 RTT 就能实现数据发送。

改进的拥塞控制，QUIC 协议当前默认使用了 TCP 协议的 Cubic 拥塞控制算法，同时也支持 CubicBytes, Reno, RenoBytes, BBR, PCC 等拥塞控制算法。

避免队头阻塞的多路复用，队头阻塞主要是 TCP 协议的可靠性机制引入的。上面说了TCP为了实现可靠性，使用了很多机制来保障数据的传输，例如使用序列号来标识数据的顺序，数据必须按照顺序处理，如果前面的数据丢失，后面的数据就算到达了也不会通知应用层来处理。而QUIC使用UDP，没有三次握手和连接，只需要用户端和服务端的应用程序支持 QUIC 协议，完全避开了操作系统和中间设备的限制，同时相比此前的HTTP/2的多路复用，QUIC 一个连接上的多个流之间没有依赖。这样可以更快地并行处理任务。

比TCP协议更安全，TCP 协议的头部没有加密和认证，在传输过程中很容易被篡改，注入和窃听。而 QUIC 除了个别报文比如 PUBLIC_RESET 和 CHLO，所有报文头部都是经过认证的，报文 Body 都是经过加密的。

能够连接迁移，什么是连接迁移？比如使用手机从无线网切换到移动5G，这时客户端的IP会改变，需要重新建立和服务端的 TCP 连接。而QUIC实现了任何一条 QUIC 连接不再以 IP 及端口进行标识，而是以一个 64 位的随机数作为 ID 来标识，这样当网络变化，IP和端口改变，只要 ID 不变，这条连接依然维持着，上层业务逻辑感知不到变化，不会中断，也就不需要重连。且由于这个ID是随机的，产生冲突的概率非常小。

更科学的流量控制器，TCP 为了保证可靠性，窗口左边沿向右滑动时的长度取决于已经确认的字节数。如果中间出现丢包，就算接收到了更大序号的 Segment，窗口也无法超过这个序列号。而QUIC 基于流和连接级别的流量控制，类似HTTP/2，通过window_update帧告诉对端自己可以接收的字节数，这样发送方就不会发送超过这个数量的数据。通过BlockFrame告诉对端由于流量控制被阻塞了，无法发送数据。就算此前有些数据包没有接收到，它的滑动只取决于接收到的最大偏移字节数。

http3的痛点

UDP 连通性问题；

QUIC 不支持明文传输；

UDP 消耗资源多（UDP消耗的CPU资源多，且处理速度慢）；

原文：https://www.jianshu.com/p/dd9719c4c2c1

https://baijiahao.baidu.com/s?id=1659114248374316834&wfr=spider&for=pc