QUIC如何解決TCP性能瓶頸

1.1 TCP 為何會有隊頭阻塞問題

HTTP/2相比HTTP/1.1 設(shè)計出的一些優(yōu)秀的改進方案，大幅提高了HTTP 的網(wǎng)絡(luò)利用效率。HTTP/2 在應(yīng)用協(xié)議層通過多路復(fù)用同一個TCP連接解決了隊頭阻塞問題，但這是以下層協(xié)議比如TCP 協(xié)議不出現(xiàn)任何數(shù)據(jù)包阻塞為前提的。TCP 在實際運行中，特別是遇到網(wǎng)絡(luò)環(huán)境不好時，數(shù)據(jù)包超時確認(rèn)或丟失是常有的事，假如某個數(shù)據(jù)包丟失需要重傳時會發(fā)生什么呢？

TCP 采用正面確認(rèn)和超時重傳機制來保證數(shù)據(jù)包的可靠交付。比如主機A 向 主機B 發(fā)送數(shù)據(jù)包，主機B 收到該數(shù)據(jù)包后會向主機A 返回確認(rèn)應(yīng)答報文，表示自己確實收到了該數(shù)據(jù)包，主機A 收到確認(rèn)應(yīng)答報文后才確定上一個數(shù)據(jù)包已經(jīng)發(fā)送成功，開始發(fā)送下一個數(shù)據(jù)包。

如果超過一定時間（根據(jù)每次測量的往返時間RTT估算出的動態(tài)閾值）未收到確認(rèn)應(yīng)答，則主機A 判斷上一個數(shù)據(jù)包丟失了，重新發(fā)送上一個數(shù)據(jù)包，這就相當(dāng)于阻塞了下一個數(shù)據(jù)包的發(fā)送。

逐個發(fā)送數(shù)據(jù)包，等待確認(rèn)應(yīng)答到來后再發(fā)送下一個數(shù)據(jù)包，效率太低了，TCP 采用滑動窗口機制來提高數(shù)據(jù)傳輸效率。窗口大小就是指無需等待確認(rèn)應(yīng)答而可以繼續(xù)發(fā)送數(shù)據(jù)的最大值，這個機制實現(xiàn)了使用大量的緩沖區(qū)，通過對多個數(shù)據(jù)包同時進行確認(rèn)應(yīng)答的功能。

當(dāng)可發(fā)送數(shù)據(jù)的窗口消耗殆盡時，就需要等待收到連續(xù)的確認(rèn)應(yīng)答后，當(dāng)前窗口才會向前滑動，為發(fā)送下一批數(shù)據(jù)包騰出窗口。假設(shè)某個數(shù)據(jù)包超時未收到確認(rèn)應(yīng)答，當(dāng)前窗口就會阻塞在原地，重新發(fā)送該數(shù)據(jù)包，在收到該重發(fā)數(shù)據(jù)包的確認(rèn)應(yīng)答前，就不會有新增的可發(fā)送數(shù)據(jù)包了。也就是說，因為某個數(shù)據(jù)包丟失，當(dāng)前窗口阻塞在原地，同樣阻塞了后續(xù)所有數(shù)據(jù)包的發(fā)送。

TCP 因為超時確認(rèn)或丟包引起的滑動窗口阻塞問題，是不是有點像HTTP/1.1 管道化機制中出現(xiàn)的隊頭阻塞問題？HTTP/2 在應(yīng)用協(xié)議層通過多路復(fù)用解決了隊頭阻塞問題，但TCP 在傳輸層依然存在隊頭阻塞問題，這是TCP 協(xié)議的一個主要性能瓶頸。該怎么解決TCP 的隊頭阻塞問題呢？

1.2 QUIC 如何解決隊頭阻塞問題？

TCP 隊頭阻塞的主要原因是數(shù)據(jù)包超時確認(rèn)或丟失阻塞了當(dāng)前窗口向右滑動，我們最容易想到的解決隊頭阻塞的方案是不讓超時確認(rèn)或丟失的數(shù)據(jù)包將當(dāng)前窗口阻塞在原地。QUIC (Quick UDP Internet Connections)也正是采用上述方案來解決TCP 隊頭阻塞問題的。

