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

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

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

TCP 不好嗎，為什么還要 QUIC

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

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

關(guān)于 TCP 的更多細(xì)節(jié)，有興趣的可以讀讀我之前寫的《輕解計算機(jī)網(wǎng)絡(luò)》里的 一個網(wǎng)管的自我修養(yǎng)之TCP協(xié)議

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

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

TCP 的問題-隊頭阻塞

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

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

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

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

這就造成了阻塞，雖然一個連接可傳多個流，但仍然存在單點問題。這個問題就叫做隊頭阻塞。

QUIC 如何解決的

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

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

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

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

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

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

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

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

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

1. UDP 本身就是非常經(jīng)典的傳輸層協(xié)議，對于快速傳輸來說，其功能完全沒有問題。
2. 還有一個重要的原因，前面也說到了，互聯(lián)網(wǎng)上的設(shè)備太多，而很多設(shè)備只認(rèn) TCP 和 UDP 協(xié)議，如果設(shè)計一個完全全新的協(xié)議，很難實施。

QUIC 協(xié)議

不需要三次握手

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

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

正是因為這樣，所以，QUIC 建立連接的過程就是 TLS 建立連接的過程，如下圖這樣，首次建立連接只需要 1-RTT。

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

連接不依靠 IP

QUIC 在建立連接后，會為這個連接分配一個連接 ID，用這個 ID 可以識別出具體的連接。

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

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

未來展望

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

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

轉(zhuǎn)載自博客：www.moonkite.cn