图12 connection流控
拥塞控制
我们知道TCP有多种拥塞控制算法，当遇到网络拥塞会通过减包等方式来避免网络环境恶化。但是，UDP本身是没有拥塞控制的，一旦不加约束的使用会导致侵占其他“守规矩”的网络协议的带宽。
所以，为了避免上述情况，基于UDP的QUIC协议借鉴了TCP的一些优秀的拥塞控制算法，如默认使用Cubic，同时，为了避免AIMD机制带来的带宽利用率低，采用了packet pacing来探测网络带宽。
思路是，QUIC会通过追踪包的到达时间来预测当前带宽的使用情况，以决定是否提高，保持或者减少发送包的速率来避免网络拥塞。
图13 packet pacing
丢包恢复
类似拥塞控制，除了基于TCP的一些丢包恢复机制，如：TLP，FACK。QUIC的丢包恢复也在一些方面做了改进。
比如：通过引入严格递增的sequence number使得计算RTT更加精确。更精确的RTT也意味更精确的RTO和超时重传机制。
还比如我们知道TCP中有个SACK选项，该选项打开时用于记录传输过程中一些没有被确认的数据的范围，便于后续定向重传多组丢失数据，而不是全部重传，所以更多的范围便于更多的选择重传，也意味着更少的重传包频率。但TCP最多支持3个SACK范围，而QUIC能支持255个。
除了上述基于TCP的改进的丢包恢复特性以外，早期的QUIC版本还有一个丢包恢复机制，就是FEC（Forward Error Correction），这个特性虽然目前处于正在改造阶段（可能会浪费带宽并且作用不是很明显），但是依然是一个有意思的解决方案。FEC的思路是通过在一组包（一般是10个）中，通过增加一个FEC包，并用FEC和每个包进行XOR，如果一旦有丢包，那么将FEC包和其余包XOR，得到的FEC包就是那个丢包，所以一组包最多只能恢复一个丢包。
更多特性
除了上述的主要特性，QUIC还有一些其他特性，如：
● 通过header stream保证流顺序
● 底层保证连接持久
● 源地址令牌防止地址欺骗
● 握手时压缩证书避免放大攻击
在此不深入研究，大家有兴趣可以翻阅Google相关的文档查阅。
业界应用情况
● Google超过50%的请求来自QUIC
● 目前Youtube有20%的流量来自QUIC
● 微博移动端全面支持QUIC协议
测试demo
● 客户端
最新版本PC Chrome（控制开启/关闭quic）
● 服务器
经stgw改造支持quic的nginx
● 页面地址（机器被回收，后续会更换机器供测试）
https://stgwquic.kof.qq.com/club/platform/act/gift/test1.html
https://stgwquic.kof.qq.com/club/platform/act/gift/test2.html
https://stgwquic.kof.qq.com/club/platform/act/gift/test3.html
● 网络
公司staffwifi
● 抓包工具
wireshark
● 效果对比
图15 HTTP1.1协议的页面
图16 HTTP2协议的页面
图17 QUIC协议的页面
图18页面请求20个，大小2MB