2015 年 HTTP/2 標準發(fā)表后坎匿，大多數(shù)主流瀏覽器也于當年年底支持該標準。此后蚁廓，憑借著多路復(fù)用访圃、頭部壓縮、服務(wù)器推送等優(yōu)勢纳令，HTTP/2 得到了越來越多開發(fā)者的青睞挽荠。不知不覺的 HTTP 已經(jīng)發(fā)展到了第三代，鵝廠也緊跟技術(shù)潮流平绩，很多項目也在逐漸使用 HTTP/3。本文基于興趣部落接入 HTTP/3 的實踐漠另，聊一聊 HTTP/3 的原理以及業(yè)務(wù)接入的方式捏雌。

1. HTTP/3 原理

1.1 HTTP 歷史

在介紹 HTTP/3 之前，我們先簡單看下 HTTP 的歷史笆搓，了解下 HTTP/3 出現(xiàn)的背景性湿。

圖片

隨著網(wǎng)絡(luò)技術(shù)的發(fā)展纬傲，1999 年設(shè)計的 HTTP/1.1 已經(jīng)不能滿足需求，所以 Google 在 2009 年設(shè)計了基于 TCP 的 SPDY肤频，后來 SPDY 的開發(fā)組推動 SPDY 成為正式標準叹括，不過最終沒能通過。不過 SPDY 的開發(fā)組全程參與了 HTTP/2 的制定過程舆乔，參考了 SPDY 的很多設(shè)計车摄，所以我們一般認為 SPDY 就是 HTTP/2 的前身介时。無論 SPDY 還是 HTTP/2，都是基于 TCP 的侠讯，TCP 與 UDP 相比效率上存在天然的劣勢，所以 2013 年 Google 開發(fā)了基于 UDP 的名為 QUIC 的傳輸層協(xié)議暑刃，QUIC 全稱 Quick UDP Internet Connections厢漩，希望它能替代 TCP，使得網(wǎng)頁傳輸更加高效岩臣。后經(jīng)提議溜嗜，互聯(lián)網(wǎng)工程任務(wù)組正式將基于 QUIC 協(xié)議的 HTTP （HTTP over QUIC）重命名為 HTTP/3。

1.2 QUIC 協(xié)議概覽

TCP 一直是傳輸層中舉足輕重的協(xié)議架谎，而 UDP 則默默無聞粱胜，在面試中問到 TCP 和 UDP 的區(qū)別時，有關(guān) UDP 的回答常常寥寥幾語狐树，長期以來 UDP 給人的印象就是一個很快但不可靠的傳輸層協(xié)議焙压。但有時候從另一個角度看，缺點可能也是優(yōu)點抑钟。QUIC（Quick UDP Internet Connections涯曲，快速 UDP 網(wǎng)絡(luò)連接） 基于 UDP，正是看中了 UDP 的速度與效率在塔。同時 QUIC 也整合了 TCP幻件、TLS 和 HTTP/2 的優(yōu)點，并加以優(yōu)化蛔溃。用一張圖可以清晰地表示他們之間的關(guān)系绰沥。

圖片

那 QUIC 和 HTTP/3 什么關(guān)系呢徽曲？QUIC 是用來替代 TCP麸塞、SSL/TLS 的傳輸層協(xié)議秃臣，在傳輸層之上還有應(yīng)用層，我們熟知的應(yīng)用層協(xié)議有 HTTP弧哎、FTP、IMAP 等稚虎，這些協(xié)議理論上都可以運行在 QUIC 之上撤嫩，其中運行在 QUIC 之上的 HTTP 協(xié)議被稱為 HTTP/3蠢终，這就是”HTTP over QUIC 即 HTTP/3“的含義蜕径。

因此想要了解 HTTP/3兜喻，QUIC 是繞不過去的，下面主要通過幾個重要的特性讓大家對 QUIC 有更深的理解帕识。

1.3 零 RTT 建立連接

用一張圖可以形象地看出 HTTP/2 和 HTTP/3 建立連接的差別遂铡。

