QUIC協議

QUIC協議參考網址 https://www.chromium.org/quic

既生瑜，何生亮？

QUIC的特性

• 提供可靠傳輸
• 減少連接建立的時間
• 改善擁塞控制
• 多路復用
• 轉發錯誤連接
• 連接移植

TCP的特性

TCP的主要特性是提供面向連接的服務,數據傳輸前需要進行三次握手，利用重傳與確認機制來保證數據的正確到達對端

UDP的特性

UDP的主要特性是面向無連接的服務,不需要確認對端是否存活,直接進行數據的發送,不能保證數據正確到達,因為不需要進行握手和確認,傳輸速度特別快

HTTP2的特性

• HTTP2采用二進制格式傳輸數據，而HTTP1使用文本格式
• HTTP2對頭部采用HPACK進行數據壓縮
• Server Push：服務器主動把css和js推送給客戶端
• 多路復用：HTTP1.1里面也采用了連接復用，但是一個鏈路在一段時間內只能被一個請求占用(下一個請求要使用該鏈路必須等到上一個應答到來)，但是HTTP2中解決了這個問題，可以使用多個請求同時使用該連接(一個請求發出后下一個請求可以接着發)
  支持優先級傳輸

QUIC的架構

我們可以看到QUIC是集大成者,它底層使用了UDP協議提高了數據傳輸的速度,同時它吸收了TCP的特性來提供可靠傳輸,容納了HTTP2的一些特性

QUIC中的握手

QUIC既然要提供可靠服務,則需要向TCP協議一樣進行握手來驗證對端的存在性。下面是client與server握手的過程(從Client角度來看整個握手過程)

如果client沒有訪問過server則會發送CHLO[client hello]給server，此后進行一些安全方面的操作,然后重新訪問server；如果client以前訪問過server,則server會發送SHLO給client,則表示握手成功
握手過程的詳細說明 https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit#

QUIC中的擁塞控制

QUIC中的擁塞控制采用TCP Cubic擁塞控制算法

多路復用問題

在HTTP2中多個請求可以使用同一條TCP連接,但是會出現前向包擁塞問題，即第一請求在被發送的過程中出了包丟失，后續的HTTP請求將會被阻塞，直到包丟失問題被解決后(第一個HTTP請求被發送完畢)，后續的HTTP請求才能被寫到TCP流中。QUIC底層使用UDP協議天然的解決了這個問題,因為UDP協議不會擁塞。即假如第一HTTP請求中發生了包丟失，QUIC還是會繼續發送后面的HTTP請求,直到某一時刻發現第一個HTTP請求中出現了包丟失問題，這時回頭解決包丟失問題

連接移植

在TCP連接中，一個鏈接是由源IP+源端口+目的IP+目的端口來標識的，當其中的一個發生變化，則意味着是一條新的連接,這時需要進行三次握手重新建立連接
但是在QUIC中一個連接的由64bit標識碼來標識的,這個標識碼是由客戶端隨機產生。這就意味着你在上網時可以在wifi和4G中無縫切換，而不用重新去建立連接

參考博客

http://www.cnblogs.com/awiki/articles/5174306.html
http://www.oschina.net/news/77135/quic-google-protocol-web-platform-from-tcp-to-udp
https://github.com/devsisters/libquic