TCP 為了保證可靠性，使用了基于字節(jié)序號的 Sequence Number 及 Ack 來確認(rèn)消息的有序到達(dá)。QUIC 同樣是一個可靠的協(xié)議，它使用 Packet Number 代替了 TCP 的 Sequence Number，并且每個 Packet Number 都嚴(yán)格遞增，也就是說就算 Packet N 丟失了，重傳的 Packet N 的 Packet Number 已經(jīng)不是 N，而是一個比 N 大的值，比如Packet N+M。

QUIC 使用的Packet Number 單調(diào)遞增的設(shè)計，可以讓數(shù)據(jù)包不再像TCP 那樣必須有序確認(rèn)，QUIC 支持亂序確認(rèn)，當(dāng)數(shù)據(jù)包Packet N 丟失后，只要有新的已接收數(shù)據(jù)包確認(rèn)，當(dāng)前窗口就會繼續(xù)向右滑動。 待發(fā)送端獲知數(shù)據(jù)包Packet N 丟失后，會將需要重傳的數(shù)據(jù)包放到待發(fā)送隊列，重新編號比如數(shù)據(jù)包Packet N+M 后重新發(fā)送給接收端，對重傳數(shù)據(jù)包的處理跟發(fā)送新的數(shù)據(jù)包類似，這樣就不會因為丟包重傳將當(dāng)前窗口阻塞在原地，從而解決了隊頭阻塞問題。那么，既然重傳數(shù)據(jù)包的Packet N+M 與丟失數(shù)據(jù)包的Packet N 編號并不一致，我們怎么確定這兩個數(shù)據(jù)包的內(nèi)容一樣呢？

還記得前篇博文：HTTP/2 是如何解決HTTP/1.1 性能瓶頸的？使用Stream ID 來標(biāo)識當(dāng)前數(shù)據(jù)流屬于哪個資源請求，這同時也是數(shù)據(jù)包多路復(fù)用傳輸?shù)浇邮斩撕竽苷＝M裝的依據(jù)。重傳的數(shù)據(jù)包Packet N+M 和丟失的數(shù)據(jù)包Packet N 單靠Stream ID 的比對一致仍然不能判斷兩個數(shù)據(jù)包內(nèi)容一致，還需要再新增一個字段Stream Offset，標(biāo)識當(dāng)前數(shù)據(jù)包在當(dāng)前Stream ID 中的字節(jié)偏移量。

有了Stream Offset 字段信息，屬于同一個Stream ID 的數(shù)據(jù)包也可以亂序傳輸了（HTTP/2 中僅靠Stream ID 標(biāo)識，要求同屬于一個Stream ID 的數(shù)據(jù)幀必須有序傳輸），通過兩個數(shù)據(jù)包的Stream ID 與 Stream Offset 都一致，就說明這兩個數(shù)據(jù)包的內(nèi)容一致。

上圖中數(shù)據(jù)包Packet N 丟失了，后面重傳該數(shù)據(jù)包的編號為Packet N+2，丟失的數(shù)據(jù)包和重傳的數(shù)據(jù)包Stream ID 與 Offset 都一致，說明這兩個數(shù)據(jù)包的內(nèi)容一致。這些數(shù)據(jù)包傳輸?shù)浇邮斩撕?，接收端能根?jù)Stream ID 與 Offset 字段信息正確組裝成完整的資源。

QUIC 通過單向遞增的Packet Number，配合Stream ID 與 Offset 字段信息，可以支持非連續(xù)確認(rèn)應(yīng)答Ack而不影響數(shù)據(jù)包的正確組裝，擺脫了TCP 必須按順序確認(rèn)應(yīng)答Ack 的限制（也即不能出現(xiàn)非連續(xù)的空位），解決了TCP 因某個數(shù)據(jù)包重傳而阻塞后續(xù)所有待發(fā)送數(shù)據(jù)包的問題（也即隊頭阻塞問題）。

