我們?cè)诳匆恍╆P(guān)于計(jì)算機(jī)網(wǎng)絡(luò)的數(shù)據(jù)或文章的時(shí)候，最常聽到的就是 TCP、UDP、HTTP 這些，除此之外，我們或多或少可能聽過 QUIC這個(gè)東西，一般跟這個(gè)詞一起出現(xiàn)的是 HTTP3，也就是HTTP協(xié)議的3.0版本，未來2.x 版本的升級(jí)方案。

QUIC 由 Google 主導(dǎo)設(shè)計(jì)研發(fā)。我們都知道 HTTP 協(xié)議是應(yīng)用層協(xié)議，在傳輸層它使用的是 TCP 作為傳輸協(xié)議，當(dāng)然這僅僅是對(duì)于 HTTP/1 和 HTTP/2 而言的。而 QUIC 的設(shè)計(jì)的對(duì)標(biāo)協(xié)議就是 TCP ，也就是說將來只要能使用 TCP 的地方，都可以用 QUIC 代替。

Google 最開始的目的就是為了替換 HTTP 協(xié)議使用的 TCP 協(xié)議，所以最開始的名字叫做 HTTP over QUIC，后來由 IETF 接管后更名為 HTTP/3。所以，現(xiàn)在說起 HTTP/3 ,實(shí)際指的就是利用 QUIC 協(xié)議的版本。

TCP 不好嗎，為什么還要 QUIC

TCP 協(xié)議作為傳輸層最負(fù)盛名的協(xié)議，可謂是久經(jīng)考驗(yàn)。只要一說到 TCP ，我們都能說出來它是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。

TCP 通過三次握手的方式建立連接，并且通過序號(hào)、ACK確認(rèn)、丟包重傳以及流量控制、擁塞控制等各種繁瑣又細(xì)致的方式來保證它的可靠性。

看上去很完美了，那為什么還要重新搞個(gè) QUIC 出來呢，而且還被作為下一代 HTTP 的實(shí)現(xiàn)協(xié)議。確實(shí)不存在完美的協(xié)議，TCP 協(xié)議在整個(gè)發(fā)展過程中經(jīng)過了多次改進(jìn)，但是由于牽扯到互聯(lián)網(wǎng)世界浩如煙海的各種設(shè)備，每次更新、修改都要考慮兼容問題，歷史包袱太重，以至于尾大不掉。

所以為了彌補(bǔ) TCP 的不足，在 TCP 上直接修改不太可能，那最好的方案就是重新開發(fā)一套協(xié)議。這種協(xié)議要吸收 TCP 的精華，又要解決 TCP 的不足，這就是 QUIC 出現(xiàn)的意義。

TCP 的問題-隊(duì)頭阻塞

時(shí)至今日，互聯(lián)網(wǎng)上大多數(shù)網(wǎng)站都已經(jīng)支持 HTTP/2 協(xié)議了，你可以在瀏覽器開發(fā)者工具中看一下網(wǎng)絡(luò)請(qǐng)求，其中的 Protocol 表示網(wǎng)絡(luò)請(qǐng)求采用的協(xié)議。

HTTP/2的一個(gè)主要特性是使用多路復(fù)用（multiplexing），因而它可以通過同一個(gè)TCP連接發(fā)送多個(gè)邏輯數(shù)據(jù)流。復(fù)用使得很多事情變得更快更好，它帶來更好的擁塞控制、更充分的帶寬利用、更長久的TCP連接————這些都比以前更好了，鏈路能更容易實(shí)現(xiàn)全速傳輸。標(biāo)頭壓縮技術(shù)也減少了帶寬的用量。

采用HTTP/2后，瀏覽器對(duì)每個(gè)主機(jī)一般只需要 一個(gè) TCP連接，而不是以前常見的六個(gè)連接。

如下圖所示，HTTP/2 在使用 TCP 傳輸數(shù)據(jù)的時(shí)候，可以在一個(gè)連接上傳輸兩個(gè)不同的流，紅色是一個(gè)流，綠色是另外一個(gè)流，但是仍然是按順序傳輸?shù)?，假設(shè)其中有一個(gè)包丟了，那整個(gè)鏈路上這個(gè)包后面的部分都要等待。

這就造成了阻塞，雖然一個(gè)連接可傳多個(gè)流，但仍然存在單點(diǎn)問題。這個(gè)問題就叫做隊(duì)頭阻塞。

QUIC 如何解決的

TCP 這個(gè)問題是無解的，QUIC 就是為了徹底解決這個(gè)問題。

