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是和同一层的应用层协 议，其核心是将丢包控制工作转移到应用层。这是一个对小组讨论和编辑来说是可行的文档，我们希望它开展成一个充实的设计文 档。希望设计成一个运行在UDP上的可以在两个终端（一个初始化整个连接的客户端和一个 服务器端）上多路复用大量流的隧道协议。例如，每个流几乎相当于一个独立的TCP连接。最终的协议可能非常像运行在UDP上的SCTP，在使用加密上非常像DTLSoa)b)c)3、流流：在一个连接中传递数据的潜在的许多数据传输信道中的一个。一个流是双向的。如 果流被客户端首先创建（连接发起人），那么它将有一个奇数编号的流标识符。如果流被服务 器创建（连接应答者），那么它将有一个偶数编号的流标识符。在流中的数据自动被分解成帧， 然后在接收端重新组装。在为一个多路复用流建立一个API时有一些复杂性需要解决。在最高层次上，我们需 要有一个机制增加新流到一个连接中，以与分别独立地读和写不同的流。对每个流，我们需要一个方法来访问流，指定流应该使用的特性。特性包括，例如，可 靠性和性能权衡（例如通过增加冗余减少抖动，通过减少冗余来减少带宽）。我们期望不同的流将有明显的传输特征，它们或许会被应用设置或修改。这些包括明显 的特征设置：*可调冗余水平（对延迟储蓄的贸易带宽）*可调优先级水平（仿照SPDY的演变优先级方案）我们期望一些或许被视为输出流的控制通道将总是有用的,且可能被用于标识剩下流的 状态改变。对加密协商来说，控制通道可能包含特殊目的帧（控制帧）和一个保存的流。在QUIC连接中的每个流将有一个独特的相关联的流标识符。基于数据传输的字节流将仿照TCP，具有有效负载数据提供的字节X围。字节X围将 选择每个字节流中的定位。流将被划分成帧放入（UDP）包中。只要有可能，任何特定的数据包的有效载荷应只来自 于一个流。这将减少这种概率，一个包丢失将阻碍不止一个流的进步。当没有足够的数据流 来填充一个数据包，然后来自不止一个流的帧可能被打包进一个包。这种包装应减少数据包 计数开销，减少序列化延迟。4、QUIC 包格式传输的根本单元将是一个标准的UDP包(又名，包)。注意确保所有的数据传输将会被 分解成刚好放入一个包的块。包括用来协商一个连接的第一包在内的所有包，将利用AEAD加密。第一包将利用一 个默认的空加密密钥，并且AEAD将只是用来排除意外干预(作为一个高质量的校验和)。加 密协商将发生在流 1，由客户端产生。headerpayloadQUIC 包QUIC包由头(header)和有效载荷(payload)组成。其中，payload是AEAD算法认证的密文。 每个包的头包括：*1 字节的公共标识，详述头的剩下局部的设计 *全局唯一标识符*QUIC 版本*包序列号公共标识全局唯一标识符QUIC版本包序列号QUIC 包的头部数据包有效载荷由一系列帧组成：头一系列帧FEC包有效载荷由冗余数据组成:头冗余数据在解密之后，我们将有一个明文有效载荷块，它包括*1 字节的私有标识*FEC 组号*一系列自我标识帧私有标识FEC组号一系列自我标识帧解密之后的 QUIC 包的有效载荷4.1 QUIC包详解1. 头:公共标识 在一个给定连接和给定包中，公共标识提供给每个包的其他区域的大小的说明。2. 头:全局唯一标识符全局唯一标识符的长度被指定为64 比特，所以，客户端可以随机地选择一个全局唯一 标识符，在一个固定的端口联系一个服务器，有很小的可能性会与其他连接碰撞。然而，全局唯一标识符对于一个已经创建了一个专用的短暂的联系服务器的端口的客户 端来说完全是冗余的。客户端将在那个端口收到的包将会是单一的QUIC出口连接的一局 部。结果，客户端可能请求，一个服务器不必费心的包括每个包的全局唯一标识符。一旦一 个服务器收到一个请求（例如在连接协商期间），服务器可以使用公共标识明确，全局唯一标 识符被省略（在头中的长度为 0）。对一些服务器和服务来说，并行连接关系的编号是非常有限的。例如，一个服务器可能 和一个客户端协商在一个特别的可选的IP和端口上继续那个连接。在那种情况下，服务器 也可能对客户端明确，一个更小的全局唯一标识符或许是可承受的。3. 头：QUIC版本 我们知道，协议开展的很快，并且需要开展。这个区域出现在第一包中，用来确保服务器可 以理解客户端将提供的一样的版本。一旦连接建立，这个是冗余的，并且公共标识将会明确 这个区域被省略了（长度为 0）。如果一个服务器需要区别版本，它将记住，被全局唯一标识 符定义的连接有一个与众不同的版本。4. 头：包序列号除了给包定序、留意副本、交流什么包丢失了，这个编号是加密的一个关键组成局部。 这个编号组成了用来解密每个包的初始化向量的根底。结果，从概念上讲，它必须是大的， 因为在连接期间，它必须绝不重复。那个需求强迫这个序列号概念上是大的，大约2人64 （比 连接还要多的包等着发送），但是我们通常不需要提供每个包的8个字节！在任何给定的时间，仅有一些有限的包序列号没有被确认。这个限制是由这个事实的自 然结果，发送者必须缓存那些未决定的包中的内部数据，并且发送者的内存是有限的。另外， 我们选择不去重传被声明为丢失的包，而是把他们的内容放入后来的数据包中。结果，接收 者常常通知，它没有收到一个包，并且发送者将通知接收者“停止等待那个包，因此没有 被确认的包的窗口将总是恰好有界的，并且不确定性（讨论的可能的最大和最小值）X围可能 被发送者知道。给予那个限制，发送者可能大大地减少需要表示包序列号（使用公共标识）的 字节数。例如，假设正在用一个像拥塞控制的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包的块有望成为一个称为帧的数据的串行列表。每个帧都有标识帧的主要字节，和关于帧格式与内容的信息。例如，有些携带确认信息的帧，也有携带纯粹流数据的帧。 还有一些其他的帧。包通常被包装成充满一个或者更多帧的数据的包然后发送出去。帧在某种意义上来说是 协议的载体.所有的帧都以一个帧类型字节开始，但是我们希望在那个字节中包装一些额外的关于具 体的每种类型的标识