QUIC 可以支持非連續(xù)的數(shù)據(jù)包確認(rèn)應(yīng)答Ack，自然也就要求每個數(shù)據(jù)包的確認(rèn)應(yīng)答Ack 都能返回給發(fā)送端（TCP 中間丟失幾個Ack 對數(shù)據(jù)包的確認(rèn)應(yīng)答影響不大），發(fā)送端收到該數(shù)據(jù)包的確認(rèn)應(yīng)答后才會釋放該數(shù)據(jù)包所占用的緩存資源，已發(fā)送但未收到確認(rèn)應(yīng)答的數(shù)據(jù)包會保存在緩存鏈表中等待可能的重傳。

QUIC 對確認(rèn)應(yīng)答Ack 丟失的容忍度比較低，自然對Ack 的傳輸能力進行了增強，Quic Ack Frame 可以同時提供 256 個 Ack Block，在丟包率比較高的網(wǎng)絡(luò)下，更多的 Ack Block 可以提高Ack 送達(dá)的成功率，減少重傳量。

1.3 QUIC 沒有隊頭阻塞的多路復(fù)用

QUIC 解決了TCP 的隊頭阻塞問題，同時繼承了HTTP/2 的多路復(fù)用優(yōu)點，因為Stream Offset 字段的引入，QUIC 中同一Stream ID 的數(shù)據(jù)幀也支持亂序傳輸，不再像HTTP/2 要求的同一Stream ID 的數(shù)據(jù)幀必須有序傳輸那么嚴(yán)格。

從上面QUIC 的數(shù)據(jù)包結(jié)構(gòu)中可以看出，同一個Connection ID 可以同時傳輸多個Stream ID，由于QUIC 支持非連續(xù)的Packet Number 確認(rèn)，某個Packet N 超時確認(rèn)或丟失，不會影響其它未包含在該數(shù)據(jù)包中的Stream Frame 的正常傳輸。

同一個Packet Number 可承載多個Stream Frame，若該數(shù)據(jù)包丟失，則其承載的Stream Frame 都需要重新傳輸。因為同一Stream ID 的數(shù)據(jù)幀亂序傳輸后也能正確組裝，這些需要重傳的Stream Frame 并不會影響其它待發(fā)送Stream Frame 的正常傳輸。

值得一提的是，TLS 協(xié)議加解密前需要對數(shù)據(jù)進行完整性校驗，HTTP/2 中如果TCP 出現(xiàn)丟包，TLS 也會因接收到的數(shù)據(jù)不完整而無法對其進行處理，也即HTTP/2 中的TLS 協(xié)議層也存在隊頭阻塞問題，該問題如何解決呢？
既然TLS 協(xié)議是因為接收數(shù)據(jù)不完整引起的阻塞，我們只需要讓TLS 加密認(rèn)證過程基于一個獨立的Packet，不對多個Packet 同時進行加密認(rèn)證，就能解決TLS 協(xié)議層出現(xiàn)的隊頭阻塞問題，某一個Packet 丟失只會影響封裝該Packet 的Record，不會讓其它Record 陷入阻塞等待的情況。

2.1 TCP連接的本質(zhì)是什么？

你可能熟悉TCP 建立連接的三次握手和四次揮手過程，但你知道TCP 建立的連接本質(zhì)上是什么嗎？這里的連接跟我們熟悉的物理介質(zhì)連接（比如電路連接）不同，主要是用來說明如何在物理介質(zhì)上傳輸數(shù)據(jù)的。

為了更直觀了解網(wǎng)絡(luò)連接概念，我們拿面向連接的TCP 與無連接的UDP 做對比，網(wǎng)絡(luò)傳輸層的兩個主流協(xié)議，他們的主要區(qū)別是什么呢？UDP 每個分組的處理都獨立于所有其他分組，TCP 每個分組的傳輸都有確認(rèn)應(yīng)答過程和可能的丟包重傳過程，需要為每個分組數(shù)據(jù)進行狀態(tài)信息記錄和管理（比如未發(fā)送、已發(fā)送、未確認(rèn)、已確認(rèn)等狀態(tài)）。

