RUDP 通过应用层实现了可靠的 UDP，其中 QUIC 工作在 4~7层，克服了 HTTP/2 + TLS1.2 + TCP 协议栈的问题，包括握手延迟、队头阻塞、协议僵化。
Google 最早发布了 gQUIC，后来被 IETF 标准化为 iQUIC，目前已经大量应用在 API场景，直播场景，CDN场景。
截至 2021-07-30，iQUIC 的 release 尚未发布，本文讨论的是协议草案 iQUIC draft-34。

1 报文格式

1.1 UDP

1.2 QUIC

2 连接

stream
packet 注意不要和 IP 的 packet 混淆了。

2.1 连接迁移

对于 TCP，唯一标识一个 segment 使用四元组（源IP、源端口、目标IP、目标端口）
使用CID

2.2 首次连接

image.png
建立一个安全的连接包含传输协商、加密协商：

  • 对于 TCP + TLS1.2，传输协商1RTT，加密协商2RTT。
  • 对于 TCP + TLS1.3，传输协商1RTT，加密协商1RTT。TLS1.3 使用前向安全性的DH加密算法。

  • 对于 QUIC，传输协商、加密协商可以在1RTT中同时完成。

    2.3 重复连接

    image.png
    如果双方曾经建立过连接，再次连接（repeat connect）均可少1个RTT：

  • 对于 TCP + TLS1.2，传输协商1RTT，加密协商1RTT。

  • 对于 TCP + TLS1.3，传输协商1RTT，加密协商中前0.5个RTT使用临时密钥，后0.5个RTT使用新密钥，可以避免离线攻击。

  • 对于 QUIC，0-RTT，由于 QUIC 支持连接迁移，所以它可以最大化 0-RTT 的优势。

    3 传输

    3.1 多路复用

    解决 TLS 对头阻塞：QUIC 传输单元是 packet，加密单元是 packet。
    解决 TCP 队头阻塞：QUIC 基于 UDP，UDP 在接收端不处理顺序，天然解决。

    3.2 前向纠错

    解决丢包问题有两个思路：重传、冗余。
    TCP 是重传思路，其中包含超时重传、选择重传。
    QUIC 是冗余思路。FEC, Forward Error Correction, 前向纠错。使用 XOR 计算一个冗余包，当有包丢失的时候，通过冗余包可以恢复出丢失包。适用于高延迟、高丢包率场景。（移动互联网、网络基建差的地区）

    3.3 流量控制

    两层流量控制：

  • 基于 stream。可以认为是一个 HTTP 请求。

  • 基于 connection。可以认为是一条 TCP 连接。

    3.4 拥塞控制

    可插拔，为了避免 AIMD 机制降低带宽利用率，采用 packet pacing 来探测网络带宽。
    Cubic

    总结

    参考文献

  • rfc768 - User Datagram Protocol

  • rfc9000 - QUIC: A UDP-Based Multiplexed and Secure Transport