圖片

HTTP/2 的連接需要 3 RTT扒接，如果考慮會話復(fù)用钾怔，即把第一次握手算出來的對稱密鑰緩存起來，那么也需要 2 RTT愚臀，更進一步的矾利，如果 TLS 升級到 1.3，那么 HTTP/2 連接需要 2 RTT舶斧，考慮會話復(fù)用則需要 1 RTT剑肯。有人會說 HTTP/2 不一定需要 HTTPS让网，握手過程還可以簡化溃睹。這沒毛病，HTTP/2 的標準的確不需要基于 HTTPS泞辐，但實際上所有瀏覽器的實現(xiàn)都要求 HTTP/2 必須基于 HTTPS咐吼，所以 HTTP/2 的加密連接必不可少锯茄。而 HTTP/3 首次連接只需要 1 RTT茶没，后面的連接更是只需 0 RTT抓半，意味著客戶端發(fā)給服務(wù)端的第一個包就帶有請求數(shù)據(jù)笛求，這一點 HTTP/2 難以望其項背。那這背后是什么原理呢狡孔？我們具體看下 QUIC 的連接過程步氏。

Step1：首次連接時荚醒，客戶端發(fā)送 Inchoate Client Hello 給服務(wù)端界阁，用于請求連接胖喳；

Step2：服務(wù)端生成 g、p咕别、a惰拱，根據(jù) g啊送、p 和 a 算出 A馋没，然后將 g篷朵、p款票、A 放到 Server Config 中再發(fā)送 Rejection 消息給客戶端；

Step3：客戶端接收到 g卡乾、p幔妨、A 后误堡，自己再生成 b雏吭，根據(jù) g杖们、p摘完、b 算出 B孝治，根據(jù) A、p岂座、b 算出初始密鑰 K掺逼。B 和 K 算好后吕喘，客戶端會用 K 加密 HTTP 數(shù)據(jù)氯质，連同 B 一起發(fā)送給服務(wù)端闻察；

Step4：服務(wù)端接收到 B 后辕漂，根據(jù) a吴超、p鲸阻、B 生成與客戶端同樣的密鑰鸟悴，再用這密鑰解密收到的 HTTP 數(shù)據(jù)细诸。為了進一步的安全（前向安全性）震贵，服務(wù)端會更新自己的隨機數(shù) a 和公鑰屏歹，再生成新的密鑰 S，然后把公鑰通過 Server Hello 發(fā)送給客戶端季希。連同 Server Hello 消息式塌，還有 HTTP 返回數(shù)據(jù)峰尝；

Step5：客戶端收到 Server Hello 后武学，生成與服務(wù)端一致的新密鑰 S火窒，后面的傳輸都使用 S 加密熏矿。

這樣票编，QUIC 從請求連接到正式接發(fā) HTTP 數(shù)據(jù)一共花了 1 RTT慧域，這 1 個 RTT 主要是為了獲取 Server Config，后面的連接如果客戶端緩存了 Server Config宛裕，那么就可以直接發(fā)送 HTTP 數(shù)據(jù)揩尸，實現(xiàn) 0 RTT 建立連接岩榆。

圖片

這里使用的是 DH 密鑰交換算法勇边，DH 算法的核心就是服務(wù)端生成 a粒褒、g奕坟、p 3 個隨機數(shù)月杉，a 自己持有苛萎，g 和 p 要傳輸給客戶端腌歉，而客戶端會生成 b 這 1 個隨機數(shù)究履，通過 DH 算法客戶端和服務(wù)端可以算出同樣的密鑰最仑。在這過程中 a 和 b 并不參與網(wǎng)絡(luò)傳輸泥彤，安全性大大提高吟吝。因為 p 和 g 是大數(shù)剑逃，所以即使在網(wǎng)絡(luò)中傳輸?shù)?p蛹磺、g萤捆、A俗批、B 都被劫持岁忘，那么靠現(xiàn)在的計算機算力也沒法破解密鑰干像。

1.4 連接遷移