TCP 建立連接的三次握手過程都做了哪些工作呢？首先確認(rèn)雙方是否能正常收發(fā)數(shù)據(jù)，通信雙方交換待發(fā)送數(shù)據(jù)的初始序列編號并作為有序確認(rèn)應(yīng)答的基點，通信雙方根據(jù)預(yù)設(shè)的狀態(tài)轉(zhuǎn)換圖完成各自的狀態(tài)遷移過程，通信雙方為分組數(shù)據(jù)的可靠傳輸和狀態(tài)信息的記錄管理分配控制塊緩存資源等。

下面給出TCP 連接建立、數(shù)據(jù)傳輸、連接釋放三個階段的報文交互過程和狀態(tài)遷移圖示（詳見博文：TCP協(xié)議與Transmission Control Protocol）：

從上圖可以看出，TCP 連接主要是雙方記錄并同步維護的狀態(tài)組成的。一般來說，建立連接是為了維護前后分組數(shù)據(jù)的承繼關(guān)系，維護前后承繼關(guān)系最常用的方法就是對其進行狀態(tài)記錄和管理。

TCP 的狀態(tài)管理可以分為連接狀態(tài)管理和分組數(shù)據(jù)狀態(tài)管理兩種，連接狀態(tài)管理用于雙方同步數(shù)據(jù)發(fā)送與接收狀態(tài)，分組數(shù)據(jù)狀態(tài)管理用于保證數(shù)據(jù)的可靠傳輸。涉及到狀態(tài)管理一般都有狀態(tài)轉(zhuǎn)換圖，TCP 連接管理的狀態(tài)轉(zhuǎn)換圖上面已經(jīng)給出了，HTTP/2 的Stream 實際上也記錄并維護了每個Stream Frame 的狀態(tài)信息，Stream 的狀態(tài)轉(zhuǎn)換圖如下：

2.2 QUIC 如何減少TCP 建立連接的開銷？

TCP 建立連接需要三次握手過程，第三次握手報文發(fā)出后不需要等待應(yīng)答回復(fù)就可以發(fā)送數(shù)據(jù)報文了，所以TCP 建立連接的開銷為 1-RTT。既然TCP 連接主要是由雙方記錄并同步維護的狀態(tài)組成的，我們能否借鑒TLS 快速恢復(fù)簡短握手相比完整握手的優(yōu)化方案呢？

TLS 簡短握手過程是將之前完整握手過程協(xié)商的信息記錄下來，以Session Ticket 的形式傳輸給客戶端，如果想恢復(fù)之前的會話連接，可以將Session Ticket 發(fā)送給服務(wù)器，就能通過簡短的握手過程重建或者恢復(fù)之前的連接，通過復(fù)用之前的握手信息可以節(jié)省 1-RTT 的連接建立開銷。

TCP 也提供了快速建立連接的方案 TFO (TCP Fast Open)，原理跟TLS 類似，也是將首次建立連接的狀態(tài)信息記錄下來，以Cookie 的形式傳輸給客戶端，如果想復(fù)用之前的連接，可以將Cookie 發(fā)送給服務(wù)器，如果服務(wù)器通過驗證就能快速恢復(fù)之前的連接，TFO 技術(shù)可以通過復(fù)用之前的連接將連接建立開銷縮短為 0-RTT。

因為TCP 協(xié)議內(nèi)置于操作系統(tǒng)中，操作系統(tǒng)的升級普及過程較慢，因此TFO 技術(shù)至今仍未普及（TFO 在2014年發(fā)布于RFC 7413）。

從上圖可知，TCP 首次建立連接的開銷為 1-RTT，快速復(fù)用/打開連接的開銷為 0-RTT，這與TLS 1.3 協(xié)議首次完整握手與快速恢復(fù)簡短握手的開銷一致。

