详细的QUIC要点.docx

详细的QUIC要点.docx

《详细的QUIC要点.docx》由会员分享，可在线阅读，更多相关《详细的QUIC要点.docx（21页珍藏版）》请在冰豆网上搜索。

详细的QUIC要点

1、QUIC的提出

SPDY是个目前基于TCP（经常使用SSL）实现的多路复用流协议。

此外，它可以通过尽可能快地（而不是等待前面的确认返回）发送所有请求来减少延迟，并且可以通过压缩一些冗余流量来减少带宽使用。

尽管其特性和成功，当提供一个延迟减少时，它在请求有效地利用资源方面遇到了一些问题。

a）单个包延迟导致一个流的头阻塞

b）由TCP处理、导致额外带宽减少和序列化延迟开销的不适宜的拥塞避免

c）TLS（SSL）会话恢复延迟

d）TLS往往引发一个解密依赖，先前的包必须在后来的包可以被解密之前被解密

我们希望减少整个英特网的延迟，提供一个响应性更好的用户交互环境。

随着时间的推移，整个世界的带宽将会提升，但是受光速支配的往返时间不会减少。

我们需要一个协议用更少的延迟和更少的重传时间消耗去传递整个互联网的请求、响应和交互，并且，我们相信现今的方法在阻碍我们。

这部分指出我们希望解决的潜在问题。

我们想要开发一个支持以下目标的传输：

减少因包丢失造成的头阻塞，低延迟，隐私保证堪比TLS，等等。

现今，可行性的头号目标显然是这个协议发展的主要驱动力。

中间盒和防火墙会代表性地阻塞或明显地降低基于除了TCP或UDP的格式的任何传输，明白这个以后，我们甚至不会考虑革命性的协议。

所以，只有开发基于TCP或UDP的协议，用来解决我们遇到的问题以及实现我们的目标。

由于基于DTLS（数据包传输层安全）的SCTP在建立连接时需要的延时太长，大约为4个RTT，所以SCTP是不合适的。

因此，我们开发了基于UDP的QUIC协议。

2、QUIC协议的层次

可以认为QUIC是为了解决SPDY在TCP遇到的瓶颈而在UDP上做探索所设计的方案。

参考SPDY来理解，可认为QUIC的传输内容分两层，高层类似SPDY，低层是在UDP上模仿实现TCP的面向连接特性和可靠性并加入类似TLS的加密过程。

QUIC提供基于UDP的多路复用、有序、可靠的流传输。

QUIC是和HTTP同一层的应用层协议，其核心是将丢包控制工作转移到应用层。

这是一个对小组讨论和编辑来说是可行的文档，我们希望它发展成一个充实的设计文档。

希望设计成一个运行在UDP上的可以在两个终端（一个初始化整个连接的客户端和一个服务器端）上多路复用大量流的隧道协议。

例如，每个流几乎相当于一个独立的TCP连接。

最终的协议可能非常像运行在UDP上的SCTP，在使用加密上非常像DTLS。

3、流

流：

在一个连接中传递数据的潜在的许多数据传输信道中的一个。

一个流是双向的。

如果流被客户端首先创建（连接发起人），那么它将有一个奇数编号的流标识符。

如果流被服务器创建（连接应答者），那么它将有一个偶数编号的流标识符。

在流中的数据自动被分解成帧，然后在接收端重新组装。

在为一个多路复用流建立一个API时有一些复杂性需要解决。

在最高层次上，我们需要有一个机制增加新流到一个连接中，以及分别独立地读和写不同的流。

对每个流，我们需要一个方法来访问流，指定流应该使用的特性。

特性包括，例如，可靠性和性能权衡（例如通过增加冗余减少抖动，通过减少冗余来减少带宽）。

我们期望不同的流将有明显的传输特征，它们或许会被应用设置或修改。

这些包括明显的特征设置：

*可调冗余水平（对延迟储蓄的贸易带宽）

*可调优先级水平（仿照SPDY的演变优先级方案）

我们期望一些或许被视为输出流的控制通道将总是有用的，且可能被用于标识剩下流的状态改变。

对加密协商来说，控制通道可能包含特殊目的帧（控制帧）和一个保留的流。

在QUIC连接中的每个流将有一个独特的相关联的流标识符。

基于数据传输的字节流将仿照TCP，具有有效负载数据提供的字节范围。

