背景

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

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

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

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

其實(shí)這個問題的答案不難想出，我們可以將TCP和UDP的特性互相結(jié)合起來，讓這個協(xié)議既可以保證可靠性，又可以保證實(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)延時TCP Fast Open，通過修改 TCP 協(xié)議利用三次握手時進(jìn)行數(shù)據(jù)交換，這個在Linux內(nèi)核 3.7.1 以及更高版本可以支持。由于修改TCP協(xié)議必然會修改內(nèi)核從而導(dǎo)致系統(tǒng)升級，這個推動的難度非常之大。

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

誰在使用它？

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

QUIC為什么這么牛？

0RTT 建立鏈接

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

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

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

更為出色擁塞控制

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

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

更好的重傳機(jī)制

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

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

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

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

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

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

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

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

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

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

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

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

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

連接遷移

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

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

其他

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

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

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

總結(jié)

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

參考文章：

QUIC協(xié)議是如何做到0RTT加密傳輸?shù)? https://blog.csdn.net/dog250/article/details/80935534
技術(shù)掃盲-新一代基于UDP的低延時網(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