https://www.toutiao.com/article/7276405067992039997/?log_from=889d51c2dae79_1700529710744
作者介紹
李龍彥，網(wǎng)絡(luò)技術(shù)專家，多年網(wǎng)絡(luò)協(xié)議棧開發(fā)經(jīng)驗(yàn)。
分享概要
一、HTTP/1.1簡(jiǎn)單介紹
二、HTTP/2介紹
三、HTTP/3介紹
四、結(jié)語(yǔ)
五、Q&A
一、HTTP/1.1簡(jiǎn)單介紹
與HTTP/1.0相比，HTTP/1.1主要有兩個(gè)新的特性：keepalive和pipelining。
Keepalive實(shí)現(xiàn)了連接復(fù)用的功能，從而達(dá)到了“長(zhǎng)連接”的目的。長(zhǎng)連接即是長(zhǎng)期存活不關(guān)閉的連接，短連接是連接用完之后就關(guān)掉的連接。
那什么情況下需要長(zhǎng)連接呢？ 如果一個(gè)業(yè)務(wù)的連接需要不停地傳輸數(shù)據(jù)，需要長(zhǎng)期不間斷地傳輸數(shù)據(jù)，那么它就需要“長(zhǎng)連接”，需要用心跳包來(lái)保證連接的活性。
如果業(yè)務(wù)有多個(gè)請(qǐng)求需要發(fā)送，那么連接復(fù)用無(wú)疑是給業(yè)務(wù)帶來(lái)了非常大的便利。在資源消耗上，不需要頻繁地建立和銷毀連接，節(jié)省了不少資源；在速度上，每次建立連接都至少需要TCP三次握手，https的話還額外需要TLS四次握手，這會(huì)增加很多網(wǎng)絡(luò)耗時(shí)。
HTTP/1.1另一個(gè)重要的特性就是pipeling，流水線幫助HTTP/1.1實(shí)現(xiàn)了并發(fā)連接的功能。
如果你的業(yè)務(wù)有多個(gè)請(qǐng)求，而且請(qǐng)求之間沒(méi)有先后依賴關(guān)系，那么使用并發(fā)功能無(wú)疑可以成倍地提升訪問(wèn)速度，以前在一個(gè)連接中，請(qǐng)求需要串行地進(jìn)行，第一個(gè)請(qǐng)求必須成功了之后才能發(fā)起第二個(gè)請(qǐng)求；多個(gè)請(qǐng)求就要排著隊(duì)逐一等待進(jìn)行，有了pipelining功能，就可以并發(fā)進(jìn)行（最多并發(fā)6個(gè)）。節(jié)省時(shí)間的同時(shí)，也造成了資源消耗的增加。
二、HTTP/2介紹
二進(jìn)制幀。幀：HTTP/2 數(shù)據(jù)通信的最小單位消息：指 HTTP/2 中邏輯上的 HTTP 消息。例如請(qǐng)求和響應(yīng)等，消息由一個(gè)或多個(gè)幀組成。HTTP/2 采用二進(jìn)制格式傳輸數(shù)據(jù)，而非 HTTP 1.x 的文本格式，二進(jìn)制協(xié)議解析起來(lái)更高效。HTTP / 1 的請(qǐng)求和響應(yīng)報(bào)文，都是由起始行，首部和實(shí)體正文（可選）組成，各部分之間以文本換行符分隔。HTTP/2 將請(qǐng)求和響應(yīng)數(shù)據(jù)分割為更小的幀，并且它們采用二進(jìn)制編碼。
流：存在于連接中的一個(gè)虛擬通道。流可以承載雙向消息，每個(gè)流都有一個(gè)唯一的整數(shù)ID。
如果把連接比作一條馬路的話，我們可以粗略地把“流”比作這條馬路上的一個(gè)個(gè)車道。
為什么需要流呢？為了并發(fā)！但是前面HTTP/1.1的pipelining不是已經(jīng)實(shí)現(xiàn)了并發(fā)了嗎？這里有兩點(diǎn)區(qū)別：
首先“流”的個(gè)數(shù)原則上是不受限制的，不像連接，一般最多只能創(chuàng)建6個(gè)，也就是最大并發(fā)量是6個(gè)，而流可以更多；
其次，“流”的創(chuàng)建和銷毀帶來(lái)的資源的消耗遠(yuǎn)遠(yuǎn)低于“連接”。
實(shí)際上數(shù)據(jù)傳輸中，TCP連接是不認(rèn)識(shí)“流”的，對(duì)于TCP連接來(lái)說(shuō)，所有的數(shù)據(jù)包都是這條連接上的，它無(wú)法區(qū)分當(dāng)前數(shù)據(jù)包是哪個(gè)“流”。所以在TCP傳輸過(guò)程中，所有流的數(shù)據(jù)包都是混合在一起進(jìn)行傳輸?shù)?。那么只有在HTTP應(yīng)用層面才可以看到“流”ID，才能識(shí)別出當(dāng)前的數(shù)據(jù)是屬于哪條流的。一般情況下，一條流就代表了一個(gè)請(qǐng)求。
為什么你的業(yè)務(wù)用了HTTP/2，效果可能還不如HTTP/1.1？
多流并發(fā)帶來(lái)了請(qǐng)求優(yōu)先級(jí)的問(wèn)題，因?yàn)橛械恼?qǐng)求客戶端（比如瀏覽器）希望它能盡快返回，有的請(qǐng)求可以晚點(diǎn)返回；又或者有的請(qǐng)求需要依賴別的請(qǐng)求的資源來(lái)展示。這也是為什么引入流的優(yōu)先級(jí)和流依賴。
流的優(yōu)先級(jí)表示了這個(gè)請(qǐng)求被處理的優(yōu)先級(jí)，比如客戶端請(qǐng)求的關(guān)鍵的CSS和JS資源是必須高優(yōu)先級(jí)返回的，圖片、視頻等資源可以晚一點(diǎn)響應(yīng)。
流的優(yōu)先級(jí)的設(shè)置是一個(gè)難以平衡或者難以做到公平合理的事情，如果設(shè)置稍微不恰當(dāng)，就會(huì)導(dǎo)致有些請(qǐng)求很慢，這在用戶看來(lái)，就是用了HTTP/2之后，怎么有的請(qǐng)求變慢了。
HTTP/2解決了HTTP協(xié)議層面的隊(duì)頭阻塞，但是TCP的隊(duì)頭阻塞仍然沒(méi)有解決，所有的流都在一條TCP連接上，如果萬(wàn)一序號(hào)小的某個(gè)包丟了，那么TCP為了保證到達(dá)的有序性，必須等這個(gè)包到達(dá)后才能滑動(dòng)窗口，即使后面的序號(hào)大的包已經(jīng)到達(dá)了也不能被應(yīng)用程序讀取。
這就導(dǎo)致了在多條流并發(fā)的時(shí)候，某條流的某個(gè)包丟了，序號(hào)在該包后面的其他流的數(shù)據(jù)都不能被應(yīng)用程序讀取。
這種情況下如果換作HTTP/1.1，由于HTTP/1.1是多條連接，某個(gè)連接上的請(qǐng)求丟包了，并不影響其他連接。所以在丟包比較嚴(yán)重的情況下，HTTP/2整體效果大概率不如HTTP/1.1。
什么情況下使用HTTP/2比較合適呢？
三、HTTP/3介紹
從一個(gè)小請(qǐng)求說(shuō)起。我們知道，一個(gè)HTTPS請(qǐng)求會(huì)經(jīng)歷四個(gè)階段：DNS解析，TCP三次握手建連，TLS四次握手協(xié)商會(huì)話密鑰，應(yīng)用請(qǐng)求的發(fā)送和應(yīng)答。對(duì)于一個(gè)小請(qǐng)求而言，TCP建連需要消耗1個(gè)RTT（數(shù)據(jù)包的往返時(shí)間），TLS建連需要消耗2個(gè)RTT，用戶數(shù)據(jù)的傳輸需要消耗1個(gè)RTT。那么總共需要消耗DNS+4RTT的時(shí)間。
在這么長(zhǎng)時(shí)間中，只有1個(gè)RTT是真正用戶傳輸應(yīng)用數(shù)據(jù)的，所以我們可以認(rèn)為：性價(jià)比很低，為了傳輸1個(gè)RTT的數(shù)據(jù)，前面需要消耗那么長(zhǎng)時(shí)間進(jìn)行建連。那么對(duì)于這種情況，能不能更快速地進(jìn)行建連呢？這就是HTTP/3要解決的頭等大事！HTTP/3底層不再使用TCP，改用QUIC協(xié)議達(dá)到了更高效的傳輸速度。
QUIC的全稱是Quickly UDP Internet Connection，所以QUIC的特點(diǎn)就是一個(gè)字，快！QUIC基于UDP，又將TCP的安全可靠傳輸特性移植過(guò)來(lái)，再把TLS1.3標(biāo)準(zhǔn)協(xié)議拿過(guò)來(lái)，融合了一個(gè)協(xié)議叫QUIC，基于QUIC協(xié)議的HTTP協(xié)議，更新了一個(gè)版本號(hào)，這就是HTTP/3。
事實(shí)上，我們并不是真的需要更新HTTP版本，而是需要對(duì)底層傳輸協(xié)議進(jìn)行升級(jí)！
接下來(lái)我們將圍繞QUIC協(xié)議的5個(gè)特性進(jìn)行詳細(xì)介紹。
特點(diǎn)一：0-RTT握手
對(duì)比TCP+TLS協(xié)議，QUIC協(xié)議的握手非常簡(jiǎn)潔。
傳統(tǒng)基于TCP的HTTPS的建連過(guò)程為什么如此慢？它需要TCP和TLS兩個(gè)建連過(guò)程。
為什么需要兩個(gè)過(guò)程？可惡就可惡在這個(gè)地方，TCP和TLS沒(méi)辦法合并，因?yàn)門CP是在內(nèi)核里完成的，TLS是在用戶態(tài)。也許有人會(huì)說(shuō)把干掉內(nèi)核里的TCP，把TCP挪出來(lái)放到用戶態(tài)，然后就可以和TLS一起處理了。
首先，你干不掉內(nèi)核里的TCP，TCP太古老了，全世界的服務(wù)器的TCP都固化在內(nèi)核里了。所以，既然干不掉TCP，那我不用它了，我再自創(chuàng)一個(gè)傳輸層協(xié)議，放到用戶態(tài)，然后再結(jié)合TLS，這樣不就可以把兩個(gè)建連過(guò)程合二為一了嗎？是的，這就是QUIC。
QUIC的1-RTT建連：客戶端與服務(wù)端初次建連（之前從未進(jìn)行通信過(guò)），或者長(zhǎng)時(shí)間沒(méi)有通信過(guò)（0-RTT過(guò)期了），只能進(jìn)行1-RTT建連。只有先進(jìn)行一次完整的1-RTT建連，后續(xù)一段時(shí)間內(nèi)的通信才可以進(jìn)行0-RTT建連。
1-RTT的握手主要包含兩個(gè)過(guò)程：
注意：在1-RTT握手完成之后，服務(wù)端會(huì)發(fā)送一個(gè)New Session Ticket報(bào)文給客戶端，這個(gè)包非常重要，這是0-RTT實(shí)現(xiàn)的基礎(chǔ)。
client和server在建連時(shí)，仍然需要兩次握手，仍然需要1個(gè)rtt，但是為什么我們說(shuō)這是0-rtt呢，是因?yàn)閏lient在發(fā)送第一個(gè)包c(diǎn)lient hello時(shí)，就帶上了數(shù)據(jù)（HTTP 請(qǐng)求），從什么時(shí)候開始發(fā)送數(shù)據(jù)這個(gè)角度上來(lái)看，的確是0-RTT。
另外需要注意的是，0-RTT存在前向安全問(wèn)題，請(qǐng)謹(jǐn)慎使用！
特點(diǎn)二：連接遷移
QUIC通過(guò)連接ID實(shí)現(xiàn)了連接遷移。
我們經(jīng)常需要在WiFi和4G之間進(jìn)行切換，比如我們?cè)诩依飼r(shí)使用WiFi，出門在路上，切換到4G或5G，到了商場(chǎng)，又連上了商場(chǎng)的WiFi，到了餐廳，又切換到了餐廳的WiFi，所以我們的日常生活中需要經(jīng)常性的切換網(wǎng)絡(luò)，那每一次的切換網(wǎng)絡(luò)，都將導(dǎo)致我們的IP地址發(fā)生變化。
傳統(tǒng)的TCP協(xié)議是以四元組（源IP地址、源端口號(hào)、目的ID地址、目的端口號(hào)）來(lái)標(biāo)識(shí)一條連接，那么一旦四元組的任何一個(gè)元素發(fā)生了改變，這條連接就會(huì)斷掉，那么這條連接中正在傳輸?shù)臄?shù)據(jù)就會(huì)斷掉，切換到新的網(wǎng)絡(luò)后可能需要重新去建立連接，然后重新發(fā)送數(shù)據(jù)。這將會(huì)導(dǎo)致用戶的網(wǎng)絡(luò)會(huì)“卡”一下。
但是，QUIC不再以四元組作為唯一標(biāo)識(shí)，QUIC使用連接ID來(lái)標(biāo)識(shí)一條連接，無(wú)論你的網(wǎng)絡(luò)如何切換，只要連接ID不變，那么這條連接就不會(huì)斷，這就叫連接遷移！
QUIC限制連接遷移為僅客戶端可以發(fā)起，客戶端負(fù)責(zé)發(fā)起所有遷移。如果客戶端接收到了一個(gè)未知的服務(wù)器發(fā)來(lái)的數(shù)據(jù)包，那么客戶端必須丟棄這些數(shù)據(jù)包。
如圖所示，連接遷移過(guò)程總共需要四個(gè)步驟。
連接遷移的實(shí)現(xiàn)，不可避開的兩個(gè)問(wèn)題：一個(gè)是四層負(fù)載均衡器對(duì)連接遷移的影響，一個(gè)是七層負(fù)載均衡器對(duì)連接遷移的影響。
如何解決以上兩個(gè)問(wèn)題？DPVS要想支持QUIC的連接遷移，就不能再以四元組進(jìn)行轉(zhuǎn)發(fā)，需要以連接ID進(jìn)行轉(zhuǎn)發(fā)，需要建立 連接ID與對(duì)應(yīng)的后端服務(wù)器的對(duì)應(yīng)關(guān)系；
QUIC服務(wù)器也是一樣的，內(nèi)核就不能用四元組來(lái)進(jìn)行查找socket，四元組查找不到時(shí)，就必須使用連接ID進(jìn)行查找socket。但是內(nèi)核代碼又不能去修改（不可能去更新所有服務(wù)器的內(nèi)核版本），那么我們可以使用eBPF的方法進(jìn)行解決。
多路復(fù)用解決隊(duì)頭阻塞問(wèn)題
由上圖來(lái)看，假設(shè)有兩個(gè)請(qǐng)求同時(shí)發(fā)送，紅色的是請(qǐng)求1，藍(lán)色的是請(qǐng)求2，這兩個(gè)請(qǐng)求在兩條不同的流中進(jìn)行傳輸。假設(shè)在傳輸過(guò)程中，請(qǐng)求1的某個(gè)數(shù)據(jù)包丟了，如果是TCP，即使請(qǐng)求2的所有數(shù)據(jù)包都收到了，但是也只能阻塞在內(nèi)核緩沖區(qū)中，無(wú)法交給應(yīng)用層。但是QUIC就不一樣了，請(qǐng)求1的數(shù)據(jù)包丟了只會(huì)阻塞請(qǐng)求1，請(qǐng)求2不會(huì)受到阻塞。
有些人不禁發(fā)問(wèn)，不是說(shuō)HTTP2也有流的概念嗎，為什么只有QUIC才能解決呢，這個(gè)根本原因就在于，HTTP2的傳輸層用的TCP，TCP的實(shí)現(xiàn)是在內(nèi)核態(tài)的，而流是實(shí)現(xiàn)在用戶態(tài)度，TCP是看不到“流”的，所以在TCP中，它不知道這個(gè)數(shù)據(jù)包是請(qǐng)求1還是請(qǐng)求2的，只會(huì)根據(jù)seq number來(lái)判斷包的先后順序。
特點(diǎn)三：更優(yōu)秀的擁塞控制算法
擁塞控制算法中最重要的一個(gè)參數(shù)是 RTT，RTT的準(zhǔn)確性決定了擁塞控制算法的準(zhǔn)確性；然而，TCP的RTT測(cè)量往往不準(zhǔn)確，QUIC的RTT測(cè)量是準(zhǔn)確的。
由于網(wǎng)絡(luò)中經(jīng)常出現(xiàn)丟包，需要重傳，在TCP協(xié)議中，初始包和重傳包的序號(hào)是一樣的，擁塞控制算法進(jìn)行計(jì)算RTT的時(shí)候，無(wú)法區(qū)別是初始包還是重傳包，這將導(dǎo)致RTT的計(jì)算值要么偏大，要么偏小。
QUIC通過(guò)Packet Number來(lái)標(biāo)識(shí)包的序號(hào)，而且規(guī)定Packet Number只能單調(diào)遞增，這也就解決了初始包和重傳包的二義性。從而保證RTT的值是準(zhǔn)確的。
另外，不同于TCP，QUIC的擁塞控制算法是可插拔的，由于其實(shí)現(xiàn)在用戶態(tài)，服務(wù)可以根據(jù)不同的業(yè)務(wù)，甚至不同的連接靈活選擇使用不同的擁塞控制算法（Reno、New Reno、Cubic、BBR等算法都有自己適合的場(chǎng)景）。
特點(diǎn)四：兩級(jí)流量控制
QUIC是雙級(jí)流控，不僅有連接這一個(gè)級(jí)別的流控，還有流這個(gè)級(jí)別的流控。如下圖所示，每個(gè)流都有自己的可用窗口，可用窗口的大小取決于最大窗口數(shù)減去發(fā)送出去的最大偏移數(shù)，跟中間已經(jīng)發(fā)送出去的數(shù)據(jù)包，是否按順序收到了對(duì)端的ACK 無(wú)關(guān)。
特點(diǎn)五：協(xié)議競(jìng)速
業(yè)內(nèi)統(tǒng)計(jì)數(shù)據(jù)全球有7%地區(qū)的運(yùn)營(yíng)商對(duì)UDP有限速或者禁閉，除了運(yùn)營(yíng)商還有很多企業(yè)、公共場(chǎng)合也會(huì)限制UDP流量甚至禁用UDP。這對(duì)使用UDP來(lái)承載QUIC協(xié)議的場(chǎng)景會(huì)帶來(lái)致命的傷害。
對(duì)此，我們可以采用多路競(jìng)速的方式使用TCP和QUIC同時(shí)建連。除了在建連進(jìn)行競(jìng)速以外，還可以對(duì)網(wǎng)絡(luò)QUIC和TCP的傳輸延時(shí)進(jìn)行實(shí)時(shí)監(jiān)控和對(duì)比，如果有鏈路對(duì)UDP進(jìn)行了限速，可以動(dòng)態(tài)從QUIC切換到TCP。
HTTP/3適用場(chǎng)景？
理論上，HTTP/3在任何場(chǎng)景都適用，但是在有些場(chǎng)景下優(yōu)化效果并不明顯，比如：連接復(fù)用率非常高、需要下載或上傳的文件特別大、網(wǎng)絡(luò)特別好等。
然而，現(xiàn)實(shí)生活中，適用HTTP/3的場(chǎng)景還是占大多數(shù)的，尤其是在流媒體、語(yǔ)音助手、游戲等場(chǎng)景。
四、結(jié)語(yǔ)
QUIC協(xié)議的出現(xiàn)，為HTTP/3奠定了基礎(chǔ)。這是近些年在web協(xié)議上最大的變革，也是最優(yōu)秀的一次實(shí)踐。面對(duì)新的協(xié)議，我們總是有著各種各樣的擔(dān)憂，誠(chéng)然，QUIC協(xié)議在穩(wěn)定性上在成熟度上，的確還不如TCP協(xié)議，但是經(jīng)過(guò)近幾年的發(fā)展，成熟度已經(jīng)相當(dāng)不錯(cuò)了，Nginx近期也發(fā)布了1.25.0版本，支持了QUIC協(xié)議。面對(duì)這樣優(yōu)秀的協(xié)議，我們希望更多的公司、更多的業(yè)務(wù)參與進(jìn)來(lái)使用QUIC，推動(dòng)QUIC更好發(fā)展，推動(dòng)用戶上網(wǎng)速度更快！
Q&A
Q1：怎么保證QUIC的安全使用？
A1：在協(xié)議層面，已經(jīng)盡可能地用各種手段保證安全了，比如：retry機(jī)制、地址校驗(yàn)機(jī)制、抗放大上限機(jī)制等等。但是仍然存在一定的安全問(wèn)題，比如0-RTT攻擊，主機(jī)安全等。另外，在安全檢測(cè)能力上也有一定的缺乏。如果想要保證QUIC安全的使用，我們還需要做好以下準(zhǔn)備：
在部署QUIC之前，建議進(jìn)行安全評(píng)估和測(cè)試，以確保安全性和合規(guī)性的要求得到滿足。
Q2：網(wǎng)絡(luò)防火墻無(wú)法解密QUIC流量，潛在惡意流量怎么檢測(cè)呢？
A2：網(wǎng)絡(luò)防火墻無(wú)法解密QUIC流量，潛在惡意流量可能會(huì)繞過(guò)防護(hù)墻進(jìn)行攻擊，因此確實(shí)需要一種機(jī)制來(lái)檢測(cè)這些流量。下面是一些可能的解決方案：
需要注意的是，以上解決方案可能會(huì)帶來(lái)一定的額外開銷和性能壓力，因此需要合理評(píng)估使用這些方案的可行性。同時(shí)，推薦綜合使用多種安全技術(shù)，以提高安全防范能力。
Q3: 直接應(yīng)用QUIC協(xié)議棧，代碼體積過(guò)大，會(huì)否裁剪代碼？具體如何選擇被裁剪的代碼？
A3：QUIC協(xié)議棧，代碼體積過(guò)大，可以考慮僅保留與QUIC能力相關(guān)的功能，把沒(méi)有必要的比如 log系統(tǒng)、無(wú)用的算法可以不編譯進(jìn)去。同時(shí)，選擇一個(gè)輕量級(jí)庫(kù)也是一個(gè)明智的做法；還有通過(guò)優(yōu)化編譯參數(shù)也是一個(gè)不錯(cuò)的思路。另外BoringSSL也是一個(gè)不小的庫(kù)，也可以進(jìn)行按需裁剪，但需要謹(jǐn)慎謹(jǐn)慎再謹(jǐn)慎。
在優(yōu)化和裁剪代碼時(shí)，可以進(jìn)行代碼分析和評(píng)估，找出影響代碼體積和性能的主要因素，選擇性地進(jìn)行優(yōu)化和裁剪，以在保證功能完整性的前提下，減小代碼體積，提高應(yīng)用性能，同時(shí)需要注意避免影響應(yīng)用體驗(yàn)和安全性。
Q4：除了HTTP/3，QUIC還能用于其他協(xié)議嗎？
A4：可以的，理論上來(lái)說(shuō)，quic是一個(gè)傳輸層協(xié)議，除了HTTP協(xié)議，也可以應(yīng)用在其他應(yīng)用層協(xié)議上。在應(yīng)用于其他協(xié)議上時(shí)，需要注意一些原則，如在選擇QUIC協(xié)議時(shí)需根據(jù)實(shí)際場(chǎng)景和需求，進(jìn)行適當(dāng)?shù)呐渲谜{(diào)整和優(yōu)化；在使用過(guò)程中需要加強(qiáng)網(wǎng)絡(luò)安全防護(hù)，保障數(shù)據(jù)傳輸?shù)陌踩?；在網(wǎng)絡(luò)設(shè)備及應(yīng)用程序的開發(fā)和調(diào)試過(guò)程中需做相關(guān)的技術(shù)支持和調(diào)試工作。
Q5：網(wǎng)站整體遷移到HTTP/3新框架的成本怎樣預(yù)估？客戶端和服務(wù)端的網(wǎng)絡(luò)協(xié)議棧如何選型？
A5：成本，我們可以分為服務(wù)器成本以及研發(fā)成本。
開源協(xié)議棧的選擇有很多，比較知名的有：Google的quiche，cloudflare的quiche，lsquic，亞馬遜的s2n-quic。最終的選型應(yīng)該根據(jù)實(shí)際需求、系統(tǒng)環(huán)境和預(yù)算等因素綜合考慮，權(quán)衡不同協(xié)議棧的優(yōu)缺點(diǎn)，選擇適合自己業(yè)務(wù)和技術(shù)棧的網(wǎng)絡(luò)協(xié)議棧。
Q6：Rtt跟丟包會(huì)有效的原因？
A6：同學(xué)是想問(wèn)：為什么在RTT比較長(zhǎng)、有一定丟包率的弱網(wǎng)場(chǎng)景，QUIC優(yōu)化效果更明顯？
RTT越長(zhǎng)，建連所需要的時(shí)間就越長(zhǎng)，用戶的請(qǐng)求耗時(shí)中，網(wǎng)絡(luò)耗時(shí)占比就會(huì)越大。那么QUIC就是解決網(wǎng)絡(luò)耗時(shí)的，QUIC所發(fā)揮的價(jià)值就會(huì)越大。
丟包就需要重傳，傳統(tǒng)的TCP對(duì)于重傳包有“二義性”，無(wú)法精確地計(jì)算RTT。而QUIC采用單調(diào)遞增的Packet Number方式，解決了重傳包的“二義性”問(wèn)題，RTT計(jì)算準(zhǔn)確。
Q7：QUIC衍生子版本眾多，怎么選擇適合的版本？現(xiàn)有版本使用時(shí)可能會(huì)遇到什么困難？
A7：QUIC 一直保持著高速發(fā)展，分為 gQUIC（Google QUIC）、iQUIC(IETF-QUIC)兩大類，衍生的 QUIC 子版本有幾十個(gè)。
選擇適合的QUIC衍生子版本可以考慮以下因素：
在使用現(xiàn)有版本時(shí)，可能會(huì)遇到以下困難：
Q8：如何理解擁塞控制和流量控制的關(guān)系？
A8：流量控制要解決的問(wèn)題是：接收方控制發(fā)送方的數(shù)據(jù)發(fā)送的速度，就是我的接收能力就那么大點(diǎn)，你別發(fā)太快了，你發(fā)太快了我承受不住，會(huì)給你丟掉 你還得重新發(fā)。
擁塞控制要解決的問(wèn)題是：數(shù)據(jù)在網(wǎng)絡(luò)的傳輸過(guò)程中，是否網(wǎng)絡(luò)有擁塞，是否有丟包，是否有亂序等問(wèn)題。如果中間傳輸?shù)臅r(shí)候網(wǎng)絡(luò)特別卡，數(shù)據(jù)包丟在中間了，發(fā)送方就需要重傳，那么怎么判斷是否擁塞了，重傳要怎么重傳法，按照什么算法進(jìn)行發(fā)送數(shù)據(jù)才能盡可能避免數(shù)據(jù)包在中間路徑丟掉，這是擁塞控制的核心。
所以，流量控制解決的是接收方的接收能力問(wèn)題，一般采用滑動(dòng)窗口算法；擁塞控制要解決的是中間傳輸?shù)臅r(shí)候網(wǎng)絡(luò)是否擁堵的問(wèn)題，一般采用慢啟動(dòng)、擁塞避免、擁塞恢復(fù)、快速重傳等算法。
Q9：請(qǐng)問(wèn)從端到端考慮，一般網(wǎng)絡(luò)請(qǐng)求耗時(shí)多少算是正常？
A9：不同的網(wǎng)絡(luò)環(huán)境，不同的請(qǐng)求大小，耗時(shí)差異非常大，要看具體情況。不能一概而論。
但是有一個(gè)標(biāo)準(zhǔn)：站在用戶的角度上看問(wèn)題，是否影響用戶使用體驗(yàn)，如果明顯體驗(yàn)不好，那么就是耗時(shí)過(guò)長(zhǎng)了。
Q10：可以用HTTP3加載網(wǎng)頁(yè)靜態(tài)資源，然后用HTTP1.1調(diào)用接口嗎？
A10：可以，HTTP/3可以用來(lái)加載網(wǎng)頁(yè)的靜態(tài)資源，而HTTP/1.1可以用來(lái)調(diào)用接口。HTTP/3是基于QUIC協(xié)議的，它能夠提供更快的網(wǎng)絡(luò)連接和更好的性能?？梢酝ㄟ^(guò)HTTP/3來(lái)加載網(wǎng)頁(yè)的靜態(tài)資源，包括HTML、CSS、JavaScript、圖片等。使用HTTP/3能夠減少連接建立的延遲以及減少對(duì)服務(wù)器資源的消耗，從而加快網(wǎng)頁(yè)的加載速度。
而對(duì)于接口調(diào)用，HTTP/1.1在許多場(chǎng)景下仍然可以使用。HTTP/1.1是目前最廣泛支持的HTTP協(xié)議，它具有廣泛的兼容性和廣泛的支持，許多服務(wù)器和客戶端都可以對(duì)其進(jìn)行支持。對(duì)于簡(jiǎn)單的接口調(diào)用，HTTP/1.1仍然能夠提供足夠的性能。
通過(guò)使用HTTP/3加載網(wǎng)頁(yè)的靜態(tài)資源，同時(shí)使用HTTP/1.1進(jìn)行接口調(diào)用，可以充分發(fā)揮兩個(gè)協(xié)議的優(yōu)勢(shì)，提供更好的用戶體驗(yàn)和性能。
Q11：文件上傳場(chǎng)景適合QUIC協(xié)議么？
A11： 可以用在文件上傳場(chǎng)景，具體能帶來(lái)多大的提升，還需要具體業(yè)務(wù)具體分析。做項(xiàng)目要考慮投入產(chǎn)出比。
Q12：QUIC有哪些缺點(diǎn)？
A12：雖然QUIC協(xié)議有許多優(yōu)勢(shì)，但也存在一些缺點(diǎn)：
針對(duì)這些缺點(diǎn)，建議在選擇QUIC協(xié)議作為傳輸層協(xié)議前，評(píng)估好自己對(duì)于網(wǎng)絡(luò)傳輸?shù)男枨蠛拖到y(tǒng)環(huán)境，選擇合適的協(xié)議；同時(shí)，在使用QUIC協(xié)議時(shí)，注意安全防護(hù)，加強(qiáng)密碼管理和認(rèn)證授權(quán)，避免可能的網(wǎng)絡(luò)攻擊和數(shù)據(jù)泄漏風(fēng)險(xiǎn)。
獲取本期PPT，請(qǐng)?zhí)砑尤好兀篸bayuqing
回看本期直播：
聯(lián)系客服