字节范围将选择每个字节流中的定位。

流将被划分成帧放入（UDP）包中。

只要有可能，任何特定的数据包的有效载荷应只来自于一个流。

这将减少这种概率，一个包丢失将阻碍不止一个流的进步。

当没有足够的数据流来填充一个数据包，然后来自不止一个流的帧可能被打包进一个包。

这种包装应减少数据包计数开销，减少序列化延迟。

4、QUIC包格式

传输的基本单元将是一个标准的UDP包（又名，包）。

注意确保所有的数据传输将会被分解成刚好放入一个包的块。

包括用来协商一个连接的第一包在内的所有包，将利用AEAD加密。

第一包将利用一个默认的空加密密钥，并且AEAD将只是用来排除意外干预（作为一个高质量的校验和）。

加密协商将发生在流1，由客户端产生。

header

payload

QUIC包

QUIC包由头（header）和有效载荷（payload）组成。

其中，payload是AEAD算法认证的密文。

每个包的头包括：

*1字节的公共标识，详述头的剩下部分的设计

*全局唯一标识符

*QUIC版本

*包序列号

公共标识

全局唯一标识符

QUIC版本

包序列号

QUIC包的头部

数据包有效载荷由一系列帧组成：

头

一系列帧

FEC包有效载荷由冗余数据组成：

头

冗余数据

在解密之后，我们将有一个明文有效载荷块，它包括：

*1字节的私有标识

*FEC组号

*一系列自我标识帧

私有标识

FEC组号

一系列自我标识帧

解密之后的QUIC包的有效载荷

4.1QUIC包详解

1.头：

公共标识

在一个给定连接和给定包中，公共标识提供给每个包的其他区域的大小的说明。

2.头：

全局唯一标识符

全局唯一标识符的长度被指定为64比特，所以，客户端可以随机地选择一个全局唯一标识符，在一个固定的端口联系一个服务器，有很小的可能性会与其他连接碰撞。

然而，全局唯一标识符对于一个已经创建了一个专用的短暂的联系服务器的端口的客户端来说完全是冗余的。

客户端将在那个端口收到的包将会是单一的QUIC出口连接的一部分。

结果，客户端可能请求，一个服务器不必费心的包括每个包的全局唯一标识符。

一旦一个服务器收到一个请求（例如在连接协商期间），服务器可以使用公共标识表明，全局唯一标识符被省略（在头中的长度为0）。

对一些服务器和服务来说，并行连接关系的编号是非常有限的。

例如，一个服务器可能和一个客户端协商在一个特别的可选的IP和端口上继续那个连接。

在那种情况下，服务器也可能对客户端表明，一个更小的全局唯一标识符或许是可接受的。

3.头：

QUIC版本

我们知道，协议发展的很快，并且需要发展。

这个区域出现在第一包中，用来确保服务器可以理解客户端将提供的相同的版本。

一旦连接建立，这个是冗余的，并且公共标识将会表明这个区域被省略了（长度为0）。

如果一个服务器需要区别版本，它将记住，被全局唯一标识符定义的连接有一个与众不同的版本。

4.头：

包序列号

除了给包定序、留意副本、交流什么包丢失了，这个编号是加密的一个关键组成部分。

这个编号组成了用来解密每个包的初始化向量的基础。

结果，从概念上讲，它必须是大的，因为在连接期间，它必须绝不重复。

那个需求强迫这个序列号概念上是大的，大约2^64（比连接还要多的包等着发送），但是我们通常不需要提供每个包的8个字节！

在任何给定的时间，仅有一些有限的包序列号没有被确认。

这个限制是由这个事实的自然结果，发送者必须缓存那些未决定的包中的内部数据，并且发送者的内存是有限的。

另外，我们选择不去重传被声明为丢失的包，而是把他们的内容放入后来的数据包中。

结果，接收者常常通知，它没有收到一个包，并且发送者将通知接收者“停止等待”那个包，因此没有被确认的包的窗口将总是恰好有界的，并且不确定性（讨论的可能的最大和最小值）范围可能被发送者知道。

给予那个限制，发送者可能大大地减少需要表示包序列号（使用公共标识）的字节数。

例如，假设正在用一个像拥塞控制的TCP传输，并且目前的拥塞窗口是20个包。

即使包丢失，在1个RTT或大约20个额外包内，接收者将知道一个丢失的包不再是未判定的。

