在Google新版的Chrome浏览器中，支持QUIC协议，在 Chrome 浏览器中打开“实验性功能”页面（chrome://flags/），启用“实验性 QUIC 协议”和“经由实验性 QUIC 协议发出的 HTTPS 请求”，重启浏览器后可以正常登陆 Google 相关服务(被DNS污染的除外)。对于被DNS污染的Google服务，还需要设置Hosts的IP，然后通过HTTPS才能访问。

QUIC协议的原理介绍：

TCP、UDP都是计算机网络通信层的主要协议。TCP是面向连接的，更强调的是传输的可靠性，UDP是面向无连接的，也即在通信双方进行数据交换之前，无需建立连接,只要知道对方地址即可发送数据，由于UDP协议是无连接方式的协议，所以它的效率高，速度快，占资源少。

为了集合两者的优点，谷歌公司研制了一种UDP通信的改进版——Quick UDP Internet Connections（QUIC），快速UDP互联网连接。

QUIC的主要特点包括，具有SPDY（SPDY是谷歌研制的提升HTTP速度的协议，是HTTP/2.0的基础）所有的优点；0-RTT连接；减少丢包；前向纠错，减少重传时延；自适应拥塞控制， 减少重新连接；相当于TLS加密。

总之，QUIC系统能够降低网络通信的延迟，提供更好的用户互动体验，尽管随着互联网的发展，网络带宽会持续增加，QUIC等新型通信协议具有越来越重要的意义。

QUIC是Quick UDP Internet Connections的缩写，读作quick。由Google开发，概要设计文档放在google docshttps://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/edit，还在不断更新。传输格式的详细设计文档放在https://docs.google.com/document/d/1WJvyZflAO2pq77yOLbp9NsGjC1CHetAXV8I0fQe-B_U/edit。

概要设计文档从TCP/UDP特性、网络安全等考虑出发，做了非常多设计思路方面的论述，开头就阐述了SPDY的4个缺点：

1. 单个包（packet）丢失会阻塞整个流（stream）。
2. TCP避免拥堵的机制做的不好，导致带宽降低和序列化的等待时间开销。
3. TLS会话重连的等待时间开销。握手机制带来额外的Round Trip。
4. TLS解密的开销。先到的包必须等后面的包到来才能解密。

可以认为QUIC是为了解决SPDY在TCP遇到的瓶颈而在UDP上做探索所设计的方案。参考SPDY来理解，可认为QUIC的传输内容分两层，高层类似SPDY，低层是在UDP上模仿实现TCP的面向连接特性和可靠性并加入类似TLS的加密过程。

QUIC的文档还算未完成的状态，且Chromium的实现代码也在完善中，这还是个试验性的半成品，没有性能比较的数据。只浅浅研究即止，不深入了。