又值一年一度的“双十一购物节”之际,大家都在乐此不疲的聊着大流量高并发场景下的处理解决方案。
提到抢购,总结就一个“快”字,筛选要快,下单要快,付款要快... 一切顺利操作之后,才有可能秒到足够便宜的好货。今天我们也围绕着“快”,来跟大家聊一下低时延利器:QUIC。
在介绍QUIC之前,我们先来做个性能对比试验:我们来分别ping 一下“大型购物”网站:www.taobao.com 和 “大型程序员交友”网站:github.com
经我们试验发现:taobao 耗时在几十ms级别,而github 却在上百ms级别。
那为什么会有这样的差异呢?我们来分析一下其中存在的原因:
网络和延时的消耗大概分以下几类:
我们知道光速:30万公里/s,从北京-纽约的距离大概1.4w公里,那往返一次需要花费:107ms。
48TTL,经过16跳路由,每一跳都要处理时间且可能会丢包(大概15%丢包率)
光 - 电信的转换消耗
例如:内容审查等等
TCP提供一种面向连接的、可靠的字节流服务,其中可靠的保证方法之一就是让从另一端收到的数据。但是数据和确认信号都有可能丢失。
名词解释:
RTT(Round Trip Time):一个连接的往返时间,即数据发送时刻到接收到确认的时刻的差值; RTO(Retransmission Time Out):重传超时时间,即从数据发送时刻算起,超过这个时间便执行重传。
RTT和RTO 的关系是:由于网络波动的不确定性,每个RTT都是动态变化的,所以RTO也应随着RTT动态变化。
网络抖动会引起丢包重传,约2-5倍的RTT。
具体介绍请参考:https://blog.csdn.net/whgtheone/article/details/80970292
HTTPS 请求存在一定的性能损耗,大致分布如下:
完成整个HTTP请,总计消耗量约:4.5RTT。
QUIC 是 Quick UDP Internet Connections 的缩写,谷歌发明的新传输协议。与 TCP 相比,QUIC 可以减少延迟。QUIC 协议可以在 1 到 2 个数据包(取决于连接的服务器是新的还是已知的)内,完成连接的创建(包括 TLS)。
主要的特点包括:
从表面上看:QUIC 非常类似于在 UDP 上实现的 TCP + TLS + HTTP/2。
由于 TCP 是在操作系统内核和中间件固件中实现的,因此对 TCP 进行重大更改几乎是不可能的(TCP 协议栈通常由操作系统实现,如 Linux、Windows 内核或者其他移动设备操作系统)。
修改 TCP 协议是一项浩大的工程,因为每种设备、系统的实现都需要更新。但是,由于 QUIC 建立在 UDP 之上,因此没有这种限制。
和 TCP 相反,UDP 协议是无连接协议。客户端发出 UDP 数据包后,只能“假设”这个数据包已经被服务端接收。这样的好处是在网络传输层无需对数据包进行确认,但存在的问题就是为了确保数据传输的可靠性,应用层协议需要自己完成包传输情况的确认。
QUIC 与现有 TCP + TLS + HTTP/2 方案相比,有以下几点主要特征:
1)利用缓存,显著减少连接建立时间;
2)改善拥塞控制,拥塞控制从内核空间到用户空间;
3)没有 head of line 阻塞的多路复用;
4)前向纠错,减少重传;
5)连接平滑迁移,网络状态的变更不会影响连接断线
从图上可以看出,QUIC 底层通过 UDP 协议替代了 TCP,上层只需要一层用于和远程服务器交互的 HTTP/2 API。这是因为 QUIC 协议已经包含了多路复用和连接管理,HTTP API 只需要完成 HTTP 协议的解析即可。
QUIC 协议开创性的使用了 UDP 协议作为底层传输协议,通过各种方式减少了网络延迟。
相信 QUIC 能够可以在不远的未来,开启通讯行业发展的新时代。
虽然目前 QUIC 协议已经运行在一些较大的网站上,但离大范围普及还有较长的一段距离,期待 QUIC 协议规范能够成为终稿,并在除了谷歌浏览器之外的其他浏览器和应用服务器中也能够实现。