QUIC（Quick UDP Internet Connections）协议简要笔记(翻译)

概述

动机

支持SPDY协议的动机

目标

我们希望开发出一套传输协议以支持下列目标：

  1. 在今天的因特网上的广泛的部署能力（例如，能够顺利通过中间路由、可以在不修改内核或提升权限的情况下运行在普通用户客户端机器上）
  2. 减少因丢包引起的 head-of-line 阻塞 （丢失一个数据包不会对其他的数据流产生影响）
  3. 低时延 a. 极大的减少连接启动时延 (通常情况零RTT连接、加密算法协商、初始请求） b. 尝试时延前向纠错编码来减少丢包后重传造成的时延
  4. 在时延和效率方面提供对移动端的支持
  5. 避免拥塞的支持，跟TCP相比更友好
  6. 可媲美TLS的隐私数据保证（不需要按顺序的传输或按顺序的解密）
  7. 在服务器端和客户端双方面都能对可靠及安全的资源要求自动伸缩（包括合理的缓冲区管理和帮助，以避免促进放大的 DoS 攻击）
  8. 减少带宽消耗和增加通道状态的响应能力（在多路复用的流直接，使用统一的信号信道状态)
  9. 在不与其他目标相冲突的情况下减少数据包个数
  10. 为多路复用的流支持可靠的传输（可以模拟 TCP 多路复用的流）
  11. 在不与其他目标相冲突的情况下，能有效的支持带有demux-mux属性的代理
  12. 在不会牺牲我们既定的目标情况下，在任何可能的情况下尽量重用或者进化现有协议

理由和一些启示

摘要：从SPDY得到的经验看，为了不让中间路由设备误解数据包，最好的做法是尽可能的使用加密数据传输。

为什么不使用基于 DTLS 之上的 SCTP

摘要：这个达不到上述3a描述的目标。同时，没有前向纠错功能。

期望的 API 接口元素

API 概念

从最高层来看，我们希望有一种机制能将新来的stream接入到现有的连接中，而不是独立读写不同的连接。

流特性

我们期望不同流将具有不同的传输特性，可以设置或修改应用程序。这些包括等鲜明特征设置： • 可调节冗余级别 （延迟储蓄的贸易带宽） • 可调节优先级别 （仿照 SPDY 不断变化的优先次序计划）

我们期望一些控制通道，可以被看作一个带外流，将始终可用和可用于信号流的其余部分的状态更改。控制信道将可能包括专用帧 （控制帧），作为好保留的流，为加密的谈判。

按顺序的数据传输

必须提供类似 TCP 按顺序的流式传输模型。

###　连接状态

应用程序和实际连接之间分离，使得对连接使用很困难。举个例子，当发送应用程序完成发送功能，它可能试图关闭连接，但数据仍然可能会在本地发送缓冲区中，这样的例子在关闭连接时，可能会导致未定义的行为或终止应用程序。

为了更好地支持应用程序，必须支持下面的特性：

1.RTT (当前平滑估计) 2.数据包大小 （包括所有开销 ； 也不包括开销，只包括有效负载） 3.带宽 （平滑的当前估计值跨整个连接） 4.峰值持续带宽 (横跨整个连接） 5.拥塞窗口大小 （表示数据包中） 6.队列大小 （已形成，但尚未通过电线发出的数据包） 7.在队列中的字节数 8.每个流队列大小 （或字节流或未发送的数据包，每两个概览)

QUIC协议哲学

我们需要考虑性能效率，将协议分为四个阶段： Startup; Steady State; Idle Entry; Idle Departure

通过无连接的UDP建立连接：克服 NAT

最根本的问题是如何将 UDP 数据报，转变成一种基础的面向连接的协议。由中间设备和防火墙 NAT 服务的不但有可能不协助并更可能是阻碍这一进程，而加剧了这一问题。

一般而言，NAT 设备会将空闲时间超过30~120秒的udp端口映射解绑定。

CID：连接的ID，用于唯一识别一个连接

CID是一个随机串，目前为64比特长。一般而言，CID的确定是通过客户端发给服务器的第一个数据包而提议的。

NAT 绑定保持连接

保持连接：什么时候我们需要这个？

当服务端需要向客户端发送消息时，我们需要保持连接。

保持连接：需要多久？

准确的算法是待定(TBD)。保持连接的超时时间是可以通过协商来确定的。

UDP报文的分片

连接的建立和重连

启动阶段的 DDOS 攻击

安全证书

从高层次看连接的场景

第一次建立连接：通常需要1个RTT，有时需要2个RTTs

在此场景中，客户端与服务器建立连接时，其初始化的hello消息表明客户端以前从未连过该服务器，因此它不能指定一个公钥。来自客户端的初始化消息可能包括一些随机值以便加快该会话的协商过程。

重复连接：通常需要0个RTT，有时需要1个RTT，极少的情况下需要2个RTTs

稳定状态

连接结构体

安全性：防篡改、隐私、真实性

数据丢失

在整个互联网中，从chrome浏览器的测试数据看，UDP包的丢失率为1~2%。

Initial experiments with UDP connectivity from browsers around the world suggest that roughly 90-95% of users will have adequate UDP connectivity for successful QUIC connections. We conjecture that the 5%+ user connectivity block is predominantly caused by LAN firewalls, probably in enterprise settings.