又值一年一度的“双十一购物节”之际，大家都在乐此不疲的聊着大流量高并发场景下的处理解决方案。
提到抢购，总结就一个“快”字，筛选要快，下单要快，付款要快... 一切顺利操作之后，才有可能秒到足够便宜的好货。今天我们也围绕着“快”，来跟大家聊一下低时延利器：QUIC。
1. 性能对比试验
在介绍QUIC之前，我们先来做个性能对比试验：我们来分别ping 一下“大型购物”网站：www.taobao.com 和 “大型程序员交友”网站：github.com
- www.taobao.com
- github.com
经我们试验发现：taobao 耗时在几十ms级别，而github 却在上百ms级别。
那为什么会有这样的差异呢？我们来分析一下其中存在的原因：
1.1 物理原因和延时
网络和延时的消耗大概分以下几类：
- 距离远
我们知道光速：30万公里/s，从北京-纽约的距离大概1.4w公里，那往返一次需要花费：107ms。
- 路由丢包
48TTL，经过16跳路由，每一跳都要处理时间且可能会丢包（大概15%丢包率）
- 信号转换
光 - 电信的转换消耗
- 其他不可抗力
例如：内容审查等等
1.2 TCP超时重传
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
1.3 HTTP请求
HTTPS 请求存在一定的性能损耗，大致分布如下：
- TCP握手3次通信，大概消耗约：1.5RTT
- SSL/TLS握手4次通信，大概消耗约：2RTT
- HTTP请求&响应，大概消耗约：1RTT
完成整个HTTP请，总计消耗量约：4.5RTT。
2. QUIC是什么？
QUIC 是 Quick UDP Internet Connections 的缩写，谷歌发明的新传输协议。与 TCP 相比，QUIC 可以减少延迟。QUIC 协议可以在 1 到 2 个数据包（取决于连接的服务器是新的还是已知的）内，完成连接的创建（包括 TLS）。
主要的特点包括：
- 0-1RTT完成一次加密的请求与响应
- IETF标准
- HTTP3标准
- Chrome有20%的流量使用QUIC
从表面上看：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 协议的解析即可。
3. 开启通讯发展新时代
QUIC 协议开创性的使用了 UDP 协议作为底层传输协议，通过各种方式减少了网络延迟。
相信 QUIC 能够可以在不远的未来，开启通讯行业发展的新时代。
- HTTP3，弱网环境下也可以流畅访问了，未来3-5年内可能会普及
- 低延时直播，RTMP over QUIC，延时从2s降低到800ms
- 即时通信（QQ、WeChat目前类似email，存在一定的延迟，还不是真正意义上的通信），网络游戏以及物联网（远程设备网络控制及通信）等都会变得有可能。
虽然目前 QUIC 协议已经运行在一些较大的网站上，但离大范围普及还有较长的一段距离，期待 QUIC 协议规范能够成为终稿，并在除了谷歌浏览器之外的其他浏览器和应用服务器中也能够实现。
