[[340127]]

本文轉(zhuǎn)載自微信公眾號「咖啡拿鐵 」，作者咖啡拿鐵。轉(zhuǎn)載本文請聯(lián)系咖啡拿鐵公眾號。

背景

又是一年一度的秋季校招開始了，以往的校招各個(gè)公司都會在公司現(xiàn)場或者學(xué)校現(xiàn)場安排學(xué)生進(jìn)行現(xiàn)場面試?但是今年由于疫情的原因，不允許讓同學(xué)在現(xiàn)場進(jìn)行一個(gè)面試，所以今年的面試形式就從線下轉(zhuǎn)到了線上，面試形式的轉(zhuǎn)變，但是我們考核學(xué)生的方式依舊沒有轉(zhuǎn)變。

校招的同學(xué)和社招的同學(xué)有很大的不同，他們沒有豐富的工作經(jīng)驗(yàn)，沒有太多的項(xiàng)目經(jīng)歷，那么我們?nèi)绾稳ズ饬恳粋€(gè)校招的同學(xué)呢?那就是基礎(chǔ)和潛力，怎么去理解基礎(chǔ)呢?俗話說不積跬步,無以至千里,不積小流,無以成江海，如果沒有一個(gè)好的基礎(chǔ)那么怎么才能成為一個(gè)優(yōu)秀的工程師呢。如何去考察一個(gè)學(xué)生基礎(chǔ)的好壞呢?我覺得有三個(gè)方面比較重要，計(jì)算機(jī)網(wǎng)絡(luò)，操作系統(tǒng)以及算法和數(shù)據(jù)結(jié)構(gòu)，通常來說計(jì)網(wǎng)考察得特別多，常見的一些問題：

• 網(wǎng)絡(luò)模型分層
• TCP和UDP的區(qū)別
• TCP三次握手和四次揮手
• HTTP各版本的區(qū)別

上面列舉的問題只是其中一部分，這些問題基本在上課的書本中找到答案，如果你這些都不會那么只能說基礎(chǔ)算是比較差了。由于這次是視頻面試，我通常會問你覺得牛客網(wǎng)的視頻面試是用的TCP還是UDP呢?在我揭曉答案之前大家也可以想想使用的是哪個(gè)網(wǎng)絡(luò)協(xié)議，在面試的過程中所有的同學(xué)都回答了應(yīng)該是使用的是UDP。我問為什么使用UDP?基本都會回答道UDP是一個(gè)無連接的協(xié)議，不用保證可靠性，傳輸速度快。我又問道如果UDP不保證可靠性，咱們在視頻面試的時(shí)候我問你問題，如果你回答問題的視頻流丟包了，那么你的答案我就聽不見了，那視頻面試的體驗(yàn)將會非常低。不少同學(xué)在這個(gè)時(shí)候就會改答案說那應(yīng)該使用的是TCP吧，我這是又會問道TCP由于需要保證可靠性，但是在公網(wǎng)的復(fù)雜環(huán)境下，想必應(yīng)該經(jīng)常會出現(xiàn)緩沖或者卡頓的現(xiàn)象吧，很多同學(xué)這個(gè)時(shí)候就會啞口無言了。

其實(shí)這個(gè)問題的答案不難想出，我們可以將TCP和UDP的特性互相結(jié)合起來，讓這個(gè)協(xié)議既可以保證可靠性，又可以保證實(shí)時(shí)性，這也就是我們所說的RUDP((Reliable UDP)，常見的RUDP協(xié)議有QUIC,WebRTC,Aeron等等，我這里主要介紹谷歌提出的QUIC，帶大家領(lǐng)略一下RUDP的精彩，看看他們是如何既能做到可靠又能保證效率。

QUIC

QUIC(Quick UDP Internet Connection)是Google公司提出的基于UDP的高效可靠協(xié)議，他和HTTP一樣同樣是應(yīng)用層協(xié)議。

為什么高效呢?是因?yàn)槠浠跓o連接的UDP而不是基于TCP去實(shí)現(xiàn)的。

為什么可靠呢?因?yàn)槠淠７耇CP協(xié)議的可靠性，在應(yīng)用層上做了可靠性的保證。

為什么需要QUIC?