客戶端發(fā)送的第一個SYN 握手包是可以攜帶數(shù)據(jù)的，但為了防止TCP 泛洪攻擊，TCP 的實現(xiàn)者不允許將SYN 攜帶的數(shù)據(jù)包上傳給應(yīng)用層。HTTP 協(xié)議中TCP 與TLS 常常配合使用，這里TCP 的第一個SYN 握手包可以攜帶TLS 1.3 的握手包，這就可以將TCP + TLS 總的握手開銷進一步降低。

首次建立連接時，TCP 和TLS 1.3 都只需要 1-RTT 就可以完成握手過程，由于TCP 第一個SYN 握手包可以攜帶TLS 的握手包，因此TCP + TLS 1.3 總的首次建立連接開銷為 1-RTT。當(dāng)要快速恢復(fù)之前的連接時，TFO 和TLS 1.3 都只需要 0-RTT 就可以完成握手過程，因此TCP + TLS 1.3 總的連接恢復(fù)開銷為 0-RTT。

QUIC可以理解為”TCP + TLS 1.3“（QUIC 是基于UDP的，可能使用的是DTLS 1.3），QUIC 自然也實現(xiàn)了首次建立連接的開銷為 1-RTT，快速恢復(fù)先前連接的開銷為 0-RTT 的效率。QUIC 作為HTTP/2 的改進版，建立連接的開銷也有明顯降低，下面給出HTTP/2 和QUIC 首次連接和會話恢復(fù)過程中，HTTP 請求首個資源的RTT 開銷對比：

從上表可以看出，QUIC 首次建立連接的開銷比"HTTP/2 + TLS 1.3"減少了 1-RTT，會話/連接恢復(fù)的開銷降低到了 0-RTT（除去HTTP 自身請求資源的開銷），顯著降低了網(wǎng)頁請求延遲。

值得一提的是，TCP 因為報文首部是透明傳輸?shù)模诎踩雷o方便比較脆弱，容易受到網(wǎng)絡(luò)攻擊。QUIC 因為有TLS 對數(shù)據(jù)包首部進行加密和驗證，增加了安全防護強度，更不容易受到網(wǎng)絡(luò)攻擊。

2.3 QUIC 如何實現(xiàn)連接的無感遷移？

每個網(wǎng)絡(luò)連接都應(yīng)該有一個唯一的標(biāo)識，用來辨識并區(qū)分特定的連接。TCP 連接使用 這四個信息共同標(biāo)識，在早期PC 時代，這四個元素信息可以唯一標(biāo)識通信雙方的主機及端口，報文中也不需要一個專門的字段來標(biāo)識連接，減少了傳輸開銷。

到了移動互聯(lián)網(wǎng)時代，客戶端（比如手機）的位置可能一直在變，接入不同的基站可能就會被分配不同的Source IP 和Source Port。即便在家里，客戶端可能也需要在LTE 和WIFI 之間切換，這兩個網(wǎng)絡(luò)分配給客戶端的Source IP 和Source Port 可能也是不同的。

TCP 用來標(biāo)識連接的四個信息中的任何一個改變，都相當(dāng)于TCP 連接標(biāo)識改變了，也就變成了不同的連接，TCP 需要先斷開舊的連接再建立新的連接，很顯然連接切換或遷移過程不夠順暢高效。

未來移動設(shè)備越來越多，在通話或者玩游戲等對實時性要求較高的場景中，因為網(wǎng)絡(luò)遷移或切換導(dǎo)致TCP 斷開連接會大大降低網(wǎng)絡(luò)服務(wù)體驗，怎么解決TCP 因為網(wǎng)絡(luò)遷移或切換導(dǎo)致斷線重連的問題呢？

早期移動電話使用Mobile IP 技術(shù)來解決網(wǎng)絡(luò)遷移或切換過程引起的斷連問題，Mobile IP 主要是通過新建IP 隧道的方式（也即建立一個新連接來轉(zhuǎn)發(fā)數(shù)據(jù)包）保持原來的連接不斷開，但這種方式增加了數(shù)據(jù)包的傳輸路徑，也就增大了數(shù)據(jù)包的往返時間，降低了數(shù)據(jù)包的傳輸效率。Mobile IP 的工作原理如下（移動主機遷移到外部代理后，為了保持原連接不斷開，新建了一條到歸屬代理的IP 隧道，讓歸屬代理以原主機IP 轉(zhuǎn)發(fā)數(shù)據(jù)包）：

