QUIC

避免前序包阻塞

SPDY和HTTP\/2协议现在都支持将页面的多个数据（如图片、js等）通过一个数据链接进行传输。该特性能够加快页面组件的传输速度，但是对于TCP协议来说，这会遇到前序包阻塞的问题。这是由于TCP协议在处理包时是有严格顺序的，当其中一个数据包遇到问题，TCP连接需要等待这个包完成重传之后才能继续进行。因此，即使逻辑上一个TCP连接上并行的在进行多路数据传输，其他毫无关联的数据也会因此阻塞。

图片来源 Next generation multiplexed transport over UDP (PDF)（https:\/\/www.nanog.org\/sites\/default\/files\/meetings\/NANOG64\/1051\/20150603_Rogan_Quic_Next_Generation_v1.pdf）

QUIC协议直接通过底层使用UDP协议天然的避免了该问题。由于UDP协议没有严格的顺序，当一个数据包遇到问题需要重传时，只会影响该数据包对应的资源，其他独立的资源（如其他css、js文件）不会受到影响。

图片来源 Next generation multiplexed transport over UDP (PDF)（https:\/\/www.nanog.org\/sites\/default\/files\/meetings\/NANOG64\/1051\/20150603_Rogan_Quic_Next_Generation_v1.pdf）

减少数据包

前文已经介绍过QUIC协议在创建连接握手时，只需要1到2个数据包即可。这对于拥有高速互联网连接的网络环境下可能没有太大的感觉，因为此时一个数据包的延时大概在10～50ms之间。

一般来说延迟在50ms之内不会有太大的感觉。但是对于无线网络来说，情况就不太一样了。且不说传统2G\/3G网络，即使是4G网络，客户端和服务器之间的延时也通常在100ms以上。传统TCP+TLS协议的传输方式，在创建连接时的4个数据包和QUIC协议的1个数据包相比，连接创建上就会多耗时300ms以上。

向前纠错

QUIC协议有一个非常独特的特性，称为向前纠错（Forward Error Correction），每个数据包除了它本身的内容之外，还包括了部分其他数据包的数据，因此少量的丢包可以通过其他包的冗余数据直接组装而无需重传。

这类似网络层的RAID 5！

目前默认的冗余量是10%，既每发送10个数据包，其冗余数据就可以重新构建一个丢失的数据包。

向前纠错牺牲了每个数据包可以发送数据的上限，但是减少了因为丢包导致的数据重传，因为数据重传将会消耗更多的时间（包括确认数据包丢失、请求重传、等待新数据包等步骤的时间消耗）。

会话重启和并行下载

底层协议切换到UDP协议之后的另一大好处是，连接不再依赖于来源IP。

对于TCP协议来说，标识一个TCP连接需要4个参数，既来源IP、来源端口、目的IP和目的端口。其中的任一参数改变，TCP连接就需要重新创建。

这对于传统网络来说影响不大，因为来源和目的IP相对固定。但是在无线网络中，情况就大不相同了。设备在移动过程中，可能会因为网络切换（如从WIFI网络切换到4G网络环境），导致TCP连接需要重新创建。

QUIC协议使用了UDP协议，不再需要这四元组参数。同时QUIC协议实现了自己的会话标记方式，称为连接UUID。当设备网络环境切换时，连接UUID不会发生变化，因此无需重新进行握手。

该特性除了可以减少无谓的连接重连之外，还可以充分利用设备的不同网络接口，进行资源的并行下载。因为虽然这些网络接口有不同的IP，但只要他们能够共享连接UUID，就能够并行的从服务器下载数据。

四、QUIC协议实践

Chrome浏览器从2014年开始已经实验性的支持了QUIC协议。可以通过在Chrome浏览器中输入chrome://net-internals/#quic查看是否已经支持QUIC协议。如果还未支持，可以在chrome://flags/#enable-quic中进行开启。

开始Chrome浏览器对QUIC协议的支持之后，可以在chrome://net-internals/#quic中查看到当前浏览器的QUIC一些连接。当然目前只有Google服务才支持QUIC协议（如YouTube、 Google.com）。

关于防火墙

通常系统管理员会关注防火墙的TCP规则，而忽略UDP规则。如果要在防火墙之后使用QUIC协议，除了传统Web服务需要开放的80/TCP、443/TCP之外，针对QUIC还需要开放443/UDP的访问。

服务端使用QUIC协议

目前支持QUIC协议的Web服务只有0.9版本以后的Caddy（https:\/\/github.com\/mholt\/caddy\/wiki\/QUIC）。其他常用Web服务如nginx、apache等都未开始支持。curl表达了对QUIC协议支持的兴趣（https:\/\/daniel.haxx.se\/blog\/2016\/07\/20\/curl-wants-to-quic\/）。

QUIC性能优势

在2015年的博文（http:\/\/blog.chromium.org\/2015\/04\/a-quic-update-on-googles-experimental.html）中，Google分享了一些关于QUIC协议实现的结果。

这些优势在诸如YouTube的视频服务上更为突出。用户报告通过QUIC协议在观看视频的时候可以减少30%的重新缓冲时间。

如果YouTube收集的报告可靠，可以预见视频服务提供商会更快的采用QUIC协议。

五、总结

QUIC协议开创性的使用了UDP协议作为底层传输协议，通过各种方式减少了网络延迟。

目前QUIC协议已经在运行在最大的网站上，期待QUIC协议规范能够成为终稿，并在其他浏览器和服务器中能够实现。