互聯(lián)網(wǎng)已經(jīng)發(fā)展了幾十年了，但是一提到網(wǎng)絡(luò)協(xié)議，傳輸層使用得最多的還是TCP協(xié)議，應(yīng)用層使用得最多的是HTTP協(xié)議，當(dāng)然HTTP底層也是使用得TCP協(xié)議。雖然互聯(lián)網(wǎng)已經(jīng)發(fā)展這么久了但是對于TCP來說發(fā)展依舊緩慢，要說最大的改進(jìn)應(yīng)該是Google 在 ACM CoNEXT 會議上發(fā)表的用于改善 Web 應(yīng)用響應(yīng)延時(shí)TCP Fast Open，通過修改 TCP 協(xié)議利用三次握手時(shí)進(jìn)行數(shù)據(jù)交換，這個(gè)在Linux內(nèi)核 3.7.1 以及更高版本可以支持。由于修改TCP協(xié)議必然會修改內(nèi)核從而導(dǎo)致系統(tǒng)升級，這個(gè)推動的難度非常之大。

既然我們修改內(nèi)核不行，那么Google就提出了在應(yīng)用層協(xié)議上修改的辦法，也就有了QUIC。

誰在使用它?

首先使用它的人肯定是谷歌，據(jù)說谷歌有50%的請求都是QUIC協(xié)議，微博也在全面使用QUIC協(xié)議，同時(shí)還有一些視頻云服務(wù)比如七牛也在使用，在騰訊內(nèi)部也有很多部門在大量使用QUIC，所以不需要擔(dān)心這個(gè)協(xié)議使用的問題。

QUIC為什么這么牛?

0RTT 建立鏈接

RTT((Round-Trip Time)顧名思義就是往返時(shí)延的意思，0RTT的話意思就是QUIC可以在第一次發(fā)送的時(shí)候就帶上數(shù)據(jù)，熟悉我們TCP的同學(xué)應(yīng)該知道，TCP會有一個(gè)三次握手那么實(shí)際上也就是會有1次RTT:

如果是HTTPS的話還會使用SSL/TLS的額外握手，就會有3次RTT：

那么0RTT的建立鏈接QUIC是怎么做到的呢?這里得先說一下QUIC的0RTT并不是完全的0RTT,他同樣需要1RTT去做一次秘鑰協(xié)商，在QUIC中使用的是Diffie-Hellman密鑰交換，該算法是一種建立密鑰的方法，并非加密方法，但其產(chǎn)生的密鑰可用于加密、密鑰管理或任何其它的加密方式，這種密鑰交換技術(shù)的目的在于使兩個(gè)用戶間能安全地交換密鑰(KEY)以便用于今后的報(bào)文加密。DH算法用了離散對數(shù)的相關(guān)知識，這里就不擴(kuò)展講解，有興趣的可以下來搜索這種算法。QUIC通過DH算法創(chuàng)建一個(gè)安全的連接后，客戶端會緩存起來原始的連接信息等。在后續(xù)的過程中只要和同一個(gè)服務(wù)器建立鏈接都是直接發(fā)送數(shù)據(jù)，不需要再次協(xié)商秘鑰，從而實(shí)現(xiàn)了后續(xù)的0RTT。

更為出色擁塞控制

TCP的擁塞控制的算法特別多，比如基于丟包反饋的(Tahoe、Reno、New Reno、SACK), 基于延時(shí)反饋的(Vegas、Westwood)，其中的Reno也就是我們最為熟悉的，它分為四個(gè)階段：慢啟動，擁塞避免，快速重傳，快速恢復(fù)。

而在QUIC中使用了更為優(yōu)秀的機(jī)制來控制擁塞控制，它可以針對不同業(yè)務(wù)，不同網(wǎng)絡(luò)制式，甚至不同的RTT，使用不同的擁塞控制算法。同時(shí)也會采用了packet pacing來探測網(wǎng)絡(luò)帶寬，來提升網(wǎng)絡(luò)使用率。

更好的重傳機(jī)制

在重傳的機(jī)制中有一個(gè)比較重要的名詞，那就是RTO(Retransmission Timeout) 重傳超時(shí)時(shí)間，一般這個(gè)數(shù)據(jù)會根據(jù)RTT去進(jìn)行計(jì)算，那么我們有一個(gè)更精確的RTT肯定就可以有一個(gè)更好的RTO。

在TCP中重傳的時(shí)候序列號不變，會導(dǎo)致我們的RTT算得不準(zhǔn)確，比如重傳的時(shí)候你不知道你這次請求到底是和原始請求匹配還是和重試請求匹配，就會導(dǎo)致我們的采樣RTT不準(zhǔn)確。

在QUIC中序列號都是遞增的，并且通過offset來確定在包中的真實(shí)位置，這樣就可以得到更為準(zhǔn)確的RTT。

在TCP中計(jì)算RTT的方法就是發(fā)出的時(shí)間和響應(yīng)回來的時(shí)間相減，但是這樣算出的時(shí)間不準(zhǔn)確，在QUIC中會減去服務(wù)端Ack Delay的時(shí)間，這樣的話就更為精準(zhǔn)。

同樣的在TCP中有個(gè)SACK選項(xiàng)，該選項(xiàng)打開時(shí)用于記錄傳輸過程中一些沒有被確認(rèn)的數(shù)據(jù)的范圍，便于后續(xù)定向重傳多組丟失數(shù)據(jù)，而不是全部重傳，所以更多的范圍便于更多的選擇重傳，也意味著更少的重傳包頻率。但TCP最多支持3個(gè)SACK范圍，而QUIC能支持255個(gè)。

沒有隊(duì)頭阻塞的多路復(fù)用

熟悉HTTP2.0的同學(xué)應(yīng)該知道在2.0中如果訪問同一個(gè)服務(wù)器只會有一個(gè)TCP連接，所有的請求都會走這條連接：

而每個(gè)請求在Connection中叫做Stream,一個(gè)Connection中可以有多個(gè)Stream，這里有個(gè)問題是在TCP中的包是保證時(shí)序的，如果某個(gè)Stream丟了一個(gè)包，他同時(shí)也會影響其他的Stream，在更為嚴(yán)重的時(shí)候反而多路復(fù)用還不如HTTP1.1的多個(gè)鏈接。

而在QUIC中，因?yàn)榈讓邮腔赨DP,UDP不需要保證包的時(shí)序，只會在接收包的時(shí)候?qū)ΠM(jìn)行重組，所以不會存在這個(gè)問題。這也就是為什么Google提議在HTTP3中使用QUIC的原因。

