QUIC(Quick UDP Internet Connections)协议是一种全新的基于UDP的web开发协议。
从TCP协议说起
当前，web平台的数据传输都基于TCP协议。TCP协议在创建连接之前需要进行 三次握手 (图1)，如果需要提高数据交互的安全性，既增加传输层安全协议(TLS)，还会增加更多的握手次数(图2)。
图1，TCP三次握手示意(来源 Next generation multiplexed transport over UDP (PDF) )
图2，TLS初始化握手示意(来源 Next generation multiplexed transport over UDP (PDF) )
正因为TCP协议连接建立的成本相对较高，可以通过 TCP快速打开 (TCP Fast Open)来减少建立连接时的握手次数。但是该技术目前应用较少。
和TCP相反，UDP协议是无连接协议。客户端发出UDP数据包后，只能“假设”这个数据包已经被服务端接收。这样的好处是在网络传输层无需对数据包进行确认，但存在的问题就是为了确保数据传输的可靠性，应用层协议需要自己完成包传输情况的确认。
此时，QUIC协议就登场了。QUIC协议可以在1到2个数据包(取决于连接的服务器是新的还是已知的)内，完成连接的创建(包括TLS)(图3)。
图3，QUIC协议握手示意(来源 Next generation multiplexed transport over UDP (PDF) )
QUIC协议的目的
从前文对比可以看出，QUIC协议的主要目的，是为了整合TCP协议的可靠性和UDP协议的速度和效率。
QUIC的维基百科页面 介绍了该协议的主要目的：
对于Google来说优化TCP协议是一个长期目标，QUIC旨在创建几乎等同于TCP的独立连接，但有着低延迟，并对类似SPDY的多路复用流协议有更好的支持。 如果QUIC协议的特性被证明是有效的，这些特性以后可能会被迁移入后续版本的TCP和TLS协议(它们都有很长的开发周期)。
值得注意的是， 如果QUIC的特性被证明是有效的，这些特性以后可能会被迁移到后续版本的TCP协议中 。
TCP协议的实现是高度管制的。TCP协议栈通常由操作系统实现，如Linux、Windows内核或者其他移动设备操作系统。修改TCP协议是一项浩大的工程，因为每种设备、系统的实现都需要更新。
相反的，UDP协议在操作系统层面实现相对简单，基于UDP协议实现新的协议以验证Google对于TCP协议改进的理论，验证成本相对较低。
QUIC协议内置了TLS栈，实现了自己的 传输加密层 ，而没有使用现有的TLS 1.2。同时QUIC还包含了部分HTTP/2的实现，因此QUIC的地位看起来是这样的：
从图上可以看出，QUIC底层通过UDP协议替代了TCP，上层只需要一层用于和远程服务器交互的HTTP/2 API。这是因为QUIC协议已经包含了多路复用和连接管理，HTTP API只需要完成HTTP协议的解析即可。
QUIC特性
避免前序包阻塞
SPDY和HTTP/2协议现在都支持将页面的多个数据(如图片、js等)通过一个数据链接进行传输。该特性能够加快页面组件的传输速度，但是对于TCP协议来说，这会遇到前序包阻塞的问题。这是由于TCP协议在处理包时是有严格顺序的，当其中一个数据包遇到问题，TCP连接需要等待这个包完成重传之后才能继续进行。因此，即使逻辑上一个TCP连接上并行的在进行多路数据传输，其他毫无关联的数据也会因此阻塞。
图片来源 Next generation multiplexed transport over UDP (PDF)
QUIC协议直接通过底层使用UDP协议天然的避免了该问题。由于UDP协议没有严格的顺序，当一个数据包遇到问题需要重传时，只会影响该数据包对应的资源，其他独立的资源(如其他css、js文件)不会受到影响。
