QUIC
当下网络传输协议的局限性(研究点)
- Web延迟是改善用户体验的障碍
- 尾部延迟(tail latency)仍然是扩展Web平台的障碍
- 尾部延迟:是指有1%的请求耗时高于99%的请求耗时,影响用户体验,甚至拖垮服务。对于大规模分布式系统来说,尾部延迟的影响尤为严重。例如大规模搜索引擎,单个请求可能就会发送到上万台服务器,系统不得不等待尾部延迟相应返回后才能返回给用户。导致尾部延迟的原因有很多,包括争用、垃圾回收、数据包丢失、主机故障以及操作系统在后台执行的奇怪操作。
- 中间盒对传输协议的限制
- 防火墙会阻挡任何不熟悉的网络流量
- 网络地址转换器(NAT)会重写传输报头,使两端在不添加显式支持的情况下无法允许来自新传输的流量。
- 由于中间盒的限制,通过修改TCP协议来改善情况很困难。
- 在网络传输的过程中仍有很多安全漏洞,而对于已经嵌入操作系统内核的TCP协议来说修复漏洞往往伴随着操作系统的升级,而后者的升级往往具有迟滞性。这限制了即使是简单网络更改的部署和迭代速度。
- 数据需要TCP+TLS的很多结构层才能从一端到达另一端,这就造成了传输延迟的增加。而且在握手时,TCP至少会产生1次往返延时,TLS在TCP基础上又增加两次往返延时,这些都是不必要的。
- 部署Web需要更改其中的很多环节,对供应商和网络运营商很依赖。
需要完成的目标
QUIC需要完成可部署性、安全性以及减少握手和头阻塞延迟。
特性
- 基于UDP的用户空间传输协议
-
其中用户空间构建QUIC有助于将其部署为各种应用程序的一部分,并且可以在用户程序更新时随之进行版本迭代
-
基于UDP可以让QUIC允许对中间盒(Middlebox)进行遍历
- 其中中间盒是一种计算机网络设备,用于转换、检查、过滤以及其他方式操纵流量,即数据包,而不是用于包转发。常见的中间盒有防火墙、网络地址转换器。
-
使用加密传输:对数据包进行加密和身份验证。
-
使用加密握手,但是在重复连接时,若上一次会话留下的凭据没有到期的话,会直接连接以将握手延迟降至最低。
-
使用数据结构抽象将队头阻塞延迟消除。
- 这样单个数据包的丢失只会阻碍包含该数据包中数据的流。
-
效果
- Google搜索响应延迟下降
- 桌面用户下降8.0%
- 移动用户下降3.6%
- YouTube播放重新缓冲率下降
- 桌面用户下降18.0%
- 移动用户下降15.3%
部署情况
目前谷歌30%以上、全球互联网7%的流量使用QUIC协议。
过程
- 在握手之前客户端不知道服务端的信息,因此可以先发 inchoate client hello(CHLO)来引出服务端的REJ消息。