Quick UDP Internet Connections，是一种新的默认加密的互联网通信协议，它提供了许多改进，旨在加速HTTP通信，同时使其变得更加安全，其最终目的是在web上代替TCP和TLS协议。QUIC 协议也是整合了 TCP 协议的可靠性和 UDP 协议的速度和效率
1.为什么需要QUIC
从上个世纪 90 年代互联网开始兴起一直到现在，大部分的互联网流量传输只使用了几个网络协议。使用 IPv4 进行路由，使用 TCP 进行连接层面的流量控制，使用 SSL/TLS 协议实现传输安全，使用 DNS 进行域名解析，使用 HTTP 进行应用数据的传输
一方面是历史悠久使用广泛的古老协议，另外一方面用户的使用场景对传输性能的要求又越来越高。如下几个由来已久的问题和矛盾就变得越来越突出
TCP
- 协议历史悠久导致中间设备僵化。
- 依赖于操作系统的实现导致协议本身僵化。
- 建立连接的握手延迟大。
- 队头阻塞
- 连接不能迁移（手机以及Wifi的场景）
UDP
- 不稳定不可靠
在不需要任何修改的情况下就能提升 15% 以上的访问速度。特别是弱网络的时候能够提升 20% 以上的访问速度。
在频繁切换 4G 和 WIFI 网络的情况下，不会断线，不需要重连，用户无任何感知。 多路复用
业务场景
2.QUIC的工作原理
2.1 QUIC的基本特征
- 低延迟的连接建立
- 更加灵活的拥塞控制
- 没有队头阻塞的多路复用
- 流和连接的流量控制
- 前项纠错
- 连接迁移
- 身份认证和加密的头部和负载
2.1.1 低延迟建立连接
TLS1.2 2RTT
TLS1.3 首次1RTT，其余0RTT
1RTT
!0 RTT 的效果是因为QUIC的客户端会缓存服务器端发的令牌和证书，当有数据需要再次发送的时候，客户端可以直接使用旧的令牌和证书，这样子就实现了 0 RTT 了。对于没有缓存的情况，服务器端会直接拒绝请求，并且返回新生产的令牌和证书。 所以当令牌失效或者没有缓存的情况下，QUIC还是需要一次握手才能开始传输数据
2.1.2 拥塞控制
QUIC协议当前默认使用TCP协议的Cubic拥塞控制算法。同时也支持 CubicBytes、Reno、RenoBytes、BBR、PCC 等拥塞控制算法
QUIC协议在TCP拥塞算法基础上做了些改进：
-
可插拔
（1）应用程序层面就能实现不同的拥塞控制算法，不需要操作系统，不需要内核支持
（2）单个应用程序的不同连接也能支持配置不同的拥塞控制
（3）应用程序不需要停机和升级就能实现拥塞控制的变更
-
单调递增的Packet Number
QUIC并没有使用TCP的基于字节序号及ACK来确认消息的有序到达，QUIC使用的是Packet Number，每个Packet Number严格递增，所以如果Packet N丢失了，重传Packet N的Packet Number已不是N，而是一个大于N的值。 这样就很容易解决TCP的重传二义性问题
-
更多的ACK块
QUIC ACK帧支持256个ACK块，相比TCP的SACK在TCP选项中实现，有长度限制，最多只支持3个ACK块
由于 TCP 头部最大只有 60 个字节，标准头部占用了 20 字节，所以 Tcp Option 最大长度只有 40 字节，再加上 Tcp Timestamp option 占用了 10 个字节 ，所以留给 Sack 选项的只有 30 个字节，每一个 Sack Block 的长度是 8 个，加上 Sack Option 头部 2 个字节，也就意味着 Tcp Sack Option 最大只能提供 3 个 Block。
在丢包率比较高的网络下，更多的 Sack Block 可以提升网络的恢复速度，减少重传量。
-
精确计算RTT时间（降低超时重传概率）
QUIC ACK包同时携带了从收到包到回复ACK的延时，这样结合递增的包序号，能够精确的计算RTT。
2.1.3 前项纠错（降低丢包重传概率）
QUIC协议的每个数据包除了本身的数据以外，会带有其他数据包的部分数据，在少量丢包的情况下，可以使用其他数据包的冗余数据完成数据组装而无需重传，从而提高数据的传输速度。将N个包的校验和（异或）建立一个单独的数据包发送，这样如果在这N个包中丢了一个包可以直接恢复出来。除此之外还可以用来校验包的正确性
2.1.4 流量控制
QUIC 是基于 UDP 传输的，而 UDP 没有流量控制，因此 QUIC 实现了自己的流量控制机制，分为 Stream 和 Connection 两种级别：
Stream级别的流控
通过限制 stream 可以发送的数据量，防止单个 stream 消耗连接（connection）的全部缓冲区。与 TCP 不同，就算此前有 packet 没有接收到，它的滑动只取决于接收到的最大偏移字节数（highest received byte offset）。只要还有可用窗口，发送方可以继续发送数据。
Connections级别的流量控制
Connections级别的流量控制：对connection 中所有 streams 相加起来的总字节数进行限制，防止发送方超过 connection 的缓冲（buffer）容量。
2.1.5 连接迁移
每个网络连接都应该有一个唯一的标识，用来辨识并区分特定的连接。TCP 连接使用<Source IP, Source Port, Target IP, Target Port> 这四个信息共同标识，在早期PC 时代，这四个元素信息可以唯一标识通信双方的主机及端口，报文中也不需要一个专门的字段来标识连接，减少了传输开销。
到了移动互联网时代，客户端（比如手机）的位置可能一直在变，接入不同的基站可能就会被分配不同的Source IP 和Source Port。即便在家里，客户端可能也需要在LTE 和WIFI 之间切换，这两个网络分配给客户端的Source IP 和Source Port 可能也是不同的。TCP 用来标识连接的四个信息中的任何一个改变，都相当于TCP 连接标识改变了，也就变成了不同的连接，TCP 需要先断开旧的连接再建立新的连接，很显然连接切换或迁移过程不够顺畅高效。
早期移动电话使用Mobile IP 技术来解决网络迁移或切换过程引起的断连问题，Mobile IP 主要是通过新建IP 隧道的方式（也即建立一个新连接来转发数据包）保持原来的连接不断开，但这种方式增加了数据包的传输路径，也就增大了数据包的往返时间，降低了数据包的传输效率。
TCP 为保持前向兼容性，没法重新设计连接标识，但为了解决移动主机连接切换问题还是推出了一套解决方案MPTCP (Multipath TCP，在2013年发布于RFC 6824) 。针对移动主机同时支持LTE 和WIFI 等多条连接链路的情况，设计的多路径TCP 技术(MPTCP) 允许在一条TCP 链路中建立多个子通道，每个子通道都可以按照三次握手的方式建立连接，每个子通道的连接允许IP 不一致，这些子通道都会绑定到MPTCP Session（比如通过LTE 和WIFI 各建立一个子通道），发送端的数据可以选择其中一条通道进行传输。MPTCP 可以让移动主机在多个连接链路间顺畅切换，切换过程不断开连接。对于移动主机跨基站连接迁移的问题，也可以在原基站与目标迁移基站之间各建立一个连接链路/子通道，当移动主机从一个基站迁移到另一个基站时，只是从一个链路子通道切换到另一个链路子通道，同样能让连接链路顺畅迁移而不断开连接。MPTCP 跟TFO 技术类似，需要操作系统及网络协议栈支持，更新和部署阻力较大，目前并不适用。
QUIC 摆脱了TCP 的诸多限制，可以重新设计连接标识，QUIC 数据包结构中有一个Connection ID 字段专门标识连接，借助Connection ID，QUIC 的连接不再绑定IP 与 Port 信息，即便因为网络迁移或切换导致Source IP 和Source Port 发生变化，只要Connection ID 不变就仍是同一个连接，协议层只需要将控制块中记录的Source IP 和Source Port 信息更新即可，不需要像TCP 那样先断开连接，这就可以保证连接的顺畅迁移或切换，用户基本不会感知到连接切换过程。
2.1.6 没有队头阻塞的多路复用
HTTP/2.0
HTTP/3.0
QUIC 使用的Packet Number 单调递增的设计，可以让数据包不再像TCP 那样必须有序确认，QUIC 支持乱序确认，当数据包Packet N 丢失后，只要有新的已接收数据包确认，当前窗口就会继续向右滑动。待发送端获知数据包Packet N 丢失后，会将需要重传的数据包放到待发送队列，重新编号比如数据包Packet N+M 后重新发送给接收端，对重传数据包的处理跟发送新的数据包类似，这样就不会因为丢包重传将当前窗口阻塞在原地，从而解决了队头阻塞问题。
增加了Stream Offset 字段信息，属于同一个Stream ID 的数据包也可以乱序传输了（HTTP/2 中仅靠Stream ID 标识，要求同属于一个Stream ID 的数据帧必须有序传输），通过两个数据包的Stream ID 与 Stream Offset 都一致，就说明这两个数据包的内容一致。
3.QUIC的实际应用
真有什么公司在测试环境中甚至生产环境中使用quic协议的吗？效果如何？国内运营商对udp的歧视到底有多严重？ - 知乎 (zhihu.com)