下一代通信協(xié)議：QUIC

在 HTTP 協(xié)議已經(jīng)占據(jù)互聯(lián)網(wǎng)大半江山的今天，盡管網(wǎng)速越來(lái)越快，但是人類還是致力于將網(wǎng)絡(luò)傳輸速率提升到極致。

從 HTTP/1.x 到 HTTP/2，TCP 已經(jīng)不能滿足人類貪婪的欲望了，他們開始向常年被忽視的 UDP 進(jìn)軍。

QUIC 是什么？

QUIC（Quick UDP Internet Connections），直譯過(guò)來(lái)就是“快速的 UDP 互聯(lián)網(wǎng)連接”，是 Google 基于 UDP 提出的一種改進(jìn)的通信協(xié)議，作為傳統(tǒng) HTTP over TCP 的替代品，開源于 Chromium 項(xiàng)目中。

為了加快 TCP 的傳輸效率，Google 提出了 BBR 擁塞控制算法，將 TCP 的性能發(fā)揮到了極致。由于 TCP 和 UDP 協(xié)議是系統(tǒng)內(nèi)核實(shí)現(xiàn)的，要提出新的協(xié)議不是不行，只是普及起來(lái)會(huì)非常困難，就連 BBR 算法，都需要更新系統(tǒng)內(nèi)核才能支持。那么，TCP 的性能已經(jīng)到了極致，還能更快嗎？

UDP 相比于 TCP，沒(méi)有那么多的要求，只要將數(shù)據(jù)發(fā)出去就行了，不需要考慮數(shù)據(jù)是否送達(dá)了、不需要考慮數(shù)據(jù)的到達(dá)順序、不需要考慮數(shù)據(jù)的正確性和完整性，所以效率比 TCP 要高出幾個(gè)檔次。

UDP 協(xié)議曾經(jīng)被普遍用于視頻直播、網(wǎng)絡(luò)游戲之類實(shí)時(shí)性要求較高的應(yīng)用，即使少數(shù)幾個(gè)包沒(méi)有送達(dá)對(duì)應(yīng)用整體的影響也不大?？墒牵瑢?duì)于 HTTP 之類的協(xié)議，是需要保證數(shù)據(jù)的正確性、完整性的，所以 UDP 本身并不適合作為 TCP 的替代品。

UDP 不適合替代 TCP 是因?yàn)樗旧聿粚?duì)數(shù)據(jù)進(jìn)行校驗(yàn)，那么如果將數(shù)據(jù)校驗(yàn)放到其他地方去實(shí)現(xiàn)，是不是就可以使用 UDP 了呢？

于是，QUIC 就誕生了，它匯集了 TCP 和 UDP 的優(yōu)點(diǎn)，使用 UDP 來(lái)傳輸數(shù)據(jù)以加快網(wǎng)絡(luò)速度，降低延遲，由 QUIC 來(lái)保證數(shù)據(jù)的順序、完整性和正確性，即使發(fā)生了丟包，也由 QUIC 來(lái)負(fù)責(zé)數(shù)據(jù)的 糾錯(cuò)。

現(xiàn)在，Google 旗下的部分服務(wù)（比如 GMail）以及許多接口已經(jīng)開始使用 QUIC 協(xié)議了。如果你使用的是 Chrome 瀏覽器，可以在瀏覽器的這個(gè)地址：chrome://net-internals/#quic 看到 QUIC 的連接情況。

QUIC 的優(yōu)點(diǎn)

由于 TCP、UDP 協(xié)議是系統(tǒng)內(nèi)核實(shí)現(xiàn)的，更新修改起來(lái)并不很方便，而 QUIC 是軟件層面實(shí)現(xiàn)的，更新迭代起來(lái)非常方便。

UDP 本身是無(wú)序傳輸?shù)模@在單個(gè)連接上并行傳輸多個(gè)數(shù)據(jù)有天生的優(yōu)勢(shì)：多個(gè)數(shù)據(jù)直接發(fā)送即可，由 QUIC 對(duì)收到的數(shù)據(jù)進(jìn)行重新組合排序，然后送往上層應(yīng)用。這中間不用等待各種數(shù)據(jù)確認(rèn)包，效率非常高。

在建立 TCP 連接時(shí)，需要進(jìn)行至少三次握手，如果要開啟 TLS 加密，則還需要進(jìn)行 TLS 握手。而 QUIC 采用了類似于 TCP Fast Open 的技術(shù)，如果之前連接過(guò)，那么之后可以不用重復(fù)握手而直接開始傳送數(shù)據(jù)，以實(shí)現(xiàn) 0-RTT 往返時(shí)延。即便之前沒(méi)有連接過(guò)，也可以在 1-RTT 內(nèi)完成連接并開始傳送數(shù)據(jù)。并且自身就擁有與 TLS 等效的加密措施。

在發(fā)生丟包時(shí)，TCP 會(huì)重傳丟失的包。而 QUIC，則使用了一種非常神奇的前向糾錯(cuò)算法，通過(guò)連續(xù)的幾個(gè)數(shù)據(jù)包的校驗(yàn)和，可以直接恢復(fù)出丟失的包內(nèi)容，而不需要重傳。

在移動(dòng)端表現(xiàn)更好：用戶的網(wǎng)絡(luò)環(huán)境并不穩(wěn)定，Wi-Fi、4G、3G、2G 之間來(lái)回變化，IP 一旦發(fā)生變化，TCP 的連接是不可能保持的。而 QUIC 就不存在這樣的問(wèn)題，通過(guò) ID 來(lái)標(biāo)識(shí)用戶（而不是 IP + 端口），在連接切換后直接恢復(fù)之前的連接會(huì)話。

配合 HTTP/2 API 食用更佳：由于 HTTP/2 采用二進(jìn)制幀傳輸機(jī)制，QUIC 直接使用這樣的機(jī)制進(jìn)行數(shù)據(jù)傳輸，效率更高！

QUIC 的缺點(diǎn)

現(xiàn)在很多網(wǎng)絡(luò)運(yùn)營(yíng)商會(huì)降低 UDP 包的優(yōu)先級(jí)，使得 UDP 丟包率特別高。（QUIC 不可用時(shí)，瀏覽器一般會(huì) Fallback 到 TCP）

目前只有 Chrome、Opera 瀏覽器支持。

什么時(shí)候更適合使用 QUIC？

• 移動(dòng)端由于 QUIC 并不使用 IP + 端口來(lái)標(biāo)識(shí)客戶身份，而是使用 ID，這使得在網(wǎng)絡(luò)環(huán)境切換后還可以保持連接，非常適合用在移動(dòng)網(wǎng)站上面，在手機(jī)信號(hào)不穩(wěn)定的情況下，TCP + TLS 的開銷是非常大的！QUIC 的 0-RTT 可以極大限度地提升訪問(wèn)速度。

總結(jié)

QUIC 實(shí)現(xiàn)的目標(biāo)，就是利用 UDP 實(shí)現(xiàn)一個(gè) TCP，支持 TCP 的所有特性，并且比 TCP 更快更好用。

QUIC 是從 2012 年開始的項(xiàng)目，到目前也還只是草案階段，并且同樣處于草案階段的 TLS1.3 也同樣擁有了 QUIC 中的很多優(yōu)點(diǎn)（比如 0-RTT）。對(duì)于訪問(wèn)速度的優(yōu)化方式越來(lái)越多，適當(dāng)?shù)倪x擇可以為網(wǎng)站增色許多。