TCP 連接基于四元組（源 IP、源端口揩懒、目的 IP已球、目的端口）智亮，切換網(wǎng)絡(luò)時至少會有一個因素發(fā)生變化阔蛉，導(dǎo)致連接發(fā)生變化状原。當連接發(fā)生變化時颠区，如果還使用原來的 TCP 連接毕莱，則會導(dǎo)致連接失敗朋截，就得等原來的連接超時后重新建立連接部服，所以我們有時候發(fā)現(xiàn)切換到一個新網(wǎng)絡(luò)時，即使新網(wǎng)絡(luò)狀況良好瘫想，但內(nèi)容還是需要加載很久国夜。如果實現(xiàn)得好车吹，當檢測到網(wǎng)絡(luò)變化時立刻建立新的 TCP 連接窄驹，即使這樣乐埠，建立新的連接還是需要幾百毫秒的時間丈咐。

QUIC 的連接不受四元組的影響棵逊，當這四個元素發(fā)生變化時辆影，原連接依然維持秸歧。那這是怎么做到的呢键菱？道理很簡單经备，QUIC 連接不以四元組作為標識侵蒙，而是使用一個 64 位的隨機數(shù)纷闺，這個隨機數(shù)被稱為 Connection ID犁功，即使 IP 或者端口發(fā)生變化，只要 Connection ID 沒有變化限嫌，那么連接依然可以維持怒医。

圖片

1.5 隊頭阻塞/多路復(fù)用

HTTP/1.1 和 HTTP/2 都存在隊頭阻塞問題（Head of line blocking）稚叹，那什么是隊頭阻塞呢蛤奥？

TCP 是個面向連接的協(xié)議凡桥，即發(fā)送請求后需要收到 ACK 消息缅刽，以確認對方已接收到數(shù)據(jù)衰猛。如果每次請求都要在收到上次請求的 ACK 消息后再請求啡省，那么效率無疑很低卦睹。后來 HTTP/1.1 提出了 Pipelining 技術(shù)，允許一個 TCP 連接同時發(fā)送多個請求徐鹤，這樣就大大提升了傳輸效率返敬。

圖片

在這個背景下救赐，下面就來談 HTTP/1.1 的隊頭阻塞经磅。下圖中预厌，一個 TCP 連接同時傳輸 10 個請求阿迈，其中第 1苗沧、2待逞、3 個請求已被客戶端接收网严，但第 4 個請求丟失识樱，那么后面第 5 - 10 個請求都被阻塞，需要等第 4 個請求處理完畢才能被處理震束，這樣就浪費了帶寬資源怜庸。

圖片

因此，HTTP 一般又允許每個主機建立 6 個 TCP 連接垢村，這樣可以更加充分地利用帶寬資源割疾，但每個連接中隊頭阻塞的問題還是存在嘉栓。

HTTP/2 的多路復(fù)用解決了上述的隊頭阻塞問題宏榕。不像 HTTP/1.1 中只有上一個請求的所有數(shù)據(jù)包被傳輸完畢下一個請求的數(shù)據(jù)包才可以被傳輸，HTTP/2 中每個請求都被拆分成多個 Frame 通過一條 TCP 連接同時被傳輸侵佃，這樣即使一個請求被阻塞担扑，也不會影響其他的請求。如下圖所示趣钱，不同顏色代表不同的請求，相同顏色的色塊代表請求被切分的 Frame胚宦。

圖片

事情還沒完首有，HTTP/2 雖然可以解決“請求”這個粒度的阻塞，但 HTTP/2 的基礎(chǔ) TCP 協(xié)議本身卻也存在著隊頭阻塞的問題枢劝。HTTP/2 的每個請求都會被拆分成多個 Frame井联，不同請求的 Frame 組合成 Stream，Stream 是 TCP 上的邏輯傳輸單元您旁，這樣 HTTP/2 就達到了一條連接同時發(fā)送多條請求的目標烙常，這就是多路復(fù)用的原理。我們看一個例子，在一條 TCP 連接上同時發(fā)送 4 個 Stream蚕脏，其中 Stream1 已正確送達侦副，Stream2 中的第 3 個 Frame 丟失，TCP 處理數(shù)據(jù)時有嚴格的前后順序驼鞭，先發(fā)送的 Frame 要先被處理秦驯，這樣就會要求發(fā)送方重新發(fā)送第 3 個 Frame，Stream3 和 Stream4 雖然已到達但卻不能被處理挣棕，那么這時整條連接都被阻塞译隘。