如下圖所示，兩臺(tái)設(shè)備之間建立的是一個(gè) QUIC 連接，但是可以同時(shí)傳輸多個(gè)相互隔離的數(shù)據(jù)流。例如黃色是一個(gè)數(shù)據(jù)流，藍(lán)色是一個(gè)數(shù)據(jù)流，它倆互不影響，即便其中一個(gè)數(shù)據(jù)流有丟包的問題，也完全不會(huì)影響到其他的數(shù)據(jù)流傳輸。

這樣一來，也就解決了 TCP 的隊(duì)頭阻塞問題。

為什么要基于 UDP 協(xié)議

QUIC 雖然是和TCP 平行的傳輸協(xié)議，工作在傳輸層，但是其并不是完全采用全新設(shè)計(jì)的，而是對(duì) UDP 協(xié)議進(jìn)行了包裝。

UDP 是無連接的，相對(duì)于 TCP 來說，無連接就是不可靠的，沒有三次握手，沒有丟包重傳，沒有各種各樣的復(fù)雜算法，但這帶來了一個(gè)好處，那就是速度快。

而 QUIC 為了達(dá)到 TCP 的可靠性，所以在 UDP 的基礎(chǔ)上增加了序號(hào)機(jī)制、丟包重傳等等 UDP 沒有而 TCP 具有的特性。

既然這么多功能都做了，還差一個(gè) UDP 嗎，完全全新設(shè)計(jì)一個(gè)不好嗎，那樣更徹底呀。

之所以不重新設(shè)計(jì)應(yīng)該有兩個(gè)原因：

1. UDP 本身就是非常經(jīng)典的傳輸層協(xié)議，對(duì)于快速傳輸來說，其功能完全沒有問題。

2. 還有一個(gè)重要的原因，前面也說到了，互聯(lián)網(wǎng)上的設(shè)備太多，而很多設(shè)備只認(rèn) TCP 和 UDP 協(xié)議，如果設(shè)計(jì)一個(gè)完全全新的協(xié)議，很難實(shí)施。

QUIC 協(xié)議

不需要三次握手

QUIC 建立連接的速度是非?？斓?，不需要 TCP 那樣的三次握手，稱之為 0-RTT（零往返時(shí)間）及 1-RTT（1次往返時(shí)間）。

QUIC 使用了TLS 1.3傳輸層安全協(xié)議，所以 QUIC 傳輸?shù)臄?shù)據(jù)都是加密的，也就是說 HTTP/3 直接就是 HTTPS 的，不存在 HTTP 的非加密版本。

正是因?yàn)檫@樣，所以，QUIC 建立連接的過程就是 TLS 建立連接的過程，如下圖這樣，首次建立連接只需要 1-RTT。

而在首次連接建立之后，QUIC 客戶端就緩存了服務(wù)端發(fā)來的 Server Hello，也就是加密中所需要的一些內(nèi)容。在之后重新建立連接時(shí)，只需要根據(jù)緩存內(nèi)容直接加密數(shù)據(jù)，所以可以在客戶端向服務(wù)端發(fā)送連接請(qǐng)求的同時(shí)將數(shù)據(jù)也一并帶過去，這就是 0-RTT 。

連接不依靠 IP

QUIC 在建立連接后，會(huì)為這個(gè)連接分配一個(gè)連接 ID，用這個(gè) ID 可以識(shí)別出具體的連接。

假設(shè)我正在家里用 WIFI 發(fā)送請(qǐng)求，但是突然有事兒出去了，馬上切換到了蜂窩網(wǎng)絡(luò)，那對(duì)于 QUIC 來說就沒有什么影響。因?yàn)檫@個(gè)連接沒有變，所以仍然可以繼續(xù)執(zhí)行請(qǐng)求，數(shù)據(jù)該怎么傳還怎么傳。

而如果使用的是 TCP 協(xié)議的話，那只能重新建立連接，重傳之前的數(shù)據(jù)，因?yàn)?TCP 的尋址依靠的是 IP 和 端口。

未來展望

隨著 QUIC 協(xié)議的不斷完善和推廣，其應(yīng)用場(chǎng)景將更加廣泛，對(duì)互聯(lián)網(wǎng)傳輸技術(shù)產(chǎn)生深遠(yuǎn)的影響。未來的互聯(lián)網(wǎng)，將是 QUIC 和 HTTP3 主導(dǎo)的時(shí)代。

要知道，HTTP/1 到 HTTP/2，中間用了整整 16 年才完成，這還只是針對(duì)協(xié)議做改進(jìn)和優(yōu)化，而 QUIC 可謂是顛覆性的修改，可想而知，其過程只會(huì)更加漫長。

作者：古時(shí)的風(fēng)箏
鏈接：https://juejin.cn/post/7384266820466180148
來源：稀土掘金
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請(qǐng)注明出處。