详细的QUIC.doc

QUIC的提出 SPDY是个目前基于TCP(经常使用SSL)实现的多路复用流协议。此外，它可以通过尽可能快地(而不是等待前面的确认返回)发送所有请求来减少延迟，并且可以通过压缩一些冗余流量来减少带宽使用。尽管其特性和成功，当提供一个延迟减少时，它在请求有效地利用资源方面遇到了一些问题。 单个包延迟导致一个流的头阻塞 由TCP处理、导致额外带宽减少和序列化延迟开销的不适宜的拥塞避免 TLS(SSL)会话恢复延迟 TLS往往引发一个解密依赖，先前的包必须在后来的包可以被解密之前被解密 我们希望减少整个英特网的延迟，提供一个响应性更好的用户交互环境。随着时间的推移，整个世界的带宽将会提升，但是受光速支配的往返时间不会减少。我们需要一个协议用更少的延迟和更少的重传时间消耗去传递整个互联网的请求、响应和交互，并且，我们相信现今的方法在阻碍我们。这部分指出我们希望解决的潜在问题。 我们想要开发一个支持以下目标的传输：减少因包丢失造成的头阻塞，低延迟，隐私保证堪比TLS，等等。 现今，可行性的头号目标显然是这个协议发展的主要驱动力。中间盒和防火墙会代表性地阻塞或明显地降低基于除了TCP或UDP的格式的任何传输，明白这个以后，我们甚至不会考虑革命性的协议。所以，只有开发基于TCP或UDP的协议，用来解决我们遇到的问题以及实现我们的目标。 由于基于DTLS(数据包传输层安全)的SCTP在建立连接时需要的延时太长，大约为4个RTT，所以SCTP是不合适的。因此，我们开发了基于UDP的QUIC协议。 QUIC协议的层次 可以认为QUIC是为了解决SPDY在TCP遇到的瓶颈而在UDP上做探索所设计的方案。参考SPDY来理解，可认为QUIC的传输内容分两层，高层类似SPDY，低层是在UDP上模仿实现TCP的面向连接特性和可靠性并加入类似TLS的加密过程。 QUIC提供基于UDP的多路复用、有序、可靠的流传输。QUIC是和HTTP同一层的应用层协议，其核心是将丢包控制工作转移到应用层。 这是一个对小组讨论和编辑来说是可行的文档，我们希望它发展成一个充实的设计文档。希望设计成一个运行在UDP上的可以在两个终端(一个初始化整个连接的客户端和一个服务器端)上多路复用大量流的隧道协议。例如，每个流几乎相当于一个独立的TCP连接。 最终的协议可能非常像运行在UDP上的SCTP，在使用加密上非常像DTLS。 流 流：在一个连接中传递数据的潜在的许多数据传输信道中的一个。一个流是双向的。如果流被客户端首先创建(连接发起人)，那么它将有一个奇数编号的流标识符。如果流被服务器创建(连接应答者)，那么它将有一个偶数编号的流标识符。在流中的数据自动被分解成帧，然后在接收端重新组装。 在为一个多路复用流建立一个API时有一些复杂性需要解决。在最高层次上，我们需要有一个机制增加新流到一个连接中，以及分别独立地读和写不同的流。 对每个流，我们需要一个方法来访问流，指定流应该使用的特性。特性包括，例如，可靠性和性能权衡(例如通过增加冗余减少抖动，通过减少冗余来减少带宽)。 我们期望不同的流将有明显的传输特征，它们或许会被应用设置或修改。这些包括明显的特征设置： *可调冗余水平(对延迟储蓄的贸易带宽) *可调优先级水平(仿照SPDY的演变优先级方案) 我们期望一些或许被视为输出流的控制通道将总是有用的，且可能被用于标识剩下流的状态改变。 对加密协商来说，控制通道可能包含特殊目的帧(控制帧)和一个保留的流。 在QUIC连接中的每个流将有一个独特的相关联的流标识符。 基于数据传输的字节流将仿照TCP，具有有效负载数据提供的字节范围。字节范围将选择每个字节流中的定位。 流将被划分成帧放入(UDP)包中。只要有可能，任何特定的数据包的有效载荷应只来自于一个流。这将减少这种概率，一个包丢失将阻碍不止一个流的进步。当没有足够的数据流来填充一个数据包，然后来自不止一个流的帧可能被打包进一个包。这种包装应减少数据包计数开销，减少序列化延迟。 QUIC包格式 传输的基本单元将是一个标准的UDP包(又名，包)。注意确保所有的数据传输将会被分解成刚好放入一个包的块。 包括用来协商一个连接的第一包在内的所有包，将利用AEAD加密。第一包将利用一个默认的空加密密钥，并且AEAD将只是用来排除意外干预(作为一个高质量的校验和)。加密协商将发生在流1，由客户端产生。 header payload QUIC包 QUIC包由头(header)和有效载荷(payload)组成。其中，payload是AEAD算法认证的密