TCP 為保持前向兼容性，沒法重新設(shè)計連接標(biāo)識，但為了解決移動主機連接切換問題還是推出了一套解決方案MPTCP (Multipath TCP，在2013年發(fā)布于RFC 6824) 。

針對移動主機同時支持LTE 和WIFI 等多條連接鏈路的情況，設(shè)計的多路徑TCP 技術(shù)(MPTCP) 允許在一條TCP 鏈路中建立多個子通道，每個子通道都可以按照三次握手的方式建立連接，每個子通道的連接允許IP 不一致，這些子通道都會綁定到MPTCP Session（比如通過LTE 和WIFI 各建立一個子通道），發(fā)送端的數(shù)據(jù)可以選擇其中一條通道進行傳輸。MPTCP 可以讓移動主機在多個連接鏈路間順暢切換，切換過程不斷開連接。

對于移動主機跨基站連接遷移的問題，也可以在原基站與目標(biāo)遷移基站之間各建立一個連接鏈路/子通道，當(dāng)移動主機從一個基站遷移到另一個基站時，只是從一個鏈路子通道切換到另一個鏈路子通道，同樣能讓連接鏈路順暢遷移而不斷開連接。MPTCP 跟TFO 技術(shù)類似，需要操作系統(tǒng)及網(wǎng)絡(luò)協(xié)議棧支持，更新和部署阻力較大，目前并不適用。

QUIC擺脫了TCP 的諸多限制，可以重新設(shè)計連接標(biāo)識，還記得前面給出的QUIC 數(shù)據(jù)包結(jié)構(gòu)嗎？QUIC 數(shù)據(jù)包結(jié)構(gòu)中有一個Connection ID 字段專門標(biāo)識連接，Connection ID是一個64位的通用唯一標(biāo)識UUID (Universally Unique IDentifier)。

借助Connection ID，QUIC 的連接不再綁定IP 與 Port 信息，即便因為網(wǎng)絡(luò)遷移或切換導(dǎo)致Source IP 和Source Port 發(fā)生變化，只要Connection ID 不變就仍是同一個連接，協(xié)議層只需要將控制塊中記錄的Source IP 和Source Port 信息更新即可，不需要像TCP 那樣先斷開連接，這就可以保證連接的順暢遷移或切換，用戶基本不會感知到連接切換過程。

3.1 TCP 擁塞控制機制的瓶頸在哪？

計算機網(wǎng)絡(luò)都處于一個共享環(huán)境中，可能會因為其它主機之間的通信使得網(wǎng)絡(luò)擁堵，如果在通信剛開始時就突然發(fā)送大量數(shù)據(jù)，可能會導(dǎo)致整個網(wǎng)絡(luò)的擁堵阻塞。TCP為了防止該問題的出現(xiàn)，設(shè)計了擁塞控制機制來限制數(shù)據(jù)包的發(fā)送帶寬，實際就是控制發(fā)送窗口的大小。

TCP 發(fā)送數(shù)據(jù)的速率受到兩個因素限制：一個是目前接收窗口的大小，通過接收端的實際接收能力來控制發(fā)送速率的機制稱為流量控制機制；另一個是目前擁塞窗口的大小，通過慢啟動和擁塞避免算法來控制發(fā)送速率的機制稱為擁塞控制機制，TCP 發(fā)送窗口大小被限制為不超過接收窗口和擁塞窗口的較小值。

TCP 通信開始時，會通過慢啟動算法得出的擁塞窗口大小對發(fā)送數(shù)據(jù)速率進行控制，慢啟動階段擁塞窗口大小從1 開始按指數(shù)增大（每收到一次確認(rèn)應(yīng)答擁塞窗口值加1，收到一個窗口大小數(shù)量的確認(rèn)應(yīng)答則擁塞窗口大小翻倍），雖然擁塞窗口增長率較快，但由于初始值較小，增長到慢啟動閾值仍然需要花費不少時間。

