(google-quic协议-)QUICDesignDocumentandSpecificationRational.doc

QUIC
快速UDP因特网连接
基于UDP的多路复用流传输
引用一个著名的引语：我先为这个文档的长度道歉，如果我有更多的时间的话，我一定会写的更少一点。

第一个草案：2012-04
改进：2013-06-04

目录
概览 4
动机 4
SPDY支持动机 4
目标 5
理由和影响 6
为什么不使用基于DTLS的SCTP？ 7
基于DTLS的SCTP的连接建立延迟 7
对基于DTLS的SCTP的有效率的带宽利用 7
包丢失重传延迟 8
预期的API基础 8
API概念 8
流特征 8
有序数据传输 8
连接状态 9
协议哲学 9
通过无连接的UDP建立连接：克服NAT 9
全局唯一标识符:连接认证的关键 10
NAT绑定保持活跃 11
UDP包分片 12
连接建立和恢复 12
启动DDOS攻击 13
安全认证 13
高水平连接情况的概述 13
第一次连接：通常1RTT，有时2RTT 14
重复连接：通常0RTT，有时1RTT，很少2RTT 14
客户端IP地址所有权的证明 15
生成客户端IP地址所有者/控制的证明 15
稳定状态 16
连接结构 16
安全：抗干扰、保密、真实性 16
孤立包加密 16
包丢失 17
拥塞避免 17
对乐观确认攻击的攻击缓解 17
合理的误差校正模式 18
逐步减少包丢失 19
包丢失的重传恢复 19
积极地推测重传 20
缓冲溢出 20
本地缓存控制 20
基于流的流量控制 21
空闲进入 21
闲置离开 21
NAT表重置 22
全连接状态的延续 22
加密元素 22
保留的加密通信流 22
加密头阻塞 23
加密和认证 23
会话密钥升级 23
协议细节：规范基本原理 24
部署问题 24
备用协议头 24
初始化(连接建立)包默认 24
协议原理概览 25
帧 25
QUIC包的概括帧 25
头：公共标识 26
头：全局唯一标识符 26
头：QUIC版本 26
头：包序列号 27
有效载荷帧概览 27
有效载荷：私有标识 27
有效载荷：FEC组号 28
有效载荷：自我标识帧 29
有效载荷内的帧 29
流帧 29
确认帧 30
拥塞控制帧 31
重置流帧 31
连接关闭帧 31
消失的流帧 32
连接重置可选项 32
恶意的返回地址重写 33
加密启动概览 33
1个RTT回退 34
2-RTT的最糟糕的回退情况 34
协议术语表 35
放大攻击 35
缓存膨胀 35
连接 35
FEC 36
帧 36
全局唯一标识符 36
包 36
流 36
致谢 37

概览
这是一个对小组讨论和编辑来说是可行的文档，我们希望它发展成一个充实的设计文档。希望设计成一个运行在UDP上的可以在两个终端(一个初始化整个连接的客户端和一个服务器端)上多路复用大量流的隧道协议。例如，每个流几乎相当于一个独立的TCP连接。

最终的协议可能非常像运行在UDP上的SCTP，在使用加密上非常像DTLS。有一个关于目标和动机的一致性列表，应该允许我们决定多少这样的近似标准可以被集成，又有哪些地方需要或使用这些主题相关的创新和变更。

动机
我们希望减少整个英特网的延迟，提供一个响应性更好的用户交互环境。随着时间的推移，整个世界的带宽将会提升，但是受光速支配的往返时间不会减少。我们需要一个协议用更少的延迟和更少的重传时间消耗去传递整个互联网的请求、响应和交互，并且，我们相信现今的方法在阻碍我们。这部分指出我们希望解决的潜在问题。

序言：TCP和TLS(SSL)是传递显著成果的优秀协议。这部分将描述我们特定应用的问题和缺点，这些不应该被看做是关于这些杰出工作的一个抱怨。

IP地址和套接字对是有限资源。今天，许多连接通常被建立在客户端和服务器之间，使用大量套接字，并经常携带冗余信息。多路复用传输有可能统一流量并减少端口利用量。多路复用传输可以统一报告和响应信道特性 (比如包丢失等)，并且也允许更高层应用协议(比如SPDY)去减少或压缩冗余数据传输(比如头)。在三层负载平衡的情况下，多路复用传输有可能允许来或往于一个客户端的不同数据流量在单个服务器上服务。

对这个传输的两个初始的支持动机是更好的支持SPDY，并进一步合并流量。SPDY目前基于TCP运行，但是遇到了一点性能限制。

