QUIC最新进展及文档整理

QUIC 之类的可靠传输协议

互联网是一个分组(或者称为数据包)交换网络,其中传输的数据的基本单位是数据包。互联网中时时刻刻在发生的是距离有限的两个路由节点之间通过物理链路的数据包交换。那互联网中远距离复杂环境下的数据传输究竟如何完成的呢?它们正是借助于多次路由节点间直接的这种数据交换完成的。直觉上就让人觉得这种数据传输不是那么的可靠,不像电话网络连接那样。实际上互联网的数据传输确实不是百分之百的可靠,互联网上传输的数据天然地可能出现丢失,乱序,重复等等问题,但目前来看,绝大多数情况下,互联网还是比较有效。

互联网有效性的一个保证即是数据的可靠传输协议,如 TCP。TCP 对于当今的互联网是如此的重要,以至于整个网络协议栈被以 TCP/IP 来指代。通常情况下传输层协议及之下的协议由内核层实现,由硬件设备实现,之上的协议的数据,是我们平常写的应用程序可以比较方便的拿到的数据。TCP 在内核实现了一套复杂的可靠传输的字节流的语义,而 UDP 在发送时,是在数据包的前面简单的加个 IP 头部等就发送出去,接收时简单的剔除掉 IP 头部就抛给应用层的数据包。除了 TCP,互联网的可靠传输协议也多有基于 UDP 实现的,毕竟这类协议运行在用户空间,不管是部署还是更新,都要方便得多,比如 RUDP,UDT 等,当然还有 QUIC。

不管是 TCP,还是基于 UDP 并运行于用户空间的可靠传输协议,它们要解决的问题都是类似的,解决问题的方法也多有相似之处,在分析这些协议时也可以从类似的几个角度入手。

提供给应用方的操作。可靠传输协议提供给应用方的操作,通常包含:

  • 等待连接/接受连接的 listen/accept
  • 建立连接的 connect
  • 发送数据的 send/write
  • 接收数据的 receive/read
  • 关闭连接的 close/shutdown

可靠传输协议的连接的生命周期,通常包含:

  • 建立连接。
  • 数据传输及传输控制。
  • 断开连接。

断开连接的过程,通常主要涉及资源的清理和容错等,不太容易成为为了优化传输效率和安全性而开发的新协议的关注重点。而建立连接和数据传输控制方面,则是各种新方法新手段层出不穷。

连接建立过程主要为了协商传输参数及协议安全性而存在,不同的可靠传输协议有不同的看法及选择,如 TCP 的 3 次握手,UDT 则是 4 次握手,这是其一,即一般的连接握手过程需要经过几个 RTT。

数据传输过程中多一个 RTT,少一个 RTT 对于传输数据量很大的情况,可能没有太大的影响,但对于当今互联网中大量存在的数据量不大,如 REST API 访问这种请求则有着显著的影响,于是一些较新的协议会有减少连接建立过程中的 RTT 的尝试。为了减少连接建立过程的 RTT,一般来说有几种方法:一是尝试增加状态减少整体建连开销,即第一次连接建立耗时较长,后续再建立连接时,耗时减少,如 TLS 的会话恢复,TCP 的 Fast Open 优化,QUIC 的 0 RTT 建连等;二是尝试在建连的握手包中发送应用数据,如TCP 的 Fast Open 优化,QUIC 的 0 RTT 建连等;三是合并多个层次的协议的连接建立协商,如 QUIC 的合并可靠传输协议的协议协商和为了安全性的 TLS 的协议协商等;四是每次建立连接之后,试图多传一些数据,甚至是并发地传数据,比如 HTTP/2 的连接复用,QUIC 的连接复用等;五新的连接标识及连接维护方法,如 QUIC 的连接迁移特性。

我们写代码时,都讨厌状态,能少一个状态就少一个状态。状态几乎难免要增加不同代码和程序逻辑的耦合,增加部署维护成本,降低并发性,降低伸缩性等,然而为了更有效的网络数据传输,许许多多的协议将状态引入进来了。

然后是数据传输控制过程。无论哪种可靠传输协议,为了实现有效的可靠传输,发送缓冲区,接收缓冲区,数据包的接收确认,丢包/超时重传,快速重传,发送滑动窗口,接收滑动窗口,拥塞窗口拥塞控制等等几乎都是必不可少的。

数据传输过程主要由数据发送方控制,数据发送方依据接收方的接收能力,对于网络环境的探测感知,以及发送方的发送能力对发送过程进行控制。接收缓冲区和接收窗口代表数据接收方的数据接收能力,发送方的发送缓冲区代表发送方的发送能力,拥塞控制和拥塞窗口则代表发送方对于网络环境状态的感知,发送方主要综合考虑接收窗口和拥塞窗口,来控制发送窗口的大小。

