目录
[QUIC 是如何实现可靠传输的？](#QUIC 是如何实现可靠传输的？)
[Packet Header](#Packet Header)
[QUIC Frame Header](#QUIC Frame Header)
[QUIC 是如何解决 TCP 队头阻塞问题的？](#QUIC 是如何解决 TCP 队头阻塞问题的？)
[HTTP/2 的队头阻塞:](#HTTP/2 的队头阻塞:)
[没有队头阻塞的 QUIC](#没有队头阻塞的 QUIC)
[QUIC 是如何做流量控制的？](#QUIC 是如何做流量控制的？)
[QUIC 实现流量控制的方式：](#QUIC 实现流量控制的方式：)
[QUIC 对拥塞控制改进](#QUIC 对拥塞控制改进)
[QUIC 更快的连接建立](#QUIC 更快的连接建立)
[QUIC 是如何迁移连接的？](#QUIC 是如何迁移连接的？)
已经有基于 UDP 协议实现的可靠传输协议的成熟方案了，那就是 QUIC 协议，已经应用在了 HTTP/3。
QUIC 是如何实现可靠传输的？
要基于 UDP 实现的可靠传输协议，那么就要在应用层 下功夫，也就是要设计好协议的头部字段。
Packet Header
首次建立连接 时和日常传输数据时使用的 Header 是不同的.
QUIC 也是需要三次握手来建立连接的，主要目的是为了协商连接 ID。QUIC 报文中的 Pakcet Number 是严格递增的， 即使是重传报文，它的 Pakcet Number 也是递增的，这样就能更加精确计算出报文的 RTT。
QUIC 使用的 Packet Number 单调递增的设计，可以让数据包不再像 TCP 那样必须有序确认，QUIC 支持乱序确认，当数据包Packet N 丢失后，只要有新的已接收数据包确认，当前窗口就会继续向右滑动。
QUIC Frame Header
QUIC 通过单向递增的 Packet Number，配合 Stream ID 与 Offset 字段信息，可以支持乱序确认而不影响数据包的正确组装，摆脱了TCP 必须按顺序确认应答 ACK 的限制，解决了 TCP 因某个数据包重传而阻塞后续所有待发送数据包的问题。
QUIC 是如何解决 TCP 队头阻塞问题的？
什么是TCP对头阻塞问题：
其实就是接收窗口的对头阻塞问题，接收方收到的数据必须是在接收窗口范围内，如果收到超过窗口范围的数据就丢弃数据，
当接收窗口收到有序数据时，接收窗口才能往前滑动，然后那些已经接收并且被确认的「有序」数据就可以被应用层读取。
当接收窗口收到的数据不是有序的，比如收到第 33～40 字节的数据，由于第 32 字节数据没有收到， 接收窗口无法向前滑动，那么即使先收到第 33～40 字节的数据，这些数据也无法被应用层读取的。只有当发送方重传了第 32 字节数据并且被接收方收到后，接收窗口才会往前滑动，然后应用层才能从内核读取第 32～40 字节的数据。
TCP 必须按序处理数据，也就是 TCP 层为了保证数据的有序性，只有在处理完有序的数据后，滑动窗口才能往前滑动，否则就停留，停留「接收窗口」会使得应用层无法读取新的数据。
HTTP/2 的队头阻塞:
HTTP/2 通过抽象出 Stream 的概念，实现了 HTTP 并发传输，一个 Stream 就代表 HTTP/1.1 里的请求和响应。不同 Stream 的帧是可以乱序发送的（因此可以并发不同的 Stream ），因为每个帧的头部会携带 Stream ID 信息，所以接收端可以通过 Stream ID 有序组装成 HTTP 消息，而同一 Stream 内部的帧必须是严格有序的。
是 HTTP/2 多个 Stream 请求都是在一条 TCP 连接上传输，这意味着多个 Stream 共用同一个 TCP 滑动窗口，那么当发生数据丢失，滑动窗口是无法往前移动的，此时就会阻塞住所有的 HTTP 请求，这属于 TCP 层队头阻塞 。
没有队头阻塞的 QUIC
QUIC 也借鉴 HTTP/2 里的 Stream 的概念，在一条 QUIC 连接上可以并发发送多个 HTTP 请求 (Stream)。
QUIC 给每一个 Stream 都分配了一个独立的滑动窗口,各自控制的滑动窗口
QUIC 是如何做流量控制的？
TCP 流量控制是通过让「接收方」告诉「发送方」，它（接收方）的接收窗口有多大，从而让「发送方」根据「接收方」的实际接收能力控制发送的数据量。
QUIC 实现流量控制的方式：
- 通过 window_update 帧告诉对端自己可以接收的字节数，这样发送方就不会发送超过这个数量的数据。
- 通过 BlockFrame 告诉对端由于流量控制被阻塞了，无法发送数据。
TCP 的接收窗口在收到有序的数据后，接收窗口才能往前滑动；
QUIC 是基于 UDP 传输的，而 UDP 没有流量控制，因此 QUIC 实现了自己的流量控制机制。
QUIC 的 每个 Stream 都有各自的滑动窗口，不同 Stream 互相独立，队头的 Stream A 被阻塞后，不妨碍 StreamB、C的读取 。
QUIC 对拥塞控制改进
QUIC 协议当前默认使用了 TCP 的 Cubic 拥塞控制算法。QUIC 是处于应用层的，应用程序层面就能实现不同的拥塞控制算法，不需要操作系统，不需要内核支持，可以针对不同的应用设置不同的拥塞控制算法。
QUIC 更快的连接建立
QUIC 内部包含了 TLS，它在自己的帧会携带 TLS 里的"记录"，再加上 QUIC 使用的是 TLS1.3，因此仅需 1 个 RTT 就可以「同时」完成建立连接与密钥协商，甚至在第二次连接的时候，应用数据包可以和 QUIC 握手信息（连接信息 + TLS 信息）一起发送，达到 0-RTT 的效果。
QUIC 是如何迁移连接的？
TCP传输协议使用HTTP协议，通过四元组确定一条TCP连接。
QUIC 协议没有用四元组的方式来"绑定"连接，而是通过连接 ID 来标记通信的两个端点，客户端和服务器可以各自选择一组 ID 来标记自己，因此即使移动设备的网络变化后，导致 IP 地址变化了，只要仍保有上下文信息（比如连接 ID、TLS 密钥等），就可以"无缝"地复用原连接，消除重连的成本，没有丝毫卡顿感，达到了连接迁移的功能。