圖片

不僅如此，由于 HTTP/2 必須使用 HTTPS洛心，而 HTTPS 使用的 TLS 協(xié)議也存在隊頭阻塞問題固耘。TLS 基于 Record 組織數(shù)據(jù)，將一堆數(shù)據(jù)放在一起（即一個 Record）加密词身，加密完后又拆分成多個 TCP 包傳輸厅目。一般每個 Record 16K，包含 12 個 TCP 包偿枕，這樣如果 12 個 TCP 包中有任何一個包丟失璧瞬，那么整個 Record 都無法解密。

圖片

隊頭阻塞會導(dǎo)致 HTTP/2 在更容易丟包的弱網(wǎng)絡(luò)環(huán)境下比 HTTP/1.1 更慢渐夸！

那 QUIC 是如何解決隊頭阻塞問題的呢嗤锉？主要有兩點。

• QUIC 的傳輸單元是 Packet墓塌，加密單元也是 Packet瘟忱，整個加密、傳輸苫幢、解密都基于 Packet访诱，這樣就能避免 TLS 的隊頭阻塞問題；
• QUIC 基于 UDP韩肝，UDP 的數(shù)據(jù)包在接收端沒有處理順序触菜，即使中間丟失一個包，也不會阻塞整條連接哀峻，其他的資源會被正常處理涡相。

image.gif

1.6 擁塞控制

擁塞控制的目的是避免過多的數(shù)據(jù)一下子涌入網(wǎng)絡(luò)，導(dǎo)致網(wǎng)絡(luò)超出最大負荷剩蟀。QUIC 的擁塞控制與 TCP 類似催蝗，并在此基礎(chǔ)上做了改進。所以我們先簡單介紹下 TCP 的擁塞控制育特。

TCP 擁塞控制由 4 個核心算法組成：慢啟動丙号、擁塞避免、快速重傳和快速恢復(fù)，理解了這 4 個算法犬缨，對 TCP 的擁塞控制也就有了大概了解喳魏。

• 慢啟動：發(fā)送方向接收方發(fā)送 1 個單位的數(shù)據(jù)，收到對方確認后會發(fā)送 2 個單位的數(shù)據(jù)遍尺，然后依次是 4 個截酷、8 個……呈指數(shù)級增長，這個過程就是在不斷試探網(wǎng)絡(luò)的擁塞程度乾戏，超出閾值則會導(dǎo)致網(wǎng)絡(luò)擁塞迂苛；
• 擁塞避免：指數(shù)增長不可能是無限的，到達某個限制（慢啟動閾值）之后鼓择，指數(shù)增長變?yōu)榫€性增長三幻；
• 快速重傳：發(fā)送方每一次發(fā)送時都會設(shè)置一個超時計時器，超時后即認為丟失呐能，需要重發(fā)念搬；
• 快速恢復(fù)：在上面快速重傳的基礎(chǔ)上，發(fā)送方重新發(fā)送數(shù)據(jù)時摆出，也會啟動一個超時定時器朗徊，如果收到確認消息則進入擁塞避免階段，如果仍然超時偎漫，則回到慢啟動階段爷恳。

圖片

QUIC 重新實現(xiàn)了 TCP 協(xié)議的 Cubic 算法進行擁塞控制，并在此基礎(chǔ)上做了不少改進象踊。下面介紹一些 QUIC 改進的擁塞控制的特性温亲。

1.6.1 熱插拔