SPDY支持动机
SPDY是个目前基于TCP(经常使用SSL)实现的多路复用流协议。此外，它可以通过尽可能快地(而不是等待前面的确认返回)发送所有请求来减少延迟，并且可以通过压缩一些冗余流量来减少带宽使用。尽管其特性和成功，当提供一个延迟减少时，它在请求有效地利用资源方面遇到了一些问题。

a) 单个包延迟导致一个流的头阻塞。因为TCP仅提供单个序列化流接口，仅仅一个包的一个延迟导致整个SPDY流的停顿。当一个包丢失时常常造成包延迟，例如因为阻塞，并且它必须被重传。一个更好的多路复用传输应该在单个包丢失时仅延迟一个流。

b) 由TCP处理、导致额外带宽减少和序列化延迟开销的不适宜的拥塞避免：一个SPDY连接常常被用来代替K个独立(非多路复用)连接。当一个基于TCP的SPDY连接的一个包丢失时，整个连接的拥塞窗口往往降低了50%，经由TCP提供[TCP立方的默认拥塞窗口减少大约30%，但是2个因素简化了在这个段落阐述上的数学]。相反，在K个非多路复用TCP连接中的一个包丢失仅减少了在一个TCP连接中的拥塞窗口。在K个流中仅有一个损失，总拥塞窗口减少了大约之前损失总和中的1/2K。伴随K通常有一个值6(对多个HTTP GET请求来说)，一个包丢失导致带宽减少到先前损失带宽(先前损失拥塞窗口大小)的11/12。结果，TCP拥塞避免相对一个多路复用TCP连接来说更加支持分片(多个)TCP连接。
//拥塞避免，在SPDY中一个连接(多个流)常常用来代替多个连接，但是前者丢包整个连接(相当于多个连接)窗口降低，后者只是其中一个连接的窗口降低

c) TLS(SSL)会话恢复延迟。一个TLS握手在数据被成功传送前至少花费一个额外的RTT。这个延迟是TLS实现的一个功能，并且不是因为安全的功能性需求。

d) TLS往往引发一个解密依赖，先前的包必须在后来的包可以被解密之前被解密。TLS1.1和DTLS以每个包的额外字节为代价，通过增加显示的初始化向量，主要解决有序依赖问题。通过在一个新的协议里结合多个层次，我们或许能够利用其他包格式化数据，提供减少数据消耗的初始化向量(比如，包序号)。

目标
我们想要开发一个支持以下目标的传输：
1. 在今天的互联网上可广泛的部署(例如，使它通过中间盒子；没有核心改变的运行在普通用户客户端机器上或提高权限)
2. 减少因包丢失造成的头阻塞(丢失一个包通常将不会危害其他多路复用流)
3. 低延迟(在设置/恢复和响应包丢失时最小往返消耗)
a. 明显地减少连接启动延迟(通常零RTT连接，加密问候，最初的请求)
b.试图用前向纠错码去减少包丢失后的重传延迟
4. 就延迟和效率而言，对移动的改良的支持(与无线电关闭期间被拆除的TCP连接截然相反)
5. 拥塞避免支持堪比且友好于TCP(统一多路复用流)
a.单个流的流量控制，防止拥有一个快速源和慢速接收槽的一个流洪泛接收端内存，允许在发送端回压显示
6. 隐私保证堪比TLS(不需要有序传输或有序解密)
7. 在服务器端和客户端，可靠和安全的资源需求缩放(包括合理的缓存管理和旨在避免促进DoS放大攻击)
8. 减少带宽消耗和增加信道状态响应能力(通过经由所有多路复用流的信道状态的统一信号)
9. 在不与其他目标冲突时减少包数
10. 支持多路复用流(可以模拟在多路复用流上的TCP)的可靠传输
11. 在不与其他目标冲突时代理的高效率多路复用分配器属性
12. 在不牺牲我们的既定目标的情况下，在这样做是合理的任何时候重用或发展现存协议(例如，考虑uTP(节制算法)，数据报拥塞控制协议，传输控制协议这些宠儿)。
//目标2,3,6就是针对SPDY的四个缺陷的
理由和影响
现今，可行性的头号目标显然是这个协议发展的主要驱动力。中间盒和防火墙会代表性地阻塞或明显地降低基于除了TCP或UDP的格式的任何传输，明白这个以后，我们甚至不会考虑革命性的协议。

各方宁愿通过改进TCP去避免头阻塞来满足目标2(基于一个流上的包丢失的阻塞影响很多流)，但是我们发现没有明显的方法去规避TCP的有序传输接口。
修改是合理的，但是直到核心改变在合适的位置上才能够广泛的部署，这被视为一个问题。另外，更重要的TCP修改可能会被现今的中间盒(它也会花费数年去发展)阻塞。

