quic 协议分析
HTTP 3 ，它来了，QUIC（quick udp internet connection “快速 UDP 互联网连接”）正如其名一样，它就是快。其正在标准化为新一代的互联网传输协议。是由google提出的使用udp进行多路并发的传输协议。
为什么需要QUIC
QUIC解决了什么问题呢？从上世纪90年代至今，互联网一直按照一成不变的模式发展着。使用ipv4进行路由，使用tcp进行连接层面的拥塞控制，并保证其传输的可靠性，使用tls层进行安全加密和身份验证，使用http进行应用的数据传输。
这么多年的发展，这些协议只是小部分或者细节上有了改变，tcp提出了几个新的拥塞控制算法，tls改变了加密方式，http层进化出了h2。但是互联网发展至今，网络传输的内容越来越大，用户对传输的时延，带宽提出越来越大的要求。
tcp虽然也在拥塞控制上提出了一些优秀的拥塞控制算法，如BBR但是限制于其对操作系统内核版本的要求，tcp 的 TFO，windows操作系统又支持不好等。导致想要切换成更高效的协议成本巨大。
这里列出几个主要的矛盾。
1、协议历史悠久导致中间设备僵化。
2、依赖于操作系统的实现导致协议本身僵化。
3、建立连接的握手延迟大。
4、队头阻塞。
QUIC概述
QUIC孕育而生，其抛开了TCP直接采用UDP，如一些拥塞算法，可靠性保证机制，不再依赖操作系统内核，而是可以自定义。
Quic 相比现在广泛应用的 http2+tcp+tls 协议有如下优势：
1、减少了 TCP 三次握手及 TLS 握手时间。
2、改进的拥塞控制。
3、避免队头阻塞的多路复用。
4、连接迁移。
5、前向冗余纠错。
中间设备僵化和操作系统老旧
有些防火墙只允许通过 80 和 443，不放通其他端口。NAT 网关在转换网络地址时重写传输层的头部，有可能导致双方无法使用新的传输格式。因为通信协议栈都是固化到操作系统中的，只能通过内核参数进行调整，但是这样的调整极其有限，如果想要新加协议，只能重新编译内核。而现实是，可能还有一些Centos5 还作为某些古董公司的线上服务器。另外，windows xp 可能还是某些事业单位的办公电脑上装的操作系统，尽管xp的时代已经过去20年了。另外TCP Fast Open 也在2013年就提出了，但是windows操作系统也有些不支持。
建立连接的握手延迟大
知道一个首次https网站的访问都要有哪些步骤吗？dns解析需要1个RTT，TCP三次握手，HTTP 302 跳转 HTTPS又需要RTT，TCP重新握手。TLS握手再消耗2个。解析CA的DNS（因为浏览器获取到证书后，有可能需要发起 OCSP 或者 CRL 请求，查询证书状态）再对CA进行TCP握手，OCSP响应。密钥协商又是RTT。当然这种情况是最极端的，大部分情况下不是所有流程都需要走一遍的。（参考 大型网站的 HTTPS 实践（二）-- HTTPS 对性能的影响）
队头阻塞
-
HTTP的对头阻塞HTTP1.1 是一发一收，也就是第一个数据没响应之前不能发第二个请求。而HTTP2 的出现，带来了多路复用的解决方案，就是将消息分为多个stream。这样，可以多个stream同时传送。 -
TCP的对头阻塞一个数据包丢了，下面的数据包就是不会确认收到，这个没法改变，因为TCP协议栈早就这样定好了，无法改变。所以基于TCP的HTTP2 在处理4层的对头阻塞问题上也是无能为力。 -
TLS的对头阻塞TLS 协议都是按照 record 来处理数据的，如果一个 record 中丢失了数据，也会导致整个 record 无法正确处理。这个目前也没有很好的解决方法。
基于以上的原因，QUIC选择了UDP。没有了三次握手，在应用层面完成了传输的可靠性，拥塞控制还有TLS的安全性。只要应用软件的客户端和服务端支持就行，绕开了操作系统内核版本这个硬骨头。
QUIC核心特性
1、减去不必要的RTT
在HTTPS over TCP+TLS的时代。HTTPS需要3个RTT，在session 复用的情况下是2个RTT。而QUIC做到了1RTT和会话复用的0RTT。
QUIC的TLS只能使用TLS1.3，这就可以做到PSK的0RTT。
http2-quic_diagram.png
2、改进的拥塞控制
TCP 的拥塞控制实际上包含了四个算法：慢启动，拥塞避免，快速重传，快速恢复。其中TCP中拥塞控制是被编译进内核中的，如果想要更改就需要改变内核参数，但是想要对已有的拥塞控制算法进行更改就需要重新编译内核，Linux 4.9 中引入了基于时延的拥塞控制算法 BBR，这打破了以往是靠丢包驱动的拥塞控制算法，但是想要在TCP中使用，就必须升级内核至4.9以上。
QUIC 协议当前默认使用了 TCP 协议的 Cubic 拥塞控制算法 [6]，同时也支持 CubicBytes, Reno, RenoBytes, BBR, PCC 等拥塞控制算法。
QUIC和TCP的对比
-
可插拔：
QUIC 可以针对某个特殊场景使用不同的拥塞控制算法，且切换十分简单。
TCP 想要切换拥塞控制算法是针对全局的，要么更改内核参数，要么重新编译内核。切换十分不便。 -
单调递增的 Packet Number
QUIC 的数据包是单调递增的Packet Number。这帮助传输解决了重传歧义，方便计算RTO，解决了TCP的队头阻塞。因为TCP的数据是流，确认机制是 seq和ack。QUIC使用 Packet Number 代替了 TCP 的 sequence number，并且每个 Packet Number 都严格递增，也就是说就算 Packet N 丢失了，重传的 Packet N 的 Packet Number 已经不是 N，而是一个比 N 大的值。而 TCP 呢，重传 segment 的 sequence number 和原始的 segment 的 Sequence Number 保持不变，也正是由于这个特性，引入了 Tcp 重传的歧义问题。后面tcp引入了timestamp解决了这些问题。
对于TCP而言，其RTO的计算方式: RTO的最佳是略大于RTT。（平滑 RTO：RFC793）由于RTT是经常变化的，所以在计算RTO之前希望先计算出SRTT。
SRTT （smoothed round-trip time） = ( α * SRTT ) + ((1 - α) * RTT)
其中α 从 0到 1（RFC 推荐 0.9），越大越平滑
RTO = min[ UBOUND, max[ LBOUND, (β * SRTT) ] ]
如 UBOUND为1分钟，LBOUND为 1 秒钟， β从 1.3 到 2 之间
对于QUIC
