图片来源 Next generation multiplexed transport over UDP (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 。其他常用web服务如nginx、apache等都未开始支持。curl表达了对QUIC协议 支持的兴趣 。
QUIC性能优势
在2015年的 博文 中，Google分享了一些关于QUIC协议实现的结果。
这些优势在诸如YouTube的视频服务上更为突出。用户报告通过QUIC协议在观看视频的时候可以减少30%的重新缓冲时间。
如果YouTube收集的报告可靠，可以预见视频服务提供商会更快的采用QUIC协议。