减少包丢失时的延迟(目标3)，与TCP相比，可能主要是通过使用误差校正而不是重传来实现。另外，这样一个TCP扩展显得不合理，没有主要(缓慢的部署，或许会超过10年甚至更久)的标准TCP的修改。我们把这个协议的广泛部署看作是在1到2年内是合理的，并且希望TCP会在一个更长的时间段里相似演变。

随着移动客户端的兴起，和它们关闭一个无线电通信的趋势，会话持续的最小的往返延迟消耗会日益重要。现今，桌面用户大大的受益于更加快速的会话持续，我们希望QUIC将达到零RTT会话恢复的利用目标，包括加密谈判(大多数时间)。

拥塞避免算法对保护英特网是至关重要的。最大程度上的，我们可能会提供一个TCP友好且兼容的协议，与TCP的高度发展和广泛部署的拥塞避免方法平等共存。我们期望在敏捷性和通知上合理的提高，经由在所有多路复用流中调整过和谐性的基于全部损失的大量流提供。

SPDY发展的经验告诉我们，唯一的办法，以防止中间盒中伤一个在UDP或TCP之上的新协议(如。误解为“已知”协议，修改“更没有帮助性的”)，是加密尽可能多的有效负载和控制结构。因此，我们计划采用包括抗干扰、隐私、重放保护、和身份验证的安全原理，那类似于TLS(或者DTLS)提供的。

压缩不会直接纳入传输，除了堪比SPDY的头压缩，因为传输可能没有意识到在各种数据片段间的隐私/敏感性限制，且不必揭示(通过流量分析)孤立数据组的相似性。SPDY目前的“连续自适应”头压缩是小问题，因为“其他流”的头直到所有之前头(被送入进化压缩上下文)已收到才能被解压。QUIC最初可能在这些压缩包中以头阻塞为代价支持这种类SPDY头压缩，但是我们应该能够尝试减少这种依赖性的改变。考虑到这种类SPDY头压缩的有效性，通常的情况是，很少有数据包会包含头文件，进一步减轻潜在的缺点。

隐私机制需要合并到有包边界的仔细对齐加密阻塞，或者至少保护字节范围的冗余，所以包丢失的延迟影响会最大限度地被遏制。注意，如果这些边界不一致，那么一个包丢失可能有效地排除破译相邻数据包，对延迟有不良影响。

为什么不使用基于DTLS的SCTP？
一个反复出现的问题是:为什么不使用基于DTLS(数据包传输层安全)的SCTP(流控制传输协议)？SCTP提供(在其他事物之中)多路复用给流，且DTLS提供一个基于UDP流的质量加密和认证给SSL。除了这样一个事实，这些协议都是在不同的标准化层次，这种组合目前在标准轨道，并描述了在这个网络工作组互联网草案。

使用这些协议的最大的可见的问题与我们在连接延迟领域的目标有关，且可能是最关键的冲突元素。此外，我们也可以预见，带宽效率的问题可能降低我们实现QUIC目标的能力。

基于DTLS的SCTP的连接建立延迟
QUIC的主要的和可信的实现目标之一主要是建立零RTT的连接，就像在上文目标3中提到的。基于DTLS的SCTP最终是否能实现那个目标是被高度怀疑的。

SCTP和DTLS目前是作为分层协议实现，一个在另一个之上，已经挑起整个连接的延迟，那是两个连接延迟之和。这个在草案的5.1节可以看到，那儿记载：
*一个DTLS连接必须在一个SCTP连接建立之前被建立。

在任何数据传输之前的连接建立中，流控制传输协议好像需要1个完整往返。关于这个需求的一个讨论，参见SCTP RFC4960的章节5。

DTLS似乎在连接建立时大约需要3个往返。DTLS模仿TLS，TLS在连接建立时默认为2个RTT问候交流 。就像在DTLS的描述中的8.1节所指出的：DTLS通常使用一个完整的3个往返来协商一个连接(包括cookie交换)。那部分指出：3个往返堪比一个基于TCP的TLS连接建立，如果TCP的连接RTT有2个TLS 问候的RTT积累。

因此，具有以上基线连接往返，我们可以期望大约4个往返的消耗建立一个基于DTLS连接的SCTP。相反，我们期望能够用零 RTT开销去执行一个QUIC连接建立。对QUIC最糟糕的情况是利用相似于SSL错误开始的方法而得到的一个RTT开销。

一些基于DTLS的SCTP的连接开销能够被减少是合理的，但是在没有主要改变和合并协议时一个竞争性的启动延迟能够实现且QUIC的目标能够实现是备受怀疑的。