更優(yōu)秀的流量控制

上面說了QUIC是多路復(fù)用的，在QUIC中可以針對Stream和Connection都進(jìn)行流量控制。

QUIC 的流量控制和 TCP 有點(diǎn)區(qū)別，TCP 為了保證可靠性，窗口左邊沿向右滑動時(shí)的長度取決于已經(jīng)確認(rèn)的字節(jié)數(shù)。如果中間出現(xiàn)丟包，就算接收到了更大序號的 Segment，窗口也無法超過這個(gè)序列號。

但 QUIC 不同，就算此前有些 packet 沒有接收到，它的滑動只取決于接收到的最大偏移字節(jié)數(shù)。

最重要的是我們可以進(jìn)行動態(tài)配置，可以在內(nèi)存不足或者上游處理性能出現(xiàn)問題時(shí)，通過流量控制來限制傳輸速率，保障服務(wù)可用性。

連接遷移

現(xiàn)在在手機(jī)上移動流量和wifi的切換是一個(gè)比較常見的事，每次切換ip地址都會發(fā)生變化，如果是TCP的話連接就會中斷從而進(jìn)行重新建立鏈接。

在QUIC不再以 IP 及端口四元組標(biāo)識，而是以一個(gè) 64 位的隨機(jī)數(shù)作為 ID 來標(biāo)識，通過這樣的方式可以進(jìn)行連接重復(fù)利用，不會重新建立新的連接。

其他

在QUIC中還有更多的其他的特性，比如：

• 通過header stream保證流順序
• 底層保證連接持久
• 源地址令牌防止地址欺騙
• 握手時(shí)壓縮證書避免放大攻擊這里就不一一介紹了

這里就不詳解介紹了，大家可以自行查閱資料搜索。

總結(jié)

其實(shí)這篇帖子也算是一個(gè)掃盲貼，相信有很多朋友沒有聽說過RUDP相關(guān)的一些東西，或者說聽說過但是一直以為他是一個(gè)很復(fù)雜，很難理解的東西，其實(shí)在這里攤開來講RUDP就是一個(gè)UDP+應(yīng)用層可靠協(xié)議組成的，希望大家看完這篇文章后，能有所收獲。

參考文章：QUIC協(xié)議是如何做到0RTT加密傳輸?shù)? https://blog.csdn.net/dog250/article/details/80935534

技術(shù)掃盲-新一代基于UDP的低延時(shí)網(wǎng)絡(luò)傳輸層協(xié)議——QUIC詳解 :http://www.52im.net/thread-1309-1-1.html

QUIC協(xié)議的分析，性能測試以及在QQ會員實(shí)踐:https://www.cnblogs.com/wetest/p/9022214.html