(google_quic协议_)QUICDesignDocumentandSpecificationRational.docVIP

(google_quic协议_)QUICDesignDocumentandSpecificationRational.doc

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
(google_quic协议_)QUICDesignDocumentandSpecificationRational

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)实现的多路复用流协议。此外,它可以通过尽可能快地(而不是等待前面的确认返回)发送所有请求来减少延迟,并且可以通过压缩一些冗余流量来减少带宽使用。尽管其特性和成功,当提供一个延迟减少时,它在请求有效地利用资源方面遇到了一些问题。 单个包延迟导致一个流的头阻塞。因为TCP仅提供单个序列化流接口,仅仅一个包的一个延迟导致整个SPDY流的停顿。当一个包丢失时常常造成包延迟,例如因为阻塞,并且它必须被重传

文档评论(0)

xcs88858 + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

版权声明书
用户编号:8130065136000003

1亿VIP精品文档

相关文档