对基于DTLS的SCTP的有效率的带宽利用
基于DTLS的SCTP所在的层使最有效率的利用在UDP包中的带宽更加困难。例如，SCTP传输传送数据到有序包和数据范围。同时，DTLS需要分别传输加密初始化向量形式的不同包信息，用于包加密。集成协议，如QUIC，可以为流协议利用的排序信息，作为包加密的初始化向量的基础。这个集成的结果是减少包开销。我们预计，这种集成将在多个额外地方节省数据空间，特别是增加包效率。[TBD:我们应该提供每包的具体收获和字节数去充实这个论点]。

包丢失重传延迟
目标3暗示，我们应该尝试通过利用FEC码减少重传延迟。DTLS和SCTP目前都没有使用FEC的规定，且这似乎是一个非常重要的尝试去合并这些的修改。有些努力去增加SCTP下的FEC，所以它或许是合理的，但是它肯定是一个当前定义的显著并发症，包丢失肯定会倾向于引起这些协议的重传延迟，尽管它会限制(由SCTP提供)单个流(至少实现目标2)。

预期的API基础
API概念
在为一个多路复用流建立一个API时有一些复杂性需要解决。在最高层次上，我们需要有一个机制增加新流到一个连接中，以及分别独立地读和写不同的流。

对每个流，我们需要一个方法来访问流，指定流应该使用的特性。特性包括，例如，可靠性和性能权衡(例如通过增加冗余减少抖动，通过减少冗余来减少带宽)。
流特征
我们期望不同的流将有明显的传输特征，它们或许会被应用设置或修改。这些包括明显的特征设置：
*可调冗余水平(对延迟储蓄的贸易带宽)
*可调优先级水平(仿照SPDY的演变优先级方案)
我们期望一些或许被视为输出流的控制通道将总是有用的，且可能被用于标识剩下流的状态改变。
对加密协商来说，控制通道可能包含特殊目的帧(控制帧)和一个保留的流。

有序数据传输
现有代码肯定需要类似于TCP的可靠和有序传输的服务。因此，我们需要一个可以极大模仿一个标准TCP套接字的流的一个API。这将允许一个多路复用流用有希望地微小修改，实验性地使用几乎任何存在的应用。我们希望这个API模仿SPDY提供的接口，屏蔽内部包丢失，提供每个有序的并且独立于其他流传输的流的数据。

连接状态
一个应用和实际的连接间的分离历来使连接的使用困难。例如，当一个发送应用结束发送，它或许尝试关闭连接，但是数据或许依然在本地排队且没有发送(或许没有应答，因此发送缓冲区不能被丢弃)。这样的例子产生竞赛，当关闭一个连接或终止一个应用时或许会导致未定义的行为。

为了更好地支持一个对应用的有效且紧密的绑定。下面的当前数据统计是合理地期望对应用可见：
1. RTT(当前平滑估计)
2. 包大小(包括所有开销；也不包括所有开销，仅包括有效载荷)
3. 带宽(贯穿于整个连接的当前平滑估计)
4. 持续峰值带宽(贯穿于整个连接)
5. 拥塞窗口大小(在包中的表示)
6. 队列大小(已经形成但还未通过电线发出去的包)
7. 字节队列
8. 每个流队列大小(不是每个流的字节就是未发出去的包，或者都是？)

通知也应该被提供，或访问下列事件[通知的粒度是待定，且不应该有通知的及时性要求，但是任何通知或状态应该包括一个那个真实事件发生时间的最好估计]：
1. 队列大小已经降到0
2.收到了所有必需的确认(连接或许会在没有传输状态损失情况下关闭)
a. 特殊包的确认已被接收(不是所有流支持这个[这应该是一个请求而不是通知？])

协议哲学
协议有四个阶段，我们需要考虑性能效率：启动，稳定状态，闲置进入，闲置离开。一个关键因素是减少启动(连接建立)期间的延迟，特别是重新开始的情况下。当大量流保持整体连接尽可能如拥塞避免允许的完整时，第二个挑战是确认在稳定状态下的有效的和低延迟的性能。第三个挑战是有效地且低延迟地确认平稳过渡到一个空闲状态，这时没有流提供数据，但是连接完全建立。过渡是明显的，TCP包丢失的尾部包丢失历来发生显著延迟，特别当最后一个包丢失时，发送端超时需要重新发送丢失的数据。

通过无连接的UDP建立连接：克服NAT
一个最基本的问题是怎样将UDP转换成一个基于连接的协议。这个问题被没有帮助作用的中间盒和防火墙NAT服务加剧了，且实际上会阻碍这一过程。

