HTTP 3 ，它來了，QUIC（quick udp internet connection “快速 UDP 互聯網連接”）正如其名壹樣，它就是快。其正在標準化為新壹代的互聯網傳輸協議。是由google提出的使用udp進行多路並發的傳輸協議。
QUIC解決了什麽問題呢？從上世紀90年代至今，互聯網壹直按照壹成不變的模式發展著。使用ipv4進行路由，使用tcp進行連接層面的擁塞控制，並保證其傳輸的可靠性，使用tls層進行安全加密和身份驗證，使用http進行應用的數據傳輸。
這麽多年的發展，這些協議只是小部分或者細節上有了改變，tcp提出了幾個新的擁塞控制算法，tls改變了加密方式，http層進化出了h2。但是互聯網發展至今，網絡傳輸的內容越來越大，用戶對傳輸的時延，帶寬提出越來越大的要求。
tcp雖然也在擁塞控制上提出了壹些優秀的擁塞控制算法，如BBR但是限制於其對操作系統內核版本的要求，tcp 的 TFO，windows操作系統又支持不好等。導致想要切換成更高效的協議成本巨大。
這裏列出幾個主要的矛盾。
1、協議歷史悠久導致中間設備僵化。
2、依賴於操作系統的實現導致協議本身僵化。
3、建立連接的握手延遲大。
4、隊頭阻塞。
QUIC孕育而生，其拋開了TCP直接采用UDP，如壹些擁塞算法，可靠性保證機制，不再依賴操作系統內核，而是可以自定義。
Quic 相比現在廣泛應用的 http2+tcp+tls 協議有如下優勢：
1、減少了 TCP 三次握手及 TLS 握手時間。
2、改進的擁塞控制。
3、避免隊頭阻塞的多路復用。
4、連接遷移。
5、前向冗余糾錯。
有些防火墻只允許通過 80 和 443，不放通其他端口。NAT 網關在轉換網絡地址時重寫傳輸層的頭部，有可能導致雙方無法使用新的傳輸格式。因為通信協議棧都是固化到操作系統中的，只能通過內核參數進行調整，但是這樣的調整極其有限，如果想要新加協議，只能重新編譯內核。而現實是，可能還有壹些Centos5 還作為某些古董公司的線上服務器。另外，windows xp 可能還是某些事業單位的辦公電腦上裝的操作系統，盡管xp的時代已經過去20年了。另外TCP Fast Open 也在2013年就提出了，但是windows操作系統也有些不支持。
知道壹個首次https網站的訪問都要有哪些步驟嗎？dns解析需要1個RTT，TCP三次握手，HTTP 302 跳轉 HTTPS又需要RTT，TCP重新握手。TLS握手再消耗2個。解析CA的DNS（因為瀏覽器獲取到證書後，有可能需要發起 OCSP 或者 CRL 請求，查詢證書狀態）再對CA進行TCP握手，OCSP響應。密鑰協商又是RTT。當然這種情況是最極端的，大部分情況下不是所有流程都需要走壹遍的。（參考 大型網站的 HTTPS 實踐（二）-- HTTPS 對性能的影響 ）
基於以上的原因，QUIC選擇了UDP。沒有了三次握手，在應用層面完成了傳輸的可靠性，擁塞控制還有TLS的安全性。只要應用軟件的客戶端和服務端支持就行，繞開了操作系統內核版本這個硬骨頭。
在HTTPS over TCP+TLS的時代。HTTPS需要3個RTT，在session 復用的情況下是2個RTT。而QUIC做到了1RTT和會話復用的0RTT。
QUIC的TLS只能使用TLS1.3，這就可以做到PSK的0RTT。
TCP 的擁塞控制實際上包含了四個算法：慢啟動，擁塞避免，快速重傳，快速恢復。其中TCP中擁塞控制是被編譯進內核中的，如果想要更改就需要改變內核參數，但是想要對已有的擁塞控制算法進行更改就需要重新編譯內核，Linux 4.9 中引入了基於時延的擁塞控制算法 BBR，這打破了以往是靠丟包驅動的擁塞控制算法，但是想要在TCP中使用，就必須升級內核至4.9以上。
QUIC 協議當前默認使用了 TCP 協議的 Cubic 擁塞控制算法 [6]，同時也支持 CubicBytes, Reno, RenoBytes, BBR, PCC 等擁塞控制算法。
QUIC和TCP的對比
其中α 從 0到 1（RFC 推薦 0.9），越大越平滑
如 UBOUND為1分鐘，LBOUND為 1 秒鐘， β從 1.3 到 2 之間
對於QUIC
參考： 科普：QUIC協議原理分析 羅成