基于UDP的可靠传输协议QUIC协议

基于 UDP 协议实现的可靠传输协议的成熟方案了，那就是 QUIC 协议，已经应用在了 HTTP/3。

QUIC是如何实现可靠传输的

• 基于 UDP 协议实现的可靠传输协议的成熟方案了，那就是 QUIC 协议，已经应用在了 HTTP/3。

• Packet header

  • Packet Header 首次建立连接时和日常传输数据时使用的 Header 是不同的

  • QUIC 也是需要三次握手来建立连接的，主要目的是为了协商连接 ID。协商出连接 ID 后，后续传输时，双方只需要固定住连接 ID，从而实现连接迁移功能。

  • Short Packet Header 中的 Packet Number 是每个报文独一无二的编号，它是严格递增的，也就是说就算 Packet N 丢失了，重传的 Packet N 的 Packet Number 已经不是 N，而是一个比 N 大的值。

  • 为什么要这么设计呢？

    • QUIC 报文中的 Pakcet Number 是严格递增的， 即使是重传报文，它的 Pakcet Number 也是递增的，这样就能更加精确计算出报文的 RTT。

    • 还有一个好处，QUIC 使用的 Packet Number 单调递增的设计，可以让数据包不再像 TCP 那样必须有序确认，QUIC 支持乱序确认，当数据包Packet N 丢失后，只要有新的已接收数据包确认，当前窗口就会继续向右滑动

• QUIC Frame Header

  • 一个 Packet 报文中可以存放多个 QUIC Frame。

  • 每一个 Frame 都有明确的类型，针对类型的不同，功能也不同，自然格式也不同。

  • 引入 Frame Header 这一层，通过 Stream ID + Offset 字段信息实现数据的有序性，通过比较两个数据包的 Stream ID 与 Stream Offset ，如果都是一致，就说明这两个数据包的内容一致。

  • QUIC 通过单向递增的 Packet Number，配合 Stream ID 与 Offset 字段信息，可以支持乱序确认而不影响数据包的正确组装

QUIC是如何解决TCP的队头阻塞问题的

• 没有队头阻塞的QUIC

  • 在一条 QUIC 连接上可以并发发送多个 HTTP 请求 (Stream)。

  • QUIC 给每一个 Stream 都分配了一个独立的滑动窗口，这样使得一个连接上的多个 Stream 之间没有依赖关系，都是相互独立的，各自控制的滑动窗口。

  • 假如 Stream2 丢了一个 UDP 包，也只会影响 Stream2 的处理，不会影响其他 Stream，与 HTTP/2 不同，HTTP/2 只要某个流中的数据包丢失了，其他流也会因此受影响。

QUIC是如何做流量控制的

• QUIC 实现流量控制的方式：

  • 通过 window_update 帧告诉对端自己可以接收的字节数，这样发送方就不会发送超过这个数量的数据。

  • 通过 BlockFrame 告诉对端由于流量控制被阻塞了，无法发送数据。

  • QUIC 是基于 UDP 传输的，而 UDP 没有流量控制，因此 QUIC 实现了自己的流量控制机制，QUIC 的滑动窗口滑动的条件跟 TCP 有一点差别，但是同一个 Stream 的数据也是要保证顺序的，不然无法实现可靠传输，因此同一个 Stream 的数据包丢失了，也会造成窗口无法滑动。

  • QUIC 的 每个 Stream 都有各自的滑动窗口，不同 Stream 互相独立，队头的 Stream A 被阻塞后，不妨碍 StreamB、C的读取。

  • QUIC 实现了两种级别的流量控制，分别为 Stream 和 Connection 两种级别：

    • Stream 级别的流量控制：Stream 可以认为就是一条 HTTP 请求，每个 Stream 都有独立的滑动窗口，所以每个 Stream 都可以做流量控制，防止单个 Stream 消耗连接（Connection）的全部接收缓冲。

    • Connection 流量控制：限制连接中所有 Stream 相加起来的总字节数，防止发送方超过连接的缓冲容量。

  • Stream 级别的流量控制

    • 接收窗口的左边界取决于接收到的最大偏移字节数，此时的接收窗口 = 最大窗口数 - 接收到的最大偏移数。

    • 看出 QUIC 的流量控制和 TCP 有点区别了：

      • TCP 的接收窗口只有在前面所有的 Segment 都接收的情况下才会移动左边界，当在前面还有字节未接收但收到后面字节的情况下，窗口也不会移动。

      • QUIC 的接收窗口的左边界滑动条件取决于接收到的最大偏移字节数。

  • Connection 流量控制

    • Connection 级别的流量窗口，其接收窗口大小就是各个 Stream 接收窗口大小之和

    • 上图所示的例子，所有 Streams 的最大窗口数为 120，其中

      • Stream 1 的最大接收偏移为 100，可用窗口 = 120 - 100 = 20

      • Stream 2 的最大接收偏移为 90，可用窗口 = 120 - 90 = 30

      • Stream 3 的最大接收偏移为 110，可用窗口 = 120 - 110 = 10

    • 那么整个 Connection 的可用窗口 = 20 + 30 + 10 = 60

      可用窗口 = Stream 1 可用窗口 + Stream 2 可用窗口 + Stream 3 可用窗口

QUIC对拥塞控制改进

• QUIC 是处于应用层的，应用程序层面就能实现不同的拥塞控制算法，不需要操作系统，不需要内核支持

• QUIC 可以随浏览器更新，QUIC 的拥塞控制算法就可以有较快的迭代速度。

• QUIC 处于应用层，所以就可以针对不同的应用设置不同的拥塞控制算法

QUIC更快的连接建立

• QUIC 内部包含了 TLS，它在自己的帧会携带 TLS 里的“记录”，再加上 QUIC 使用的是 TLS1.3，因此仅需 1 个 RTT 就可以「同时」完成建立连接与密钥协商，甚至在第二次连接的时候，应用数据包可以和 QUIC 握手信息（连接信息 + TLS 信息）一起发送，达到 0-RTT 的效果。

QUIC是如何迁移连接的

• 基于 TCP 传输协议的 HTTP 协议，由于是通过四元组（源 IP、源端口、目的 IP、目的端口）确定一条 TCP 连接。

• 当移动设备的网络从 4G 切换到 WIFI 时，意味着 IP 地址变化了，那么就必须要断开连接，然后重新建立 TCP 连接。

• QUIC 协议没有用四元组的方式来“绑定”连接，而是通过连接 ID来标记通信的两个端点，客户端和服务器可以各自选择一组 ID 来标记自己，因此即使移动设备的网络变化后，导致 IP 地址变化了，只要仍保有上下文信息（比如连接 ID、TLS 密钥等），就可以“无缝”地复用原连接，消除重连的成本，没有丝毫卡顿感，达到了连接迁移的功能。