结果，发送者可以侥幸逃脱在线路上仅发送64比特包序列号的低序号字节。

接收者给予那些比特可以轻易地决定较高的56比特必须是什么，可以使用那个去解密包。

注意，如果一个非常老的包到达接收方，并且老的包序列号是被曲解的，那么AEAD认证会失败，并且老的（并且适合丢弃的）包甚至会被忽略。

5.有效载荷：

私有标识

目前1字节大小的私有标识表示“私有”，因为他们被加密覆盖，并且对窃听者是不可见的。

与公共标识一样，在标识中编码的一个值是FEC组号的大小，和有效载荷到帧的开始的隐式偏移。

私有标识还有另外2个独特的比特。

第一个比特是一个随机加密比特，第二个比特用来鉴定FEC组中的最后一个包。

FEC组中的最后一个包是冗余FEC包（包含组中的明文有效载荷的异或）。

私有标识：

加密比特

加密比特由发送者随机选择，并且放入每一个包中。

这个信息用来对抗任何潜在的乐观确认攻击。

当一个接收器发送一系列包的确认时，它需要证明它收到了那个集合，通过提供它宣称已经看见的加密比特哈希表宣称的那个集合。

加密比特的一个问题是，当一个包丢失时，它的加密比特是不可见的。

为了解决这个问题，并且不需要接收器创建无止尽的丢失包列表（来自哈希表的异常），发送者常常提供一个更新，表明哈希表相对于一个特定的数据包来说应该是什么。

例如，假设包1，2，3，4被发送了。

假设包3丢失了。

接收器将表明（在一个确认帧里），它收到了从1到4的所有包，除了包3。

确认帧也会提供一个打包1，2，3，4包的加密比特的哈希表。

发送器可以确认哈希表是正确的，并且声明包3丢失了。

然后，发送器可以传输（包括一个确认帧）它不再关注包4或者更老的包，并且它可以提供到包4为止的所有加密比特哈希表。

结果，接收器终于知道到包4为止的包的哈希表，并且当它收到下一步的数据包时可以提供额外的增值哈希表结果。

私有标识：

FEC最后的比特

这个比特用来标记最后一个包是一个FEC组。

我们现在的FEC方法在一系列受FEC保护的包的末尾恰好有一个FEC包。

这个比特表明，整个有效载荷应该单独处理，并且被视作在这个组中的其他有效载荷的异或和。

注意，当这个比特被设置时，包必须是一些FEC组的一部分，因此FEC组号也必须总是存在的。

6.有效载荷：

FEC组号

假定，我们大约看见在互联网上1%以上的包丢失，100以上且不是200个包都无损失的被接收是完全不可能的。

因为这个原因，我们决定限制FEC组不大于255个包。

我们的实验暗示，当FEC丢失时，一个10到20的受一个冗余FEC包保护的包数据序列或许是最有益的。

每20个包，有大约5%的带宽消耗，并且有一个完全可见的延迟权衡。

我们还注意到，对TCP来说，看见拥塞窗口正好低于50个包是最常见的。

因此，和重传相比，对于更大的组使用一个FEC无益于减少延迟。

因为以上分析，我们目前支持一系列连续的包的简单异或FEC，并且一字节足以鉴定一组受保护的包。

如果发送器决定保护一系列包，它使用私有标识去表明，确实有一个嵌入式的FEC组号字节。

每个FEC组的参与者有一个偏移FEC组号，它可以鉴定组中的第一个包（即，它是减去目前包序列号的一个总数）。

这种方法考虑到就什么时候结束那个FEC组的一个懒惰的决定（即，包的准确编号不需要知道，最后的FEC包可以在任何时间被加入，例如当没有数据发送时）。

7.有效载荷：

自我标识帧

每个QUIC包的块有望成为一个称为帧的数据的串行列表。

每个帧都有标识帧的主要字节，和关于帧格式与内容的信息。

例如，有些携带确认信息的帧，也有携带纯粹流数据的帧。

还有一些其他的帧。

包通常被包装成充满一个或者更多帧的数据的包然后发送出去。

帧在某种意义上来说是协议的载体.

所有的帧都以一个帧类型字节开始，但是我们希望在那个字节中包装一些额外的关于具体的每种类型的标识。

结果，它实际上是用于鉴定帧类型的一个帧类型字节的开始几个比特，其他几个比特用