QUIC(Quick UDP Internet Connections，快速UDP互联网连接)是Google提出的一种基于UDP改进的通信协议，其目的是降低网络通信的延迟，提供更好的用户互动体验。
QUIC的主要特点包括：具有SPDY(SPDY是谷歌研制的提升HTTP速度的协议，是HTTP/2.0的基础)所有的优点；0-RTT连接；减少丢包；前向纠错，减少重传时延；自适应拥塞控制， 减少重新连接；相当于TLS加密。
有关QUIC的详细资料可以参考http://www.chromium.org/quic里的相关文档和代码。
1.重传与恢复
与TCP类似，QUIC每发送一个包后，都会等待回复一个确认包。当丢包率超过协议的纠错门限时，会显式或隐式地进行重传
对于某些重要的数据包，如初始密钥协商时的数据包，在建立连接时非常重要，如果这类包丢失会阻塞整体数据流。QUIC对于这一类数据包在确认发生丢失前就会尝试重传，通常是等待较短的时间(如20ms)没收到确认后就马上再次发送。这样在网络中会有若干个相同的包同时传输，只要有一个能成功抵达就完成了连接，这样降低了丢包率。接收方对于关键数据包的多次发送和普通数据包的超时重传，都采用相同的重复包处理机制
QUIC在拥塞避免算法的基础上还加入了心跳包，用于减少丢包率
QUIC使用了FEC(前向纠错码)来恢复数据，FEC采用简单异或的方式。每次发送一组数据，包括若干个数据包后，并对这些数据包依次作异或运算，最后的结果作为一个FEC包再发送出去。接收方收到一组数据后，根据数据包和FEC包即可以进行校验和纠错。
2.安全性
QUIC对每个散装的UDP包都进行了加密和认证的保护，并且避免使用前向依赖的处理方法(如CBC模式)，这样每个UDP包可以独立地根据IV进行加密或认证处理。
QUIC采用了两级密钥机制：初始密钥和会话密钥。初次连接时不加密，并协商初始密钥。初始密钥协商完毕后会马上再协商会话密钥，这样可以保证密钥的前向安全性，之后可以在通信的过程中就实现对密钥的更新。接收方意识到有新的密钥要更新时，会尝试用新旧两种密钥对数据进行解密，直到成功才会正式更新密钥，否则会一直保留旧密钥有效。
3. 0-RTT握手过程
QUIC握手的过程是需要一次数据交互，0-RTT时延即可完成握手过程中的密钥协商，比TLS相比效率提高了5倍，且具有更高的安全性。
QUIC在握手过程中使用Diffie-Hellman算法协商初始密钥，初始密钥依赖于服务器存储的一组配置参数，该参数会周期性的更新。初始密钥协商成功后，服务器会提供一个临时随机数，双方根据这个数再生成会话密钥。
具体握手过程如下：
(1) 客户端判断本地是否已有服务器的全部配置参数，如果有则直接跳转到(5)，否则继续
(2) 客户端向服务器发送inchoate client hello(CHLO)消息，请求服务器传输配置参数
(3) 服务器收到CHLO，回复rejection(REJ)消息，其中包含服务器的部分配置参数
(4) 客户端收到REJ，提取并存储服务器配置参数，跳回到(1)
(5) 客户端向服务器发送full client hello消息，开始正式握手，消息中包括客户端选择的公开数。此时客户端根据获取的服务器配置参数和自己选择的公开数，可以计算出初始密钥。
(6) 服务器收到full client hello，如果不同意连接就回复REJ，同(3)；如果同意连接，根据客户端的公开数计算出初始密钥，回复server hello(SHLO)消息，SHLO用初始密钥加密，并且其中包含服务器选择的一个临时公开数。
(7) 客户端收到服务器的回复，如果是REJ则情况同(4)；如果是SHLO，则尝试用初始密钥解密，提取出临时公开数
(8) 客户端和服务器根据临时公开数和初始密钥，各自基于SHA-256算法推导出会话密钥
(9) 双方更换为使用会话密钥通信，初始密钥此时已无用，QUIC握手过程完毕。之后会话密钥更新的流程与以上过程类似，只是数据包中的某些字段略有不同。