TCP 中如果要修改擁塞控制策略，需要在系統(tǒng)層面進行操作杯矩。QUIC 修改擁塞控制策略只需要在應(yīng)用層操作栈虚，并且 QUIC 會根據(jù)不同的網(wǎng)絡(luò)環(huán)境、用戶來動態(tài)選擇擁塞控制算法史隆。

圖片

1.6.2 前向糾錯 FEC

QUIC 使用前向糾錯(FEC魂务，F(xiàn)orward Error Correction)技術(shù)增加協(xié)議的容錯性。一段數(shù)據(jù)被切分為 10 個包后泌射，依次對每個包進行異或運算头镊，運算結(jié)果會作為 FEC 包與數(shù)據(jù)包一起被傳輸，如果不幸在傳輸過程中有一個數(shù)據(jù)包丟失魄幕，那么就可以根據(jù)剩余 9 個包以及 FEC 包推算出丟失的那個包的數(shù)據(jù)，這樣就大大增加了協(xié)議的容錯性颖杏。

這是符合現(xiàn)階段網(wǎng)絡(luò)技術(shù)的一種方案纯陨，現(xiàn)階段帶寬已經(jīng)不是網(wǎng)絡(luò)傳輸?shù)钠款i，往返時間才是，所以新的網(wǎng)絡(luò)傳輸協(xié)議可以適當增加數(shù)據(jù)冗余翼抠，減少重傳操作咙轩。

image.gif

1.6.3 單調(diào)遞增的 Packet Number

TCP 為了保證可靠性，使用 Sequence Number 和 ACK 來確認消息是否有序到達阴颖，但這樣的設(shè)計存在缺陷活喊。

超時發(fā)生后客戶端發(fā)起重傳，后來接收到了 ACK 確認消息量愧，但因為原始請求和重傳請求接收到的 ACK 消息一樣钾菊，所以客戶端就郁悶了，不知道這個 ACK 對應(yīng)的是原始請求還是重傳請求偎肃。如果客戶端認為是原始請求的 ACK煞烫，但實際上是左圖的情形，則計算的采樣 RTT 偏大累颂；如果客戶端認為是重傳請求的 ACK滞详，但實際上是右圖的情形，又會導(dǎo)致采樣 RTT 偏小紊馏。圖中有幾個術(shù)語料饥，RTO 是指超時重傳時間（Retransmission TimeOut），跟我們熟悉的 RTT（Round Trip Time朱监，往返時間）很長得很像岸啡。采樣 RTT 會影響 RTO 計算，超時時間的準確把握很重要赌朋，長了短了都不合適凰狞。

image.gif

QUIC 解決了上面的歧義問題。與 Sequence Number 不同的是沛慢，Packet Number 嚴格單調(diào)遞增赡若，如果 Packet N 丟失了，那么重傳時 Packet 的標識不會是 N团甲，而是比 N 大的數(shù)字逾冬，比如 N + M，這樣發(fā)送方接收到確認消息時就能方便地知道 ACK 對應(yīng)的是原始請求還是重傳請求躺苦。

圖片

1.6.4 ACK Delay

TCP 計算 RTT 時沒有考慮接收方接收到數(shù)據(jù)到發(fā)送確認消息之間的延遲身腻，如下圖所示，這段延遲即 ACK Delay匹厘。QUIC 考慮了這段延遲嘀趟，使得 RTT 的計算更加準確。

圖片

1.6.5 更多的 ACK 塊

一般來說愈诚，接收方收到發(fā)送方的消息后都應(yīng)該發(fā)送一個 ACK 回復(fù)她按，表示收到了數(shù)據(jù)牛隅。但每收到一個數(shù)據(jù)就返回一個 ACK 回復(fù)太麻煩，所以一般不會立即回復(fù)酌泰，而是接收到多個數(shù)據(jù)后再回復(fù)媒佣，TCP SACK 最多提供 3 個 ACK block。但有些場景下陵刹，比如下載默伍，只需要服務(wù)器返回數(shù)據(jù)就好，但按照 TCP 的設(shè)計衰琐，每收到 3 個數(shù)據(jù)包就要“禮貌性”地返回一個 ACK也糊。而 QUIC 最多可以捎帶 256 個 ACK block。在丟包率比較嚴重的網(wǎng)絡(luò)下碘耳，更多的 ACK block 可以減少重傳量显设，提升網(wǎng)絡(luò)效率。

