站长注：注意到quic协议是因为实际测试adguard的quic协议叫DOH和TLS协议速度快很多。
QUIC是一个通用的传输层网络协议，最初由Google的Jim Roskind设计，2012年实现并部署，2013年随着实验范围的扩大而公开发布，并向IETF描述。虽然仍是互联网草案，但在从Chrome浏览器到Google服务器的所有连接中，超过一半的连接都使用了QUIC。Microsoft Edge、Firefox和Safari都支持它，但默认情况下没有启用。
虽然它的名字最初是作为 “快速UDP互联网连接”的首字母缩写提出的，但IETF使用的QUIC一词并不是首字母缩写，它只是协议的名称。QUIC提高了目前使用TCP的面向连接的网络应用的性能。它通过使用用户数据报协议（UDP）在两个端点之间创建若干个多路连接来实现这一目标，其目的是为了在网络层淘汰TCP，以满足许多应用的需求，因此该协议偶尔也会获得 “TCP/2”的昵称。
QUIC与HTTP/2的多路复用连接协同工作，允许多个数据流独立到达所有端点，因此不受涉及其他数据流的丢包影响。相反，HTTP/2创建在传输控制协议（TCP）上，如果任何一个TCP数据包延迟或丢失，所有多路数据流都会遭受队头阻塞延迟。
QUIC的次要目标包括降低连接和传输时延，以及每个方向的带宽估计以避免拥塞。它还将拥塞控制算法移到了两个端点的用户空间，而不是内核空间，据称这将使这些算法得到更快的改进。此外，该协议还可以扩展前向纠错（FEC），以进一步提高预期错误时的性能，这被视为协议演进的下一步。
2015年6月，QUIC规范的互联网草案提交给IETF进行标准化。2016年，成立了QUIC工作组。2018年10月，IETF的HTTP工作组和QUIC工作组共同决定将QUIC上的HTTP映射称为 “HTTP/3″，以提前使其成为全球标准。
Quic 相比现在广泛应用的 http2+tcp+tls 协议有如下优势 ：
- 减少了 TCP 三次握手及 TLS 握手时间。
- 改进的拥塞控制。
- 避免队头阻塞的多路复用。
- 连接迁移。
- 前向冗余纠错。
QUIC 核心特性连接建立延时低
0RTT 建连可以说是 QUIC 相比 HTTP2 最大的性能优势。那什么是 0RTT 建连呢？这里面有两层含义。
- 传输层 0RTT 就能建立连接。
- 加密层 0RTT 就能建立加密连接。
比如上图左边是 HTTPS 的一次完全握手的建连过程，需要 3 个 RTT。就算是 Session Resumption[14]，也需要至少 2 个 RTT。
而 QUIC 呢？由于建立在 UDP 的基础上，同时又实现了 0RTT 的安全握手，所以在大部分情况下，只需要 0 个 RTT 就能实现数据发送，在实现前向加密的基础上，并且 0RTT 的成功率相比 TLS 的 Sesison Ticket要高很多。
下一步测试：
1）nginx开启quic
2）chrome和firefox开启quic支持
参考资料：
- https://zh.wikipedia.org/zh-cn/QUIC
- https://zhuanlan.zhihu.com/p/32553477
- https://www.cnblogs.com/zafu/p/7844478.html
- https://www.cnbeta.com/articles/tech/1134087.htm