QUIC是基于UDP（减少了网络延迟）的一个应用层协议，类似HTTP2（多路复用队头阻塞方面）+TLS（加密方面）+TCP（拥塞控制方面），网络状态方面答
    减少了TCP三次握手和TLS握手时间（2*RTT）
    在应用层改进了拥塞控制
    避免队头阻塞的多路复用
    TCP层面的队头阻塞：由于要保证顺序，窗口左边沿向右滑动时的长度取决于已经确认的字节数，而QUIC窗口移动取决 于接收到的最大的
    TLS 协议层面也有一个队头阻塞，因为 TLS 协议都是按照 record 来处理数据的，如果一个 record 中丢失了数据，也 会导致整个 record 无法正确处理。
    可靠性方面，QUIC是在应用层的，而TCP是在传输层
    连接迁移

    QUIC核心特性
    利用缓存，只需要0RTT就可以建立连接
    拥塞控制
    默认使用TCP的拥塞控制算法（同时支持BBR），但做了一些改进，也就是它这个拥塞控制算法不依赖于操作系统，可 以根据用户的网络环境来自由转换拥塞控制算法
    网络状态的变更不会导致断线
    如WiFI和4G网络切换，NAT竞争。因为QUIC使用的是64位的随机数来标识连接而不是使用四元组标识连接
    加密认证
    TCP没有对头部进行加密认证，所以序列号滑动窗口这些可能被修改，而QUIC头部都是经过加密认证处理的
    队头阻塞
    他的多路复用没有队头阻塞的影响，多个Stream（Packet为基本单位）之间没有依赖，而HTTP2加剧了TCP层面的 队头阻塞
    当然，并不是所有的 QUIC 数据都不会受到队头阻塞的影响，比如 QUIC 当前也是使用 Hpack 压缩算法 [10]，由于算法的限制，丢失一个头部数据时，可能遇到队头阻塞。

    面临的挑战
    小地方，路由封杀UDP 443端口（ 这正是QUIC 部署的端口）；
    UDP包过多，由于QS限定，会被服务商误认为是攻击，UDP包被丢弃；
    无论是路由器还是防火墙目前对QUIC都还没有做好准备。

    caddy可以支持QUIC协议
    http://www.52im.net/thread-1309-1-1.html