揭秘！扒一扒能加速互聯網的QUIC協議

今天早上，一則新聞《谷歌希望憑借其 QUIC 協議加速互聯網》引起了筆者注意，這篇新聞中提到，大約有一半來自 Chrome 瀏覽器對谷歌服務器的請求，現在由 QUIC 協議負責處理。

QUIC 是什么？我們光從字面上來看，就知道它很快，它代表了快速 UDP Internet 連接（全稱是 Quick UDP Internet Connections）。QUIC 是由谷歌開發，在 2013 年就實現的網絡協議，當年 6 月就加入了最新版的 Chrome Canary 中。

QUIC 雖然類似于 SPDY，但根據維基百科介紹， 前者是一個實驗性傳輸層協議，而后者則工作在傳輸層，它的目標主要是優化或替換面向連接中使用 TCP 協議的 Web 應用程序。另外，QUIC 某種程度上與 TCP Fast Open 也類似，但 2011 年面世的 TCP Fast Open 目前尚沒有大范圍使用。

QUIC 在兩個 UDP 端點之間支持一組多路連接，這樣的設計目的是為了給 TLS/SSL 提供安全保護，減少連接、傳輸延遲和寬帶，從而避免在各個方向的擁擠。QUIC 主要優化對象是使用 TCP 連接的 Web 應用程序。

為什么要推出 QUIC？

新浪博客用戶“逝去的青春”在他的一篇博文中有做介紹：

TCP、UDP 都是計算機網絡通信層的主要協議。TCP 是面向連接的，更強調的是傳輸的可靠性，UDP 是面向無連接的，也即在通信雙方進行數據交換之前，無需建立連接，只要知道對方地址即可發送數據，由于 UDP 協議是無連接方式的協議，所以它的效率高，速度快，占資源少。為了集合兩者的優點，谷歌公司推出了 QUIC。

Via：訪問 Google 的神器：Chrome 的 QUIC 協議

QUIC為什么能夠在兩者基礎上進行優化？

Linux 平臺軟件工程師 Lenky 則在個人站點上一篇文章中做了說明：

因為光速不變，而且拋開網絡繁忙這些額外整體因素（因為我們這里考慮的是局部，要做的目標也是局部優化，因此整體因素屬于更上一 層的研究），那么在網絡上，任意確定兩端之間的往返時延 RTTs（round trip times）基本上是固定的，因此，減少單個連接網絡延遲的唯一辦法就是讓建立一條連接所需耗費的 RTTs 個數盡量的少。從這個需求可以看出，對于 TCP 協議本身而言，已經很難做到對應的優化了，一方面是因為 TCP 所要求的握手協議、擁塞控制等固定了其所必須的 RTTs 個數，而另一方面是因為 TCP 實現于操作系統協議棧內，要改變實際用戶的操作系統必定是相當難的。

QUIC 嘗試解決那些 SPDY 無法涵蓋的問題點。首先是 TCP 對頭阻塞，其次是 TCP 擁塞閥門阻塞，也就是這兩個點導致的 SPDY 優勢無法充分發揮。

Via：QUIC 簡介

ChinaUnix 博客用戶 Henrystark 更為詳盡地描述了優化原理

基于一條 TCP 連接的 SPDY 復用連接會面臨這樣的情況：當有丟包發生時，所有連接都將阻塞，這是由 TCP 的擁塞控制特性決定的。丟包必須恢復，而恢復過程中，或早或晚，滑動窗口總有停等的時刻，耗費一個 RTT。在廣域網上，一個 RTT 相當于 50-100ms。相比較而言，當x條并行 HTTP 連接中，有一條丟包，只會阻塞一條。

QUIC 是和 HTTP 同一層的應用層協議，其核心是將丟包控制工作轉移到應用層。由于 QUIC 基于 UDP，可以不理會丟包，快速投遞，再用丟包恢復方法保證可靠性。除此之外，基于一條 TCP 連接的 SPDY 和多條并行 HTTP 連接相比，沒有優勢可言。多條連接中，每個連接都有一個擁塞窗口，不受彼此丟包影響。

Via：QUIC 和 TCP

QUIC 優點：

看了這么多，有些內容確實是比較生澀難懂，那還是挑開說吧，它都有哪些特性或優點：

• 擁有 SPDY 的所有優點（多路傳輸，支持優先級等等）
• 零往返時間連接
• 數據包同步，有效降低數據丟包率
• 轉發問題連接，有效減少重發延遲
• 自適應擁塞控制（對 TCP 友好），有效減少移動客戶端重新連接的次數
• 與 TLS 等效的加密措施
• Chrome 支持與 Google 的 QUIC 通信
• 前向糾錯

大部分 Via： Google 期望使用 QUIC 給互聯網加速

QUIC 的其中一個優勢——通信通道的定義基于 ID 而不是 IP+ 端口，使得切換網絡后繼續轉發連接成為可能（例如從 WiFi 網絡進入移動網絡）。值得一提的是，所有 QUIC 連接都使用特殊的機制進行加密。另外，QUIC 還能夠快速迭代，這主要因為 QUIC 部署在客戶端級別，而不是在內核級別，使得迭代周期由以年計算變為以周計算。

根據 Google 的開發人員 Robbie Shade 的說法，采用 TLS 時，在一次跨大西洋的連接中 TCP 握手要耗時 300ms，而 QUIC 可以將延遲降為 100ms，那效果究竟怎么樣呢？天極在《谷歌欲用改良版的 UDP 協議 QUIC 提高網頁速度》文章中，是這么提到：

數據表明 75% 的連接均可利用 QUIC 的優勢，哪怕預先建立的優化連接(Google 搜索)采用 QUIC 后頁面加載性能仍然能提高 3 個百分點。而時延嚴重的一些 web 應用，在采用 QUIC 后的改進效果則要更加明顯。比如有用戶報告 油Tube 重新緩沖次數減少了 30%。

對于安全性，谷歌特別表示，TCP 的支持往往是直接內置到操作系統內核，谷歌沒有任何控制權。目前谷歌只是希望證明 QUIC 是有效的，如果確實很好，它會遷移到 TCP 和 TLS，而在未來還會向 IETF 提交，從而讓 QUIC 能成為 HTTP2 中一個新的互聯網標準。

谷歌為什么要做這件事呢？兩年前谷奧的一篇文章道出了真相——谷歌一直在試圖重塑各種互聯網核心協議，以推進更快更可靠更安全的互聯網。當然這肯定是有私心，只有更快、更可靠、更安全的互聯網，才能讓賴以搜索引擎為生的谷歌發展得更好。

最后：關于 QUIC 地內容大部分都在這里，如果這些信息還不能滿足你，文中的一些鏈接打開后，你會發現會有更多內容和鏈接等著你，歡迎有心的人繼續挖掘。