QUIC協(xié)議淺析與HTTP/3.0
1. 簡介
QUIC（Quick UDP Internet Connections)基于UDP的傳輸層協(xié)議派歌，提供像TCP一樣的可靠性坏挠。在提高web應(yīng)用性能上纷妆，可以選擇在應(yīng)用層使用HTTP2.0實現(xiàn)多路傳輸欧宜，在物理層使用CDN解決網(wǎng)絡(luò)擁塞和最后一公里問題。在傳輸層铁坎，目前主要使用TCP绸罗，但由于TCP本身的問題（一個充滿補丁的丑陋的協(xié)議）草添，成為了限制web應(yīng)用性能的一個瓶頸遗座。
QUIC是Google新開發(fā)的一個基于UDP的協(xié)議舀凛，它提供了像TCP一樣的傳輸可靠性保證，可以實現(xiàn)數(shù)據(jù)傳輸?shù)?-RTT延遲途蒋，靈活的設(shè)計使我們可以對它的擁塞控制及流量控制做更多的定制猛遍，它還提供了傳輸?shù)陌踩员Ｕ希约跋馠TTP/2一樣的應(yīng)用數(shù)據(jù)二進制分幀傳輸号坡。
而QUIC協(xié)議最最吸引人的特性有兩點懊烤，一是對線頭阻塞(HOL)問題的解決更為徹底】矶眩基于TCP的HTTP/2腌紧，盡管從邏輯上來說，不同的流之間相互獨立畜隶，不會相互影響壁肋，但在實際傳輸方面，數(shù)據(jù)還是要一幀一幀的發(fā)送和接收代箭，一旦某一個流的數(shù)據(jù)有丟包墩划，則同樣會阻塞在它之后傳輸?shù)钠渌c它毫不相干的流的數(shù)據(jù)的傳輸。而基于UDP的QUIC協(xié)議則可以更為徹底地解決這樣的問題嗡综，讓不同的流之間真正的實現(xiàn)相互獨立傳輸乙帮，互不干擾。
另一個特性切換網(wǎng)絡(luò)時的連接保持极景。當前移動端的應(yīng)用環(huán)境察净，用戶的網(wǎng)絡(luò)可能會經(jīng)常切換，比如從辦公室或家里出門盼樟，WiFi斷開氢卡，網(wǎng)絡(luò)切換為3G或4G〕拷桑基于TCP的協(xié)議译秦，由于切換網(wǎng)絡(luò)之后，IP會改變击碗，因而之前的連接不可能繼續(xù)保持筑悴。而基于UDP的QUIC協(xié)議，則可以內(nèi)建與TCP中不同的連接標識方法稍途，從而在網(wǎng)絡(luò)完成切換之后阁吝，恢復(fù)之前與服務(wù)器的連接。
由于這些良好的特性械拍，QUIC協(xié)議已經(jīng)有在gmail中得到了大量的應(yīng)用突勇。
互聯(lián)網(wǎng)工程任務(wù)組（IETF装盯，協(xié)作設(shè)計網(wǎng)絡(luò)協(xié)議的行業(yè)組織）一直致力于制定標準化的QUIC版本，該版本目前與谷歌的原始提案有很大差異甲馋。IETF還希望開發(fā)一個使用QUIC的HTTP版本埂奈，該版本之前名為HTTP-over-QUIC或HTTP/QUIC。然而摔刁，HTTP-over-QUIC不是HTTP/2 over QUIC挥转，而是一種為QUIC設(shè)計的新的HTTP更新版。
因此共屈，身兼IETF旗下HTTP工作組組長和QUIC工作組組長的馬克?諾丁漢（Mark Nottingham）提議，將HTTP-over-QUIC改名為HTTP/3党窜，這個提議似乎已得到了廣泛接受拗引。HTTP的下一個版本將QUIC列作一項必不可少的基本功能，那樣HTTP/3將始終使用QUIC作為其網(wǎng)絡(luò)協(xié)議幌衣。
2. 傳輸與建立連接上的優(yōu)勢
2.1 避免前序包阻塞（HOL阻塞）
多個數(shù)據(jù)在TCP連接上傳輸時矾削，若一個數(shù)據(jù)包出現(xiàn)問題，TCP需要等待該包重傳后豁护，才能繼續(xù)傳輸其它數(shù)據(jù)包哼凯。但在QUIC中，因為其基于UDP協(xié)議楚里，UDP數(shù)據(jù)包在出問題需要重傳時断部，并不會對其他數(shù)據(jù)包傳輸產(chǎn)生影響。
2.2 零RTT建立連接
目前TCP與SSL/TLS(1.0,1.1,1.2)每次建連需要TCP三次握手+安全握手班缎，需要4~5個RRT
2.3 第一次連接
客戶端之前沒有連接個此服務(wù)器蝴光，那么他會發(fā)送一個Hello Packet。服務(wù)器接到之后达址，會回復(fù)一個數(shù)據(jù)包蔑祟。里面包含了安全證書和對此客戶端唯一的SYN cookie〕吝耄客戶端接到包之后疆虚，首先要做的就是解碼，保存好SYN cookie满葛。SYN cookie 類似于令牌径簿，能夠驗證客戶端身份。它的生存周期較短纱扭，防止被盜用牍帚。這樣建立連接只需要1個RTT。
當客戶端接到服務(wù)器發(fā)來的第一個數(shù)據(jù)包乳蛾，沒有正確解碼暗赶，那么它會再次發(fā)送一個包要求服務(wù)器從新發(fā)送它的安全證書鄙币，并將SYN cookie附加到這個請求包中，以便讓服務(wù)器驗證請求的正確性和有效性蹂随。此時十嘿，建立連接需要2個RTT。
2.4 重復(fù)連接
因為客戶端之前已經(jīng)成功和服務(wù)器通信岳锁。自然保留了一份服務(wù)器的安全證書绩衷。當再次想要連接服務(wù)器的時候，客戶端假設(shè)這個安全證書沒有過期激率，還是有效的咳燕。加密一個Hello Packet并發(fā)送之后。接著不用等回復(fù)就可以直接加密其他的數(shù)據(jù)包并發(fā)送乒躺。Hello Packet 里面包括一些協(xié)商信息和對自己掌握著Client IP的證明等招盲。因為不用等待確認，為了預(yù)防丟包等問題嘉冒，Hello Packet可能會隔一段時間被重傳多次曹货，保證減少丟包造成的延遲。比如讳推，先發(fā)一個Hello包顶籽，之后發(fā)送數(shù)據(jù)包，再發(fā)送一個Hello包银觅。
服務(wù)器接到Hello包之后礼饱，用自己現(xiàn)有的秘鑰解碼，如果解碼不成功设拟，將把客戶端的連接當做第一次連接慨仿，重發(fā)安全證書等信息。同上介紹的一樣纳胧。此時镰吆，通常會有2個RTT，極端情況下是3個RTT跑慕。
服務(wù)器成功解碼之后万皿，驗證了客戶端的安全性之后，就可以繼續(xù)處理接下來收到的數(shù)據(jù)包核行。此時延時是0個RTT牢硅。
3. 優(yōu)雅的丟包處理
3.1 FEC前向糾錯
QUIC協(xié)議的每個數(shù)據(jù)包除了本身的數(shù)據(jù)以外，會帶有其他數(shù)據(jù)包的部分數(shù)據(jù)芝雪，在少量丟包的情況下减余，可以使用其他數(shù)據(jù)包的冗余數(shù)據(jù)完成數(shù)據(jù)組裝而無需重傳，從而提高數(shù)據(jù)的傳輸速度惩系。具體實現(xiàn)類似于RAID5位岔，將N個包的校驗和（異或）建立一個單獨的數(shù)據(jù)包發(fā)送如筛，這樣如果在這N個包中丟了一個包可以直接恢復(fù)出來。除此之外還可以用來校驗包的正確性
3.2 關(guān)鍵包發(fā)送多次
3.3 快速重啟會話（支持手機網(wǎng)絡(luò)切換）
普通基于tcp的連接抒抬，是基于兩端的ip和端口和協(xié)議來建立的杨刨。在網(wǎng)絡(luò)切換場景，例如手機端切換了無線網(wǎng)擦剑，使用4G網(wǎng)絡(luò)妖胀，會改變本身的ip，這就導(dǎo)致tcp連接必須重新創(chuàng)建惠勒。而QUIC協(xié)議使用特有的UUID來標記每一次連接赚抡，在網(wǎng)絡(luò)環(huán)境發(fā)生變化的時候，只要UUID不變纠屋，就能不需要握手怕品，繼續(xù)傳輸數(shù)據(jù)。
4. 安全
前向安全巾遭。即使被人抓包存儲起來，在未來某個時間點秘鑰被破解后仍然不能解密闯估。
內(nèi)置的加密模塊灼舍，支持SNI，因此支持一個IP部署多個證書涨薪，默認打開骑素，相比TLS更高效的向前加密。
https://www.cnblogs.com/mod109/p/7372577.html
5. 適用場景
- 長距離傳輸
- 手機網(wǎng)絡(luò)
- 請求的頁面資源數(shù)較多刚夺，并發(fā)的連接數(shù)多
- 要求加密傳輸
本文整理自網(wǎng)絡(luò)献丑，來源見擴展閱讀