圖片

1.7 流量控制

TCP 會對每個 TCP 連接進行流量控制辛辨，流量控制的意思是讓發(fā)送方不要發(fā)送太快捕捂，要讓接收方來得及接收，不然會導(dǎo)致數(shù)據(jù)溢出而丟失斗搞，TCP 的流量控制主要通過滑動窗口來實現(xiàn)的指攒。可以看出僻焚，擁塞控制主要是控制發(fā)送方的發(fā)送策略允悦，但沒有考慮到接收方的接收能力，流量控制是對這部分能力的補齊虑啤。

QUIC 只需要建立一條連接隙弛，在這條連接上同時傳輸多條 Stream，好比有一條道路狞山，兩頭分別有一個倉庫全闷，道路中有很多車輛運送物資。QUIC 的流量控制有兩個級別：連接級別（Connection Level）和 Stream 級別（Stream Level）萍启，好比既要控制這條路的總流量总珠，不要一下子很多車輛涌進來，貨物來不及處理勘纯，也不能一個車輛一下子運送很多貨物局服，這樣貨物也來不及處理。

那 QUIC 是怎么實現(xiàn)流量控制的呢驳遵？我們先看單條 Stream 的流量控制淫奔。Stream 還沒傳輸數(shù)據(jù)時，接收窗口（flow control receive window）就是最大接收窗口（flow control receive window）堤结，隨著接收方接收到數(shù)據(jù)后搏讶，接收窗口不斷縮小佳鳖。在接收到的數(shù)據(jù)中，有的數(shù)據(jù)已被處理媒惕，而有的數(shù)據(jù)還沒來得及被處理。如下圖所示来庭，藍色塊表示已處理數(shù)據(jù)妒蔚，黃色塊表示未處理數(shù)據(jù)，這部分數(shù)據(jù)的到來月弛，使得 Stream 的接收窗口縮小肴盏。

image.gif

隨著數(shù)據(jù)不斷被處理，接收方就有能力處理更多數(shù)據(jù)帽衙。當滿足 (flow control receive offset - consumed bytes) < (max receive window / 2) 時菜皂，接收方會發(fā)送 WINDOW_UPDATE frame 告訴發(fā)送方你可以再多發(fā)送些數(shù)據(jù)過來。這時 flow control receive offset 就會偏移厉萝，接收窗口增大恍飘，發(fā)送方可以發(fā)送更多數(shù)據(jù)到接收方。

圖片

Stream 級別對防止接收端接收過多數(shù)據(jù)作用有限谴垫，更需要借助 Connection 級別的流量控制章母。理解了 Stream 流量那么也很好理解 Connection 流控。Stream 中翩剪，接收窗口(flow control receive window) = 最大接收窗口(max receive window) - 已接收數(shù)據(jù)(highest received byte offset) 乳怎，而對 Connection 來說：接收窗口 = Stream1 接收窗口 + Stream2 接收窗口 + ... + StreamN 接收窗口 。

2. HTTP/3 實踐

2.1 X5 內(nèi)核與 STGW

X5 內(nèi)核是騰訊開發(fā)的適用于安卓系統(tǒng)的瀏覽器內(nèi)核前弯，為了解決傳統(tǒng)安卓系統(tǒng)瀏覽器內(nèi)核適配成本高蚪缀、不安全、不穩(wěn)定等問題而開發(fā)的統(tǒng)一的瀏覽器內(nèi)核恕出。STGW 是 Secure Tencent Gateway 的縮寫询枚，意思是騰訊安全云網(wǎng)關(guān)。兩者早在前兩年便支持了 QUIC 協(xié)議剃根。

