QUIC(Quick UDP Internet Connections，快速UDP互聯網鏈接)是Google提出的一種基於UDP改進的通訊協議，其目的是下降網絡通訊的延遲，提供更好的用戶互動體驗。html
QUIC的主要特色包括：具備SPDY(SPDY是谷歌研製的提高HTTP速度的協議，是HTTP/2.0的基礎)全部的優勢；0-RTT鏈接；減小丟包；前向糾錯，減小重傳時延；自適應擁塞控制， 減小從新鏈接；至關於TLS加密。算法
有關QUIC的詳細資料能夠參考http://www.chromium.org/quic裏的相關文檔和代碼。安全
1.重傳與恢復
與TCP相似，QUIC每發送一個包後，都會等待回覆一個確認包。當丟包率超過協議的糾錯門限時，會顯式或隱式地進行重傳服務器
對於某些重要的數據包，如初始密鑰協商時的數據包，在創建鏈接時很是重要，若是這類包丟失會阻塞總體數據流。QUIC對於這一類數據包在確認發生丟失前就會嘗試重傳，一般是等待較短的時間(如20ms)沒收到確認後就立刻再次發送。這樣在網絡中會有若干個相同的包同時傳輸，只要有一個能成功抵達就完成了鏈接，這樣下降了丟包率。接收方對於關鍵數據包的屢次發送和普通數據包的超時重傳，都採用相同的重複包處理機制網絡
QUIC在擁塞避免算法的基礎上還加入了心跳包，用於減小丟包率post
QUIC使用了FEC(前向糾錯碼)來恢復數據，FEC採用簡單異或的方式。每次發送一組數據，包括若干個數據包後，並對這些數據包依次做異或運算，最後的結果做爲一個FEC包再發送出去。接收方收到一組數據後，根據數據包和FEC包便可以進行校驗和糾錯。ui
2.安全性
QUIC對每一個散裝的UDP包都進行了加密和認證的保護，而且避免使用前向依賴的處理方法(如CBC模式)，這樣每一個UDP包能夠獨立地根據IV進行加密或認證處理。加密
QUIC採用了兩級密鑰機制：初始密鑰和會話密鑰。初次鏈接時不加密，並協商初始密鑰。初始密鑰協商完畢後會立刻再協商會話密鑰，這樣能夠保證密鑰的前向安全性，以後能夠在通訊的過程當中就實現對密鑰的更新。接收方意識到有新的密鑰要更新時，會嘗試用新舊兩種密鑰對數據進行解密，直到成功纔會正式更新密鑰，不然會一直保留舊密鑰有效。server
3. 0-RTT握手過程
QUIC握手的過程是須要一次數據交互，0-RTT時延便可完成握手過程當中的密鑰協商，比TLS相比效率提升了5倍，且具備更高的安全性。htm
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握手過程完畢。以後會話密鑰更新的流程與以上過程相似，只是數據包中的某些字段略有不一樣。