为了探测网络状况,类似于 TCP 的 CUBIC 算法几乎总是无法避免的,慢启动,拥塞避免,快速重传,丢包/超时重传等。为了充分利用当前网络环境的网络带宽,慢启动过程的初始拥塞窗口可以适当地调整的比之前大一些,如 UDT 的做法。为了更精确地感知网络状态和接收方的接收能力的变化,如 RTT 等,QUIC 引入了单调递增的 Seqno,Ack Delay 时间,更多的 Ack 等特性,TCP 的数据包中总是会携带有接收窗口的大小,还有 HTTP/2 和 QUIC 中的 WINDOW_UPDATE 等。为了尽可能避免重传,FEC 也常常作为一种优化手段。探测到网络状况之后,对于传输更精细的控制,则可以专门再来探讨。

Wiki 页

QUIC Wiki 页HTTP3 Wiki 页 提供了对于 QUIC 协议和 HTTP/3 协议当前发展状况的一个简要描述。

QUIC Wiki 的说明那样,“最初由 Google 创建,并移交给 IETF 的名为 QUIC 的协议,与后来在 IETF 内创建的 QUIC(尽管它们的名字一样)有着巨大的不同。最初的 Google QUIC,有时被称为 gQUIC,只是一个用来基于加密的 UDP 发送 HTTP/2 帧的协议,而 IETF 协议 QUIC 则是一个通用的传输协议。”

当前的 HTTP/3 对应于之前的 Google QUIC,而当前的 IETF QUIC 则是一个更宏大的体系,既包括了作为通用的基于 UDP 的安全的传输协议,也包括也括 HTTP/3 等内容。

IETF QUIC Working Group

IETF QUIC 工作组的官方网站。这个站点有大量非常权威的标准文档和QUIC标准化推进过程进展的信息。QUIC 相关协议的一些最新文档如下:

IETF QUIC datatracker 页 可以查看当前 QUIC 协议标准化进程的一些状态。

IETF QUIC 工作组官方 GitHub

IETF QUIC 工作组官方 GitHub group

base-drafts

  • QUIC 协议套件的 IETF QUIC 工作组文档,Markdown 格式。

zh-translations

  • IETF-QUIC-Working-Group 相关文档的中文翻译所使用的仓库。

wg-materials

  • IETF QUIC 工作组的议程、会议记录、演示文稿和其他材料。

QUIC 实现

IETF QUIC 工作组收集整理的当前的 QUIC 实现,包含许多不同操作系统平台,不同编程语言,不同 QUIC 版本的实现。QUIC 协议的实现被分为了四个部分:IETF QUIC 传输基于 QUIC 的 IETF HTTPQPACK,和 Google QUIC

由于这些实现的存在,QUIC 协议不仅仅可以作为一个传输 HTTP 流量的安全的基于 UDP 的可靠传输协议,就像早期 Google QUIC 那样,而是已经可以作为一个通用的基于 UDP 的安全的可靠传输来用了。

工具

一个协议的完整生态,一定少不了可以对这种协议进行分析、测试、监测和调试的工具。IETF QUIC 工作组收集整理的当前的 QUIC 工具

最重要的协议分析工具当属 Wireshark,而 Wireshark 也已经提供了对于 HTTP/2,Google QUIC,和 IETF QUIC 协议包解码的支持了,当前(2019.03.14)最新的稳定版 Wireshar 是 3.0.0 版。其它还包括:

  • QUIC Tracker:QUIC-Tracker 是一个 IETF-QUIC 的测试集。它与 IETF-QUIC 实现交换数据包来验证实现是否与 IETF 规范一致。测试集由多个场景组成,每个场景都旨在测试 QUIC 协议的某个特定功能。测试集每天运行,并把结构抛在网站上。QUIC-Tracker 有一个自己的 GitHub group,QUIC-Tracker 源码的 GitHub repo 为 quic-tracker
  • qvalve:qvalve 可以以可预见的方式损害 QUIC 流,如通过丢包、重排序或者重传单独的数据包和包序列。它是一个不透明的 UDP 代理,应该插入到 QUIC 客户端和 QUIC 服务器之间。qvalve 的行为由一个以一种简单的语言描述的规则来配置。qvalve 可以用来模拟弱网、网络繁忙等情形,并观察在这种网络环境下 QUIC 协议的表现。
  • spindump:spindump 工具是一个 Unix 命令行实用程序,它可以用来检测通过某个网卡的流量的延迟。该工具执行被动的网络监视。它不是一个用于监视独立的连接的流量内容和元数据的工具,且由于网络中的连接是加密的,它也确实不可能做到那些。这个工具主要观察传输协议的特性,比如 QUIC Spin 位,并尝试获取关于单个连接的往返时间、聚合值或平均值的信息。这个工具支持 TCP,QUIC,COAP,DNS,和 ICMP 流量。

QUIC 协议实践

WEB加速,协议先行

让互联网更快的“快”—QUIC协议原理分析

让互联网更快的“快”—QUIC协议在腾讯的实践和优化

天下武功,唯’QUICK’不破,揭秘QUIC的五大特性及外网表现

七牛云技术分享:使用QUIC协议实现实时视频直播0卡顿!

HTTP/3 都来了,你却还在用 HTTP/1.1?

The Road to QUIC

Get a head start with QUIC

HTTP/3: From root to tip

坚持原创技术分享,您的支持将鼓励我继续创作!