那作為運行在 X5 上的業(yè)務(wù)哩盲，我們該如何接入 QUIC 呢？得益于 X5 和 STGW狈醉，業(yè)務(wù)在接入 QUIC 時所需要做的改動非常小廉油，只需要兩步。

Step 1. 在 STGW 上開啟白名單苗傅，允許業(yè)務(wù)域名接入 QUIC 協(xié)議抒线；

Step 2. 業(yè)務(wù)資源的 Response Header 添加 alt-svc 屬性，示例：alt-svc: quic=":443"; ma=2592000; v="44,43,39"渣慕。

圖片

接入 QUIC 時嘶炭，STGW 的優(yōu)勢非常明顯抱慌，由 STGW 與支持 QUIC 的客戶端(這里是 X5)進行通信，而業(yè)務(wù)后臺與 STGW 仍然使用 HTTP/1.1 通信眨猎，QUIC 所需要的 Server Config 等緩存信息也都是由 STGW 維護抑进。

2.2 協(xié)商升級與競速

業(yè)務(wù)域名加入了 STGW 的白名單，業(yè)務(wù)資源的 Response Header 也添加了 alt-svc 屬性睡陪，那 QUIC 是如何建立連接的呢寺渗？這里有個關(guān)鍵的步驟：協(xié)商升級±计龋客戶端不確定服務(wù)器是否支持 QUIC信殊，如果貿(mào)然地請求建立 QUIC 連接可能會失敗，所以需要經(jīng)歷協(xié)商升級過程才能決定是否使用 QUIC汁果。

image.gif

首次請求時涡拘，客戶端會使用 HTTP/1.1 或者 HTTP/2，如果服務(wù)器支持 QUIC据德，則在響應(yīng)的數(shù)據(jù)中返回 alt-svc 頭部鳄乏，告訴客戶端下次請求可以走 QUIC。alt-svc 主要包含以下信息：

• quic：監(jiān)聽的端口晋控；
• ma：有效時間汞窗，單位是秒，承諾在這段時間內(nèi)都支持 QUIC赡译；
• 版本號：QUIC 的迭代很快仲吏，這里列出所有支持的版本號。

確認服務(wù)器支持 QUIC 之后蝌焚，客戶端向服務(wù)端同時發(fā)起 QUIC 連接和 TCP 連接裹唆，比較兩個連接的速度，然后選擇較快的協(xié)議只洒，這個過程叫“競速”许帐，一般都是 QUIC 獲勝。

2.3 QUIC 性能表現(xiàn)

圖片

QUIC 建立連接的成功率在 90% 以上毕谴，競速成功率也接近 90%成畦，0 RTT 率在 55% 左右。

圖片

使用 QUIC 協(xié)議時頁面首屏耗時要比非 QUIC 協(xié)議減少 10%涝开。

圖片

從資源獲取的不同階段看循帐，QUIC 協(xié)議在連接階段節(jié)省的時間比較明顯。

圖片

從頁面首屏區(qū)間占比圖中可以看出舀武，使用了 QUIC 協(xié)議后拄养，首屏耗時在 1 秒內(nèi)的占比提升明顯，大約在 12% 左右银舱。

3. 總結(jié)

QUIC 丟掉了 TCP瘪匿、TLS 的包袱跛梗，基于 UDP，并對 TCP棋弥、TLS核偿、HTTP/2 的經(jīng)驗加以借鑒、改進顽染，實現(xiàn)了一個安全高效可靠的 HTTP 通信協(xié)議宪祥。憑借著 0 RTT 建立連接、平滑的連接遷移家乘、基本消除了隊頭阻塞、改進的擁塞控制和流量控制等優(yōu)秀的特性藏澳，QUIC 在絕大多數(shù)場景下獲得了比 HTTP/2 更好的效果仁锯。

一周前，微軟宣布開源自己的內(nèi)部 QUIC 庫 -- MsQuic翔悠，將全面推薦 QUIC 協(xié)議替換 TCP/IP 協(xié)議业崖。

HTTP/3 未來可期。