(google_quic协议_)QUICDesignDocumentandSpecificationRationalQUIC
快速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)实现的多路复用流协议。此外,它可以通过尽可能快地(而不是等待前面的确认返回)发送所有请求来减少延迟,并且可以通过压缩一些冗余流量来减少带宽使用。尽管其特性和成功,当提供一个延迟减少时,它在请求有
(google quic协议 )QUICDesignDocumentandSpecificationRational 来自淘豆网m.daumloan.com转载请标明出处.
