[[340127]]

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

背景

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

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

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

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

其實(shí)這個(gè)問(wèn)題的答案不難想出，我們可以將TCP和UDP的特性互相結(jié)合起來(lái)，讓這個(gè)協(xié)議既可以保證可靠性，又可以保證實(shí)時(shí)性，這也就是我們所說(shuō)的RUDP((Reliable UDP)，常見(jiàn)的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(wú)連接的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ā)展這么久了但是對(duì)于TCP來(lái)說(shuō)發(fā)展依舊緩慢，要說(shuō)最大的改進(jìn)應(yīng)該是Google 在 ACM CoNEXT 會(huì)議上發(fā)表的用于改善 Web 應(yīng)用響應(yīng)延時(shí)TCP Fast Open，通過(guò)修改 TCP 協(xié)議利用三次握手時(shí)進(jìn)行數(shù)據(jù)交換，這個(gè)在Linux內(nèi)核 3.7.1 以及更高版本可以支持。由于修改TCP協(xié)議必然會(huì)修改內(nèi)核從而導(dǎo)致系統(tǒng)升級(jí)，這個(gè)推動(dòng)的難度非常之大。

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

誰(shuí)在使用它?

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

QUIC為什么這么牛?

0RTT 建立鏈接

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

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

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

更為出色擁塞控制

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

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

更好的重傳機(jī)制

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

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

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

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

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

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

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

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

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

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

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

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

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

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

連接遷移

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

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

其他

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

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

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

總結(jié)

其實(shí)這篇帖子也算是一個(gè)掃盲貼，相信有很多朋友沒(méi)有聽(tīng)說(shuō)過(guò)RUDP相關(guān)的一些東西，或者說(shuō)聽(tīng)說(shuō)過(guò)但是一直以為他是一個(gè)很復(fù)雜，很難理解的東西，其實(shí)在這里攤開(kāi)來(lái)講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é)議的分析，性能測(cè)試以及在QQ會(huì)員實(shí)踐:https://www.cnblogs.com/wetest/p/9022214.html