來源 | 后端技術(shù)指南針
大白和小黑生活不止眼前的茍且，還有詩和遠方的田野。
新的一周又開始了，大白和小黑是同事，平時倆人一起喝酒吃肉打游戲居多，當然有時候也討論下學(xué)術(shù)和前沿技術(shù)。
這不，小黑聽說了個新鮮玩意，然后和大白聊了起來：
小黑：大白大白，聽說HTTP協(xié)議已經(jīng)到3.0了？
大白：是的，已經(jīng)到3.0了，甚至我還要告訴你它還是基于UDP開發(fā)的！
小黑：UDP?沒搞錯吧?!UDP可是不靠譜代言人啊，TCP不香了嗎？
大白：千真萬確，而且已經(jīng)跑起來效果不錯，正在推廣呢，據(jù)說Chrome金絲雀版本已經(jīng)支持了，可以搶鮮試用。
小黑：害！我這個憨憨HTTP2.0還沒整明白，3.0就來了，快快快，給俺講講這個黑科技。
小黑是個爽快人，許諾大白給他講清楚了，周五就請一頓木屋燒烤，再小酌幾杯，放松一下。
大白看在小黑對知識的渴求和燒烤的份上，決定給小黑講講HTTP3.0和QUIC協(xié)議那些事。
通過本文你將了解到以下內(nèi)容：
HTTP3.0和QUIC協(xié)議的前景和應(yīng)用效果
科技永不止步。
我們都知道互聯(lián)網(wǎng)中業(yè)務(wù)是不斷迭代前進的，像HTTP這種重要的網(wǎng)絡(luò)協(xié)議也是如此，新版本是對舊版本的揚棄。
2.1 HTTP2.0和TCP的愛恨糾葛
HTTP2.0是2015年推出的，還是比較年輕的，其重要的二進制分幀協(xié)議、多路復(fù)用、頭部壓縮、服務(wù)端推送等重要優(yōu)化使HTTP協(xié)議真正上了一個新臺階。
像谷歌這種重要的公司并沒有滿足于此，而且想繼續(xù)提升HTTP的性能，花最少的時間和資源獲取極致體驗。
那么肯定要問HTTP2.0雖然性能已經(jīng)不錯了，還有什么不足嗎？
移動互聯(lián)網(wǎng)領(lǐng)域表現(xiàn)不佳(弱網(wǎng)環(huán)境)
熟悉HTTP2.0協(xié)議的同學(xué)應(yīng)該知道，這些缺點基本都是由于TCP協(xié)議引起的，水能載舟亦能覆舟，其實TCP也很無辜呀！
在我們眼里，TCP是面向連接、可靠的傳輸層協(xié)議，當前幾乎所有重要的協(xié)議和應(yīng)用都是基于TCP來實現(xiàn)的。
網(wǎng)絡(luò)環(huán)境的改變速度很快，但是TCP協(xié)議相對緩慢，正是這種矛盾促使谷歌做出了一個看似出乎意料的決定-基于UDP來開發(fā)新一代HTTP協(xié)議。
2.2 谷歌為什么選擇UDP
上文提到，谷歌選擇UDP是看似出乎意料的，仔細想一想其實很有道理。
我們單純地看看TCP協(xié)議的不足和UDP的一些優(yōu)點：
基于TCP開發(fā)的設(shè)備和協(xié)議非常多，兼容困難
TCP協(xié)議棧是Linux內(nèi)部的重要部分，修改和升級成本很大
從上面的對比可以知道，谷歌要想從TCP上進行改造升級絕非易事，但是UDP雖然沒有TCP為了保證可靠連接而引發(fā)的問題，但是UDP本身不可靠，又不能直接用。
綜合而知，谷歌決定在UDP基礎(chǔ)上改造一個具備TCP協(xié)議優(yōu)點的新協(xié)議也就順理成章了，這個新協(xié)議就是QUIC協(xié)議。
2.3 QUIC協(xié)議和HTTP3.0
QUIC其實是Quick UDP Internet Connections的縮寫，直譯為快速UDP互聯(lián)網(wǎng)連接。
我們來看看維基百科對于QUIC協(xié)議的一些介紹：
QUIC協(xié)議最初由Google的Jim Roskind設(shè)計，實施并于2012年部署，在2013年隨著實驗的擴大而公開宣布，并向IETF進行了描述。
QUIC提高了當前正在使用TCP的面向連接的Web應(yīng)用程序的性能。它在兩個端點之間使用用戶數(shù)據(jù)報協(xié)議（UDP）建立多個復(fù)用連接來實現(xiàn)此目的。
QUIC的次要目標包括減少連接和傳輸延遲，在每個方向進行帶寬估計以避免擁塞。它還將擁塞控制算法移動到用戶空間，而不是內(nèi)核空間，此外使用前向糾錯（FEC）進行擴展，以在出現(xiàn)錯誤時進一步提高性能。
HTTP3.0又稱為HTTP Over QUIC，其棄用TCP協(xié)議，改為使用基于UDP協(xié)議的QUIC協(xié)議來實現(xiàn)。
QUIC協(xié)議詳解擇其善者而從之，其不善者而改之。
HTTP3.0既然選擇了QUIC協(xié)議，也就意味著HTTP3.0基本繼承了HTTP2.0的強大功能，并且進一步解決了HTTP2.0存在的一些問題，同時必然引入了新的問題。
QUIC協(xié)議必須要實現(xiàn)HTTP2.0在TCP協(xié)議上的重要功能，同時解決遺留問題，我們來看看QUIC是如何實現(xiàn)的。
3.1 隊頭阻塞問題
隊頭阻塞 Head-of-line blocking（縮寫為HOL blocking）是計算機網(wǎng)絡(luò)中是一種性能受限的現(xiàn)象，通俗來說就是：一個數(shù)據(jù)包影響了一堆數(shù)據(jù)包，它不來大家都走不了。
隊頭阻塞問題可能存在于HTTP層和TCP層，在HTTP1.x時兩個層次都存在該問題。
HTTP2.0協(xié)議的多路復(fù)用機制解決了HTTP層的隊頭阻塞問題，但是在TCP層仍然存在隊頭阻塞問題。
TCP協(xié)議在收到數(shù)據(jù)包之后，這部分數(shù)據(jù)可能是亂序到達的，但是TCP必須將所有數(shù)據(jù)收集排序整合后給上層使用，如果其中某個包丟失了，就必須等待重傳，從而出現(xiàn)某個丟包數(shù)據(jù)阻塞整個連接的數(shù)據(jù)使用。
QUIC協(xié)議是基于UDP協(xié)議實現(xiàn)的，在一條鏈接上可以有多個流，流與流之間是互不影響的，當一個流出現(xiàn)丟包影響范圍非常小，從而解決隊頭阻塞問題。
3.2 0RTT 建鏈
衡量網(wǎng)絡(luò)建鏈的常用指標是RTT Round-Trip Time，也就是數(shù)據(jù)包一來一回的時間消耗。
RTT包括三部分：往返傳播時延、網(wǎng)絡(luò)設(shè)備內(nèi)排隊時延、應(yīng)用程序數(shù)據(jù)處理時延。
一般來說HTTPS協(xié)議要建立完整鏈接包括:TCP握手和TLS握手，總計需要至少2-3個RTT，普通的HTTP協(xié)議也需要至少1個RTT才可以完成握手。
然而，QUIC協(xié)議可以實現(xiàn)在第一個包就可以包含有效的應(yīng)用數(shù)據(jù)，從而實現(xiàn)0RTT，但這也是有條件的。
簡單來說，基于TCP協(xié)議和TLS協(xié)議的HTTP2.0在真正發(fā)送數(shù)據(jù)包之前需要花費一些時間來完成握手和加密協(xié)商，完成之后才可以真正傳輸業(yè)務(wù)數(shù)據(jù)。
但是QUIC則第一個數(shù)據(jù)包就可以發(fā)業(yè)務(wù)數(shù)據(jù)，從而在連接延時有很大優(yōu)勢，可以節(jié)約數(shù)百毫秒的時間。
QUIC的0RTT也是需要條件的，對于第一次交互的客戶端和服務(wù)端0RTT也是做不到的，畢竟雙方完全陌生。
因此，QUIC協(xié)議可以分為首次連接和非首次連接，兩種情況進行討論。
3.3 首次連接和非首次連接
使用QUIC協(xié)議的客戶端和服務(wù)端要使用1RTT進行密鑰交換，使用的交換算法是DH(Diffie-Hellman)迪菲-赫爾曼算法。
DH算法開辟了密鑰交換的新思路，在之前的文章中提到的RSA算法也是基于這種思想實現(xiàn)的，但是DH算法和RSA的密鑰交換不完全一樣，感興趣的讀者可以看看DH算法的數(shù)學(xué)原理。
3.3.1 首次連接
簡單來說一下，首次連接時客戶端和服務(wù)端的密鑰協(xié)商和數(shù)據(jù)傳輸過程，其中涉及了DH算法的基本過程：
客戶端對于首次連接的服務(wù)端先發(fā)送client hello請求。
服務(wù)端生成一個素數(shù)p和一個整數(shù)g，同時生成一個隨機數(shù) (筆誤-此處應(yīng)該是Ks_pri)為私鑰，然后計算出公鑰 = mod p，服務(wù)端將，p，g三個元素打包稱為config，后續(xù)發(fā)送給客戶端。
客戶端隨機生成一個自己的私鑰，再從config中讀取g和p，計算客戶端公鑰 = mod p。
客戶端使用自己的私鑰和服務(wù)端發(fā)來的config中讀取的服務(wù)端公鑰，生成后續(xù)數(shù)據(jù)加密用的密鑰K = mod p。
客戶端使用密鑰K加密業(yè)務(wù)數(shù)據(jù)，并追加自己的公鑰，都傳遞給服務(wù)端。
服務(wù)端根據(jù)自己的私鑰和客戶端公鑰生成客戶端加密用的密鑰K = mod p。
為了保證數(shù)據(jù)安全，上述生成的密鑰K只會生成使用1次，后續(xù)服務(wù)端會按照相同的規(guī)則生成一套全新的公鑰和私鑰，并使用這組公私鑰生成新的密鑰M。
服務(wù)端將新公鑰和新密鑰M加密的數(shù)據(jù)發(fā)給客戶端，客戶端根據(jù)新的服務(wù)端公鑰和自己原來的私鑰計算出本次的密鑰M，進行解密。
之后的客戶端和服務(wù)端數(shù)據(jù)交互都使用密鑰M來完成，密鑰K只使用1次。
3.3.2 非首次連接
前面提到客戶端和服務(wù)端首次連接時服務(wù)端傳遞了config包，里面包含了服務(wù)端公鑰和兩個隨機數(shù)，客戶端會將config存儲下來，后續(xù)再連接時可以直接使用，從而跳過這個1RTT，實現(xiàn)0RTT的業(yè)務(wù)數(shù)據(jù)交互。
客戶端保存config是有時間期限的，在config失效之后仍然需要進行首次連接時的密鑰交換。
3.4 前向安全問題
前向安全是密碼學(xué)領(lǐng)域的專業(yè)術(shù)語，看下百度上的解釋：
前向安全或前向保密Forward Secrecy是密碼學(xué)中通訊協(xié)議的安全屬性，指的是長期使用的主密鑰泄漏不會導(dǎo)致過去的會話密鑰泄漏。
前向安全能夠保護過去進行的通訊不受密碼或密鑰在未來暴露的威脅，如果系統(tǒng)具有前向安全性，就可以保證在主密鑰泄露時歷史通訊的安全，即使系統(tǒng)遭到主動攻擊也是如此。
通俗來說，前向安全指的是密鑰泄漏也不會讓之前加密的數(shù)據(jù)被泄漏，影響的只有當前，對之前的數(shù)據(jù)無影響。
前面提到QUIC協(xié)議首次連接時先后生成了兩個加密密鑰，由于config被客戶端存儲了，如果期間服務(wù)端私鑰泄漏，那么可以根據(jù)K = mod p計算出密鑰K。
如果一直使用這個密鑰進行加解密，那么就可以用K解密所有歷史消息，因此后續(xù)又生成了新密鑰，使用其進行加解密，當時完成交互時則銷毀，從而實現(xiàn)了前向安全。
3.5 前向糾錯
前向糾錯是通信領(lǐng)域的術(shù)語，看下百科的解釋：
前向糾錯也叫前向糾錯碼Forward Error Correction 簡稱FEC 是增加數(shù)據(jù)通訊可信度的方法，在單向通訊信道中，一旦錯誤被發(fā)現(xiàn)，其接收器將無權(quán)再請求傳輸。
FEC 是利用數(shù)據(jù)進行傳輸冗余信息的方法，當傳輸中出現(xiàn)錯誤，將允許接收器再建數(shù)據(jù)。
聽這段描述就是做校驗的，看看QUIC協(xié)議是如何實現(xiàn)的：
QUIC每發(fā)送一組數(shù)據(jù)就對這組數(shù)據(jù)進行異或運算，并將結(jié)果作為一個FEC包發(fā)送出去，接收方收到這一組數(shù)據(jù)后根據(jù)數(shù)據(jù)包和FEC包即可進行校驗和糾錯。
3.6 連接遷移
網(wǎng)絡(luò)切換幾乎無時無刻不在發(fā)生。
TCP協(xié)議使用五元組來表示一條唯一的連接，當我們從4G環(huán)境切換到wifi環(huán)境時，手機的IP地址就會發(fā)生變化，這時必須創(chuàng)建新的TCP連接才能繼續(xù)傳輸數(shù)據(jù)。
QUIC協(xié)議基于UDP實現(xiàn)摒棄了五元組的概念，使用64位的隨機數(shù)作為連接的ID，并使用該ID表示連接。
基于QUIC協(xié)議之下，我們在日常wifi和4G切換時，或者不同基站之間切換都不會重連，從而提高業(yè)務(wù)層的體驗。
QUIC的應(yīng)用和前景通過前面的一些介紹我們看出來QUIC協(xié)議雖然是基于UDP來實現(xiàn)的，但是它將TCP的重要功能都進行了實現(xiàn)和優(yōu)化，否則使用者是不會買賬的。
QUIC協(xié)議的核心思想是將TCP協(xié)議在內(nèi)核實現(xiàn)的諸如可靠傳輸、流量控制、擁塞控制等功能轉(zhuǎn)移到用戶態(tài)來實現(xiàn)，同時在加密傳輸方向的嘗試也推動了TLS1.3的發(fā)展。
但是TCP協(xié)議的勢力過于強大，很多網(wǎng)絡(luò)設(shè)備甚至對于UDP數(shù)據(jù)包做了很多不友好的策略，進行攔截從而導(dǎo)致成功連接率下降。
主導(dǎo)者谷歌在自家產(chǎn)品做了很多嘗試，國內(nèi)騰訊公司也做了很多關(guān)于QUIC協(xié)議的嘗試。
其中騰訊云對QUIC協(xié)議表現(xiàn)了很大的興趣，并做了一些優(yōu)化然后在一些重點產(chǎn)品中對連接遷移、QUIC成功率、弱網(wǎng)環(huán)境耗時等進行了實驗，給出了來自生產(chǎn)環(huán)境的諸多寶貴數(shù)據(jù)。
簡單看一組騰訊云在移動互聯(lián)網(wǎng)場景下的不同丟包率下的請求耗時分布：
任何新生事物的推動都是需要時間的，出現(xiàn)多年的HTTP2.0和HTTPS協(xié)議的普及度都沒有預(yù)想高，IPv6也是如此，不過QUIC已經(jīng)展現(xiàn)了強大的生命力，讓我們拭目以待吧！
本文小結(jié)網(wǎng)絡(luò)協(xié)議本身就很復(fù)雜，本文只能從整體出發(fā)對重要的部分做粗淺的闡述，如果對某個點很感興趣，可以查閱相關(guān)代碼和RFC文檔。
我們之前可能遇到過這個面試題：
如何用UDP協(xié)議來實現(xiàn)TCP協(xié)議的主要功能。
我確實筆試遇到過這道題，可以說很抓狂，題目太宏大了。
不過現(xiàn)在看看QUIC協(xié)議就回答了這個問題：基于UDP主體將TCP的重要功能轉(zhuǎn)移到用戶空間來實現(xiàn)，從而繞開內(nèi)核實現(xiàn)用戶態(tài)的TCP協(xié)議，但是真正實現(xiàn)起來還是非常復(fù)雜的。
技術(shù)進步也非朝夕之功，需要在實踐中反復(fù)錘煉。
最后感謝各位的傾情安排，歡迎文末積極討論哦！