例如，考虑一个中间框的情况下，如防火墙和NAT，决定不再支持一个特定的TCP连接。中间框可以发送一个TCP 重置(连接重置)到两端作为一个断开连接通知的一部分。相反，当一个NAT服务决定丢弃一个使用UDP流量的绑定，没有通知，因为一个UDP数据报不希望是一个“连接”。一旦一个UDP NAT释放发生，外部端点(通常是一个服务器)无法发送流量到客户端。更糟的是，来自服务器的流量通常是黑洞，没有否定确认响应。对TCP，试图使用一个未绑定端口可能导致至少一个堪比否定确认的重置。作为进一步的并发症，如果一个NAT端口未绑定发生，然后客户端发送额外的UDP流量，NAT服务可能创建一个新绑定。新端口绑定可能有不同的源端口(在服务器看来），尽管QUIC需要把流量看作一个现存连接的持续。

目前的估计表明，对现在已部署的 NAT盒来说，在30到120秒的空闲时间之后释放一个UDP端口映射是非常常见的，并且释放可能会很快发生。早期释放可能是由于LRU NAT表驱逐，或各种各样的“弱”实现，如伪随机哈希表驱逐。这两种释放活动对我们的协议来说是有问题的，必须处理好。在未来，可能RFC 4787会迫使最小超时为120秒，默认超时为5分钟，但这都是未来推测验收和部署，我们需要处理今天的中间框。

客户端和服务器之间最期待的流量是一个客户机请求的形式，其次是服务器响应。结构表明，(不成熟的)NAT释放可能不是至关重要的。不幸的是，有许多服务器响应因为时间延长期而被延迟的情况，包括服务器返回端响应时间。作为一种常见的且更极端的例子，通过Chrome的统计数据表明，大约所有HTTP GET连接中有0.5%在连接被打开后60秒才接收响应。这样的延迟被认为是由“悬挂”造成。我们的协议需要小心处理这些服务器端停顿，但是仍然允许服务器响应在一个打开流上的(延迟)数据。

NAT转换的一个基本原理发生在局域网边界。除非客户端建立一个经过NAT的出站连接，服务器通常没有办法联系(响应?)一个客户端，除非利用UPnP这样的服务。假定PCP(端口控制协议:RFC 6887)支持是不普遍的，我们将设计不依赖于这些服务的协议。在客户端，我们将检查该服务的存在，并在可用时使用它。随着我们发展QUIC，我们需要进行实验，看看UPnP或PCP多久存在一次，以及它运行多久。

全局唯一标识符:连接认证的关键
假定NAT服务在整个连接期间可以改变可见广域网的源端口(通过释放，重新绑定)，很明显，源IP地址和源端口是完全不足以定义一个连接的。我们通过通常持续于连接的整个周期的全局唯一标识符(全局唯一标识符)克服任何此类混淆。全局唯一标识符预计将是一个全局惟一的伪随机生成器(当前大小是64位)。通常提议全局唯一标识符放在第一个由客户端发往服务器的UDP包中，在整个连接周期被交换的所有未来包中显式或隐式存在。这是连接定义的关键。

服务器可以使用该全局唯一标识符作为一个键去识别特定的连接，其中的许多入站连接发送UDP数据包到单个服务器端口。服务器也使用全局唯一标识符恢复使用AEAD的当前会话加密上下文(用相关数据认证加密)。这种情况下概念上包括一个加密密钥，以及验证密钥。(注意:包的可变部分，例如源端口等，不包括在相关数据验证中)。

NAT绑定保持活跃
如上所述，NAT端口绑定可能被一个NAT服务丢弃而不另行通知。对这样一个丢弃的唯一补救措施是从客户机发送额外流量到服务器，重新建立一个活跃的NAT端口映射。如果有任何服务器可能试图向客户机发送流量的机会，端口绑定必须主动重建，有理由相信现有的端口绑定已经被丢弃(超时)。

端口绑定的主动建立是昂贵的，因为它可能是在没有“真正的”流量发送时完成的。对移动设备来说，保持活跃传输可能是特别有问题的，因为他们可能影响功耗。因此，应该尽量减少保持活跃传输的频率和这种持续活跃的绝对计数。

保持活跃：什么时候需要？
为了简化我们什么时候需要保持连接的活跃这个问题，我们假设至少一个多路复用流在连接上是开放的时候，服务器仅发送流量到客户端。因此，如果一个连接被用于从服务器到客户端的自发传输，流必须保持开放。

保持活跃：需要多久一次？
在某些情况下，来自服务器的入站流量可能足以使一个NAT绑定保持活跃，但是一些NAT服务器需要来自客户端的出站数据包去重置表条目过期时间。如果旧的绑定已经过期，出站包也可以用来重新创建一个NAT绑定，因此可以解决任何可能是由于错误读写周期造成的问题。

其他基于UDP的协议，比如音频和视频流，经常大约每15秒发送UDP持续活跃包。我们需要实验确定基线超时，适应我们感觉到的环境。

为了监控持续活跃的效力，在一个算法断定(或协商)空闲(从最后一个客户端包传输起)时超时后，服务器会自动发送一个保持活跃的探测。客户端将保持一个相应的定时器，并在时间已经过期时被提醒，且一些额外的时间已经过去了(如，额外的时间可能是一个或多个估算RTTs)。客户机将确认探测包的到来或在它应该已经到达不久后有效否定确认预期的探测包。在这两种情况下，客户端会发送一个数据包，并确保NAT绑定被恢复了。由于这一过程中，端点可以缩短超时间隔(在一个否定应答之后)，或可能延长间隔(在一个确认后)。自适应过程应该聚集在明显的NAT超时，但可以强制不超过一些限制，以免为攻击者提供一个DOS向量。

确切的算法待定。持续活跃超时也可以协商(例如：服务器可能认出带有一个有长生存期表的NAT服务的一个移动网络)，或者可能从之前的连接坚持。一些真实世界的实验后，我们可能会判定在某些环境中的一些客户端不适合使用QUIC，因为他们的持续活跃需求对一个或两个端点来说是不可容忍的。

UDP包分片
在单个链路上大于MTU的UDP数据包有在IP层被分片的风险。我们是否把我们所有的数据包标记为“不分片”是待定的，如果超过MTU的话，这将导致的一致的包损失。本节讨论一些利弊和可能的方法。最关键的预期实现是，在今天(和明天)的互联网上的分片逐步变得越来越普遍。结果，这部分可能不怎么重要，在这个问题上的任何/所有的决策可能证明是可行的。

当一个包在IP层分片时，初始包将继续持有UDP源和目标端口说明符，以及一个全局唯一标识符，但所有后面的分片将缺乏这样的识别信息。重新组装的惟一手段将是IP层的“识别”字段，它只有16位长度。因此，如果超过(大约)2 ^ 16的平方根的包同时在传输，碰撞(和破碎的重新组装)的概率将是巨大的。例如，当连接窗户超过约256包，可能会有冲突。

即使有效的拥塞窗口是“小的”(远低于256包)，NAT路由器可能管理许多单独的到一个服务器IP地址(来自路由器的IP地址)的连接。收集可能一次轻易有超过256包在传输，争夺唯一的IP标识符，煽动重组碰撞(如果分片)。

碰撞，可能基于相同的MTU边界，将(面对包重新排序)，几乎不可能重新组装正确。因此，接收方要么放弃重新组装工作(在一些分片包的一部分)，要么它将提供一个错误的重新组装。错误组装的包将被探测为被一个认证过的哈希表歪曲了。因此，重新组装错误不会导致比丢弃可能分片了的包更坏的协议错误。

分片可能影响带宽利用率，可能挥霍地花费一个目标服务器的时间。考虑到重组的冲突几乎一定存在，如果我们有任何重要的分片，可能需要排除分片，避免浪费在服务器上重组的努力。另一方面，如果这个问题是微乎其微的，更好的覆盖和支持间歇分片可能是可取的。

目前，操作系统API不允许一个应用层代码探测这个事实，IP分片已经发生。我们可能试图增强我们的服务器操作系统支持，以便检测分片。有这样一个API，我们可以尝试在任何可见的MTU限制内运行。这种方法将习惯性的避免倾向于“路径最大传输单元探测”错误，而是观察和响应呈现真实UDP数据包的行动。[待定：攻击者可能会选择断断续续的分片一些数据包，以便使我们协商出一个较小和低效率的MTU。我们会发现这样的结果是不可接受的。如果是这样，我们可以在全局下降来适应MTU，或降低来促进传输或分片包的重组。]

连接建立和恢复
最小化启动时的延迟，加快第一次接触时的数据响应，第一次通过QUIC发送的数据包通常会包括会话协商信息以及一个或多个请求。QUIC目的是推测性地假设客户端有可接受的至少需要一个初步加密请求的加密证书，它有足够的不需要反分布式拒绝服务挑战的连接凭证，而且它有足够的新证据表明重播攻击可以排除。如果服务器拒绝接受凭证，比得上TCP会话建立或SSL问候协商的额外的反复协商就会接踵而来。

启动DDOS攻击
关于快速启动的一个已知的问题是拒绝服务攻击。在这种攻击中，恶意客户端可能会提供一个错误的返回(响应)地址，并可能会导致服务器耗尽重要的计算资源，和/或发送重要的流量给一个第三方地址。从历史观点上说，这些对TCP服务器的攻击已通过要求一个额外的往返(确认返回地址)和同步cookie的利用被避免。最近围绕具有TCP快开放的TCP进行的扩展工作试图答应改良TCP的方案，使TCP包括在初始同步包中的数据，具有对DOS攻击的合理的可接受的控制。

QUIC将不得不解决连接证书期满的问题，和/或其他机制来阻止重放攻击使用这些凭证。我们希望设计的协议，包括密码恢复，像TCP快速打开协议一样强健并且能处理这样的攻击。当一个服务器被攻击或出现过载时，论文包括源IP(基于以前的连接历史)所有权的证明和到3次握手式连接的自动回退 (re:增加一个额外的RTT)。我们的协议始终包括端到端加密的这个事实使我们确信，所有权凭证不可能简单地通过偷听被偷走。

安全认证
客户机应该在与上述服务器的先前联系中保留关于一个服务器的信息。保留的信息应该至少足以支持TLS会话恢复的模拟，还应该包括服务器信息，比如服务器最近使用的公钥(历史性地保存在一个证书里，用一个到可信根的关联链)。客户应该推测性的假设，最后的已知服务器公钥仍在使用(除非有证据表明撤销或更换)，并尝试利用这些信息实现加密初始载荷转移(请求)的一个零RTT传输。

支持加密的没有往返的服务器将随机性添加到连接中，要求服务器维护状态以避免重放攻击。该状态可以通过假设一定数量的时钟同步及时被限制，在太空，给客户端一个ID标识碎片(称为一个快速启动的轨道)。服务器可能无法建立连接的唯一性，在这种情况下，客户机必须准备再加密和重传它乐观发送的每件事。

同样地，如果服务器密钥已经改变，客户端将不得不重加密和重传乐观的初始的数据流量。

在一个零RTT设置中的初始流量可能没有想象中安全，所以我们应该假设连接将升级到一个真正的在同一连接上的后续流的临时密钥。尽管支持0­RTT连接建立的默认设置应该是默认的，服务器应该可能坚持，只有完全向前安全加密用于甚至最初的流量。

高水平连接情况的概述
本节旨在概述QUIC连接通常会如何进行。我们将着重概述导致每种情况的RTT数量。我们还将提供一些用来减轻可能发生的袭击的细节的动机。

在所有情况下，服务器可能选择强制退回到一个较慢的连接情况，当超载或者可能遭受DOS攻击时。在某些情况下，一台服务器可能选择投机地经受被攻击微创的风险，尤其是当攻击的成本仅限于消耗计算资源的服务器端，且服务器轻负载的。下面的描述试图最大限度地防止第三方在连接形成期间遭受反射攻击。其他部分将解决在稳定和漫游状态时的第三方攻击。

第一次连接：通常1RTT，有时2RTT
在这个场景中，客户端联系服务器，它的初始化问候消息表明，客户端从未访问服务器，因此它不能推测公钥。来自客户端的最初的消息可能包括一些加快一个会话协商的随机性。整个客户端消息将适合一个包，并且应该填补/填充这包。通过填写第一个客户端生成的包，我们保证服务器会发送一个完整的响应数据包，而且它通常不会超过客户端的第一个包。这个完整包还将提高任何攻击者(提供一个错误的返回地址)的带宽成本，减少可能存在的任何反映放大的可能性。同时，对一个可靠的客户端来说，这个满包的成本可以忽略不计，这应该很少使用这个连接策略，并将立刻改变会缩短少数额外用来填充第一个包的字节的数据。

服务器会回复一个服务器证书，该证书通常可以装进一个包。典型的证书大小是1­1.5 kB，例如谷歌目前的证书大约是806字节。为了最小化这个服务器响应的大小，服务器将只包括证书的散列链(而不是证书链中的完整证书列表)。最小化这个服务器响应减少(或消除)任何反射放大可能。发送证书的散列链作为一个猜测，客户端可能能够解码散列值，然后验证链。此外，服务器包括的正确响应相当于同步 Cookie，它是一个生存短暂的证明，收件人控制目标客户端源IP和端口。注意，它是非常短暂的，因为它是不受阻碍地发送的，并可能被恶意第三方盗用。

当客户端收到上面的包，它可以尝试验证服务器证书。验证证书的第一步是解码证书链散列。如果客户无法充分地解码证书链散列，或证书链似乎没有验证服务器证书，然后客户端进入2 RTT的情况，并为了全面阐述证书链而被迫发送一个请求到服务器。随着请求发送的还有同步Cookie，它允许服务器安全地将额外的数据包发送到客户机(没有误导放大攻击的风险)。

最终(1或2个往返之后)，客户端将有一个经过身份验证的服务器证书，也有一个短暂生存的同步 Cookie模拟。有了这些信息，客户端可以进入到下面描述的0 RTT情况，并被立即作为可信的客户端返回的IP地址和端口所有者。额外的熵可能已经被交换，这可能加速或允许加密协商，但这不是概述的关键。

重复连接：通常0RTT，有时1RTT，很少2RTT
在一个重复连接中，客户端将推测，服务器仍然使用那个可见且验证过的服务器证书。此外，客户端可能拥有证明，它控制了它的返回IP地址和端口。证明可能包括在上面的“首次连接”一节中描述过的SYN Cookie的模拟，也可能包括一个TCP快速打开cookie的模拟，这是生存更长的(有效期在更长的时间内)。

为了继续此连接，客户端会建造一个消息的TLS会话主秘钥的模拟。在SSL快速启动中使用的技术将用于这个结构，以减轻重播攻击。也包括在这个构造中的(加密)消息将是控制客户机的IP地址的“证据”，以及任何QUIC可转让项目，例如提出的拥塞避免算法等。加密的证据(如TCP的快速打开cookie模拟)将确保一个偷听者不能偷和滥用这样的证据。

上面的加密问候消息将发送一个包到服务器。发送之后，客户端可以加密、验证和发送额外的数据包，如被要求开放流，发出请求，等等。(为了减少包丢失的影响，也可能会推迟整个连接建立，这些包可能发送不止一次。例如，它可能是，加密的问候数据包将被发送，然后是数据包，然后重新发送加密问候包(可能经过轻微的踱步的延迟呢?)，然后重新发送数据包。待定：我们可能使用一些重传逻辑和比平时短的超时设置。)

当接收器获取加密问候包时，它将评估其内容。如果被猜测的服务器公钥不再使用，或消息提出的谈判结果不被服务器所接受，那么服务器可能拒绝数据包的内容，而把它作为上面所描述的相同的“第一次连接”。在这种情况下，利用提议的主秘钥后到达的数据包将被丢弃(没有办法在服务器端解密)。

如果公钥仍然是可以接受的，问候消息是可以接受的，那么客户机的IP和端口的控制证据是被接受的。在普通情况下，证明了控制客户机的IP是足够的，接下来的数据包可以解密、加工和采取行动(就像一个TCP信道后完成了SYN + ACK往返后我们处理一个HTTP GET 一样)。

客户端IP地址所有权的证明
客户端IP的所有权证明是不够的几个原因。许多这些原因与服务器多忙以及在资源利用攻击下的可能性有多大有关，这可能会提高或降低证明的标准。同样，如果证据更旧，它可能被视为不值得信赖的。最后，如果证据没有直接适用而是一个“附近IP”的证明(实际IP证明备用IP)，那么它可能被视为比一个更加远的相关IP的证明更加值得信赖。如果证明不足够信任，那么服务器可能发送一个拒绝(探测)包，以确保客户端返回的IP和端口是真实的。

生成客户端IP地址所有者/控制的证明
在一个连接中，一个QUIC服务器可能创建并发送一个声明，客户正在一个特定的时间使用一个特定的IP地址和端口。这样的声明将包括一个由服务器秘诀生成的MAC，这样服务器就可以验证这一说法的0­RTT“重复连接”证明。服务器可能会推动这个语句(具有最近的时间戳)在这个连接中的更新。

客户端可以组装一个或多个这样的不同的IP地址证明列表。例如，它可能获得被家庭WIFI防火墙使用的IP所有权的证明，以及在一个3G移动连接中使用的IP地址。在漫游的情况下似乎是合理的，或可能的，客户端可能为服务器提供一个带有多个预期未来漫游的所有权证明。当服务器提前意识到可能漫游(和可能发挥作用的特定IP地址)，它通常可以立即回复客户返回的IP地址的改变，没有拖延执行调查的过渡。

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

基于数据传输的字节流将仿照TCP，具有有效负载数据提供的字节范围。字节范围将选择每个字节流中的定位。

连接结构
流将被划分成帧放入(UDP)包中。只要有可能，任何特定的数据包的有效载荷应只来自于一个流。这样的奉献将减少这种概率，一个包丢失将阻碍不止一个流的进步。当没有足够的数据流来填充一个数据包，然后来自不止一个流的帧可能被打包进一个包。这种包装应减少数据包计数开销，减少序列化延迟。

安全：抗干扰、保密、真实性
给定一个包，我们需要一种方法来识别加密上下文。上下文将被关联到出现在每一个(UDP)数据包中的全局唯一标识符。

数据包将被在加密上下文中使用共享密钥的AEAD(与相关数据验证加密)保护。我们预计在每个数据包大约需要8个字节的认证开销，但细节待定，基于艺术标准的状态。

每个数据包需要一些用于加密的初始化向量字节。现时标志需要每一个数据包是唯一的。AEAD算法将被选择用来做一个简单的计数器(即，必须是唯一的，但初始化向量的可预测性是可以接受的)，并将基于数据包序列号。

我们应该提供支持分组打包以减少流量分析的易损性。在这一点上，反流量分析可能没有被充分理解怎样设计使用这种能力的对策。

安全协议应该旨在往