如何看待谷歌 Google 打算用 QUIC 協議替代 TCP/UDP？

12-28

http://www.appy-geek.com/Web/ArticleWeb.aspx?regionid=10articleid=40491819

媒體編輯不懂技術或者有意誇大。

簡而言之，TCP/UDP是通用協議，重在簡單和通用；QUIC是一種針對瀏覽器和HTTP Server間通訊進行優化的專用協議，是針對它所面對的問題域做了很多取捨的。我認為不存在後者代替前者的可能。

另外翻了一下原文，人家Google的人可沒說過QUIC取代TCP/UDP這種話。
「Where do we go from here? Today, roughly half of all requests from Chrome to Google servers are served over QUIC and we』re continuing to ramp up QUIC traffic, eventually making it the default transport from Google clients — both Chrome and mobile apps — to Google servers.We plan to formally propose QUIC to the IETF as an Internet standard but we have some housekeeping to do first, like changing the wire format and updating our reference implementation from SPDY-over-QUIC to HTTP2-over-QUIC. In the coming months, we also plan to work on lowering handshake overhead to allow better server-side scalability, improving forward error correction and congestion control, and adding support for multipath connections. 」

本答案內容主要參考自Google Develop Live的介紹視頻：
QUIC: next generation multiplexed transport over UDP（https://www.youtube.com/watch?v=hQZ-0mXFmk8）【能不能訪問看個人水平】

一. QUIC 的基本特點

基於UDP的多路傳輸（單連接下）；
極低的等待時延（相比於TCP的三次握手）；
快速迭代更新；
開源於Chromium項目中。

首先，QUIC為 傳輸層 協議，與TCP、UDP、SCTP同級。所以肯定會 在一定範圍內 同現有的傳輸層協議構成競爭關係。

二. 為什麼不用TCP

TCP由於基於操作系統內核實現，發展速度極慢，現有的TCP Fast Open實現等等雖然早已存在於標準中但是實際應用情況及其落後，即便除非所有機器的操作系統都更新到最新，否則考慮到兼容性不太可能大範圍採用新技術。
QUIC直接基於客戶端實現，而非基於系統內核（這點有點像最新的.Net Core），可以進行快速迭代更新，不需要操作系統內核層面的更改。

（TCP的性能缺陷將在下文中說明）。
像SCTP這樣的傳輸層協議也都存在了10多年了但由於支持的操作系統內核太少也完全沒有辦法普及應用，所以基於UDP是一個更有效的選擇。（並非是上層協議）

三. QUIC的發展路線

QUIC成為一個獨立的傳輸層方案，成為更多應用層的高性能選擇；
QUIC的理念被TCP和TLS所採納，使得TCP的性能得到充分發展，融合統一；

綜上所述，Google並不是想取代TCP，但是確實想改TCP又改不了（內核實現的劣勢），所以獨立實現了QUIC協議作為替補方案。

四. 核心優勢

1. 多路復用

類似於SCTP的多流設計，可以通過一個連接同時進行多個請求，不必等待上一個請求返回浪費時間，也不必同時建立若干個連接浪費資源。
另外單流情況下若發生丟包則會有等待重傳阻塞，影響整個連接的傳輸速度。

2. 等待時延（Latency）

Web訪問的 用戶體驗 極大地取決於打開網站的等待時間，而TCP需要進行 三次握手 才能建立連接，具有一定的連接等待時延，如果用了TLS加密，還會有其他的步驟進一步增加時延。
QUIC採用了類似於TCP Fast Open的設計，在之前已經連接過的情況下可以無需握手，直接開始傳送數據，連接建立時延為0。
為什麼不直接用TCP Fast Open呢？因為TCP在內核呀，除非所有的伺服器和客戶端的操作系統都能支持並且都更新到能支持的版本才行。所以可能這輩子都不行，就像HTTP1也支持單連接承載多請求但還沒有哪個瀏覽器支持的。

3. 加密技術

總之看起來比TLS性能好很多，也具有各種攻擊防禦策略，這方面不是很懂。可以直接看視頻或者相關文檔。

4. 前向糾錯

QUIC和TCP一個主要的核心區別就是：TCP採用重傳機制，而QUIC採用糾錯機制。
如果發生丟包的話，TCP首先需要一個等待延時來判斷發生了丟包，然後再啟動重傳機制，在此期間會對連接造成一定的阻塞（並且TCP窗口是緩慢增大的，Web這種突發性快速連接情況下窗口會相對較小），從而影響傳輸時間。
而QUIC採用了一種腦洞極大的前向糾錯（FEC）方案，類似於RAID5，將N個包的校驗和（異或）建立一個單獨的數據包發送，這樣如果在這N個包中丟了一個包可以直接恢復出來，完全不需要重傳，有利於保證高速性，N可以根據網路狀況動態調整。

5. 速率控制而非擁塞控制

看樓上的內容好像這個要改，暫時不確定，不做介紹。

6. 連接保持

在IP地址和埠變化的情況下（比如從Wi-Fi切換到流量），可以無需重新建立連接，繼續通信。對移動設備的用戶體驗較為友好。

綜上所述，QUIC確實是一個完善的傳輸層解決方案，在 Web 訪問 上相對TCP確實具有一些優勢。但是總的來說，不說取代，如果能達到和TCP相提並論的地步就已經非常不錯了。

作為用戶，衷心希望QUIC協議能夠不斷發展，當然也希望TCP協議能夠不斷完善。

RAmen！

不是說QUIC是基於UDP的上層協議嗎？？它自己都是基於UDP的，怎麼取代UDP？

《QUIC和TCP》

http://m.blog.chinaunix.net/uid-28387257-id-4335291.html

補充: QUIC不再支持速率控制，轉而採用和TCP類似的擁塞控制。在擁塞避免方面並無特別建樹。另，QUIC需要在包頭打入flowid，這個特性會使很多場景無法使用QUIC。

這完全是誤讀吧，QUIC是tcp承載的http的替代版本，將其視作http over udp更為合適一些。

udp本質上是無序通訊，在並行傳輸上具備tcp不具備的優勢，同時在web這種可並行傳輸的的場景中(資源獲取，視頻緩衝)使用udp傳輸能有效解決請求響應延遲，在非序列的條件下也能提高帶寬的利用率。

Google對大規模部署首先是做了TCP BBR的優化，在阻塞問題上已經有很大提升。直接使用udp可以進一步的挖掘網路的傳輸潛力，這特別對文件傳輸和視頻類應用會有很大的幫助。

http over udp不是什麼新鮮事物，google在chrome項目中引入QUIC主要是直接實現了http over udp的客戶端事實上的普及。

想知道這個到底是啥，讀paper. google自己好像沒有因為這個發paper，就是有一個官方document. 後續有一些在測試這個協議的論文，以及一些在安全方面的論文。下面是一個實驗性質的paper。你可以看看introduction，就知道這是個啥了。
http://c3lab.poliba.it/images/3/3b/QUIC_SAC15.pdf

以前做唱吧之類app的公司有用過類似的解決方案。解決移動端TCP連接不穩定的問題。思路很像

QUIC在遇到丟包率高的時候，應該會更多佔用用戶端CPU和內存吧，這點上是否應該比現有TCP要嚴重？