為了防止擁塞窗口后期增長過快，當(dāng)擁塞窗口大小超過慢啟動閾值（一般為發(fā)生超時重傳或重復(fù)確認(rèn)應(yīng)答時，擁塞窗口一半的大?。┖螅妥兏鼮榫€性增長（每收到一個窗口大小數(shù)量的確認(rèn)應(yīng)答則擁塞窗口大小增加一個數(shù)據(jù)段），直到發(fā)生超時重傳或重復(fù)確認(rèn)應(yīng)答，擁塞窗口向下調(diào)整，擁塞窗口大小變化過程如下圖示：

從上圖可以看出，TCP 發(fā)生超時重傳時，擁塞窗口直接下調(diào)為 1，并從慢啟動階段開始逐漸增大擁塞窗口，當(dāng)超過慢啟動閾值后進入擁塞避免階段，這個過程對網(wǎng)絡(luò)傳輸效率影響較大。

TCP 發(fā)生重復(fù)確認(rèn)應(yīng)答而觸發(fā)快速重傳時，判斷網(wǎng)絡(luò)擁堵情況更輕些，因此擁塞窗口下調(diào)為慢啟動閾值 + 3個數(shù)據(jù)段的大小，相當(dāng)于直接跨過慢啟動階段進入擁塞避免階段，這個過程對網(wǎng)絡(luò)傳輸效率影響相對較小，這種機制稱為快速恢復(fù)機制。

現(xiàn)在網(wǎng)絡(luò)帶寬相比TCP協(xié)議剛誕生時有了明顯的改善，TCP 的擁塞控制算法也成為影響網(wǎng)絡(luò)傳輸效率的一個瓶頸，如果觸發(fā)超時重傳的次數(shù)比較多，對網(wǎng)絡(luò)傳輸效率的影響相當(dāng)大。

3.2 QUIC 如何降低重傳概率？

TCP 的擁塞控制機制是被超時重傳或者快速重傳觸發(fā)的，想要提高網(wǎng)絡(luò)傳輸效率，容易想到兩個方案：一個是改進擁塞控制算法；另一個是降低重傳次數(shù)。這里先介紹如何降低重傳次數(shù)/概率？

降低TCP 的重傳概率有兩個方向：

降低超時重傳概率：可以通過改善網(wǎng)絡(luò)環(huán)境，提高重發(fā)超時閾值的計算準(zhǔn)確度，也就是提高往返時間RTT 的測量準(zhǔn)確度，來降低超時重傳概率；

降低丟包重傳概率：可以增加傳輸一定的冗余數(shù)據(jù)比如糾錯碼，當(dāng)丟失部分?jǐn)?shù)據(jù)時可以通過糾錯碼恢復(fù)丟失的數(shù)據(jù)，降低丟包重傳的概率。

由于TCP 重傳 segment 的 Sequence Number 和原始的 segment 的 Sequence Number 保持不變，當(dāng)發(fā)送端觸發(fā)重傳數(shù)據(jù)包Sequence N后，接收到了該數(shù)據(jù)包，發(fā)送端無法判斷接收到的數(shù)據(jù)包是來自原始請求的響應(yīng)，還是來自重傳請求的響應(yīng)，這就帶來了TCP 重傳的歧義性，該問題肯定會影響采樣RTT 測量值的準(zhǔn)確性，進而影響重發(fā)超時閾值計算的準(zhǔn)確度，可能會增大數(shù)據(jù)包超時重傳的概率。

QUIC 采用單向遞增的Packet Number來標(biāo)識數(shù)據(jù)包，原始請求的數(shù)據(jù)包與重傳請求的數(shù)據(jù)包編號并不一樣，自然也就不會引起重傳的歧義性，采樣RTT 的測量更準(zhǔn)確。

除此之外，QUIC 計算RTT 時除去了接收端的應(yīng)答延遲時間，更準(zhǔn)確的反映了網(wǎng)絡(luò)往返時間，進一步提高了RTT 測量的準(zhǔn)確性，降低了數(shù)據(jù)包超時重傳的概率。

TCP 傳輸?shù)臄?shù)據(jù)只包括校驗碼，并沒有增加糾錯碼等冗余數(shù)據(jù)，如果出現(xiàn)部分?jǐn)?shù)據(jù)丟失或損壞，只能重新發(fā)送該數(shù)據(jù)包。沒有冗余的數(shù)據(jù)包雖然降低了傳輸開銷，但增加了丟包重傳概率，因為重傳觸發(fā)擁塞控制機制，勢必會降低網(wǎng)絡(luò)傳輸效率。

適當(dāng)增加點冗余數(shù)據(jù)，當(dāng)丟失或損壞的數(shù)據(jù)量較少時，就可以靠冗余數(shù)據(jù)恢復(fù)丟失或損壞的部分，降低丟包重傳概率。只要冗余數(shù)據(jù)比例設(shè)置得當(dāng)，提高的網(wǎng)絡(luò)傳輸效率就可以超過增加的網(wǎng)絡(luò)傳輸開銷，帶來網(wǎng)絡(luò)利用率的正向提升。

QUIC引入了前向冗余糾錯碼（FEC: Fowrard Error Correcting），如果接收端出現(xiàn)少量（不超過FEC的糾錯能力）的丟包或錯包，可以借助冗余糾錯碼恢復(fù)丟失或損壞的數(shù)據(jù)包，這就不需要再重傳該數(shù)據(jù)包了，降低了丟包重傳概率，自然就減少了擁塞控制機制的觸發(fā)次數(shù)，可以維持較高的網(wǎng)絡(luò)利用效率。

糾錯碼的原理比較復(fù)雜，如果想對糾錯碼有更多的了解，可以參考文章：二維碼的秘密，文中簡單介紹了二維碼中的糾錯碼是如何實現(xiàn)信息糾錯和補全的。

3.3 QUIC 如何改進擁塞控制機制？

TCP 的擁塞控制實際上包含了四個算法：慢啟動、擁塞避免、快速重傳、快速恢復(fù)?，F(xiàn)在網(wǎng)絡(luò)環(huán)境改善速度較快，TCP 的慢啟動與擁塞避免過程需要的時間較長，雖然TCP 也在不斷更新改進擁塞控制算法，但由于TCP 內(nèi)置于操作系統(tǒng)，擁塞控制算法的更新速度太過緩慢，跟不上網(wǎng)絡(luò)環(huán)境改善速度，TCP 落后的擁塞控制算法自然會降低網(wǎng)絡(luò)利用效率。

QUIC協(xié)議當(dāng)前默認(rèn)使用了 TCP 的 Cubic 擁塞控制算法，同時也支持 CubicBytes、Reno、RenoBytes、BBR、PCC 等擁塞控制算法，相當(dāng)于將TCP 的擁塞控制算法照搬過來了，QUIC 是如何改進TCP 的擁塞控制算法的呢？

QUIC直接照搬TCP 的擁塞控制算法只是借鑒了TCP 經(jīng)過驗證的成熟方案，由于QUIC 是處于應(yīng)用層的，可以隨瀏覽器更新，QUIC 的擁塞控制算法就可以有較快的迭代速度，在TCP 的擁塞控制算法基礎(chǔ)上快速迭代，可以跟上網(wǎng)絡(luò)環(huán)境改善的速度，盡快提高擁塞恢復(fù)的效率。

QUIC還將擁塞控制算法設(shè)計為可插拔模塊，可以根據(jù)需要為不同的連接配置不同的擁塞控制算法，這樣可以為每個連接根據(jù)其網(wǎng)絡(luò)環(huán)境配置最適合的擁塞控制算法（可以根據(jù)大數(shù)據(jù)和人工智能計算結(jié)果自動精準(zhǔn)配置），盡可能讓每個連接的網(wǎng)絡(luò)帶寬得到最高效的利用。

作者：流云IoT

https://blog.csdn.net/m0_37621078/article/details/106506532

編輯：jq