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

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

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

QUIC 是什么申鱼？

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

為了加快 TCP 的傳輸效率骂维，Google 提出了 BBR 擁塞控制算法惹资，將 TCP 的性能發(fā)揮到了極致。由于 TCP 和 UDP 協(xié)議是系統(tǒng)內(nèi)核實現(xiàn)的航闺，要提出新的協(xié)議不是不行褪测，只是普及起來會非常困難，就連 BBR 算法潦刃，都需要更新系統(tǒng)內(nèi)核才能支持侮措。那么，TCP 的性能已經(jīng)到了極致乖杠，還能更快嗎分扎？

UDP 相比于 TCP，沒有那么多的要求胧洒，只要將數(shù)據(jù)發(fā)出去就行了畏吓，不需要考慮數(shù)據(jù)是否送達了、不需要考慮數(shù)據(jù)的到達順序卫漫、不需要考慮數(shù)據(jù)的正確性和完整性菲饼，所以效率比 TCP 要高出幾個檔次。

UDP 協(xié)議曾經(jīng)被普遍用于視頻直播列赎、網(wǎng)絡(luò)游戲之類實時性要求較高的應(yīng)用宏悦，即使少數(shù)幾個包沒有送達對應(yīng)用整體的影響也不大。可是饼煞，對于 HTTP 之類的協(xié)議源葫，是需要保證數(shù)據(jù)的正確性、完整性的砖瞧，所以 UDP 本身并不適合作為 TCP 的替代品息堂。

UDP 不適合替代 TCP 是因為它本身不對數(shù)據(jù)進行校驗，那么如果將數(shù)據(jù)校驗放到其他地方去實現(xiàn)芭届，是不是就可以使用 UDP 了呢储矩？

于是感耙，QUIC 就誕生了褂乍，它匯集了 TCP 和 UDP 的優(yōu)點，使用 UDP 來傳輸數(shù)據(jù)以加快網(wǎng)絡(luò)速度即硼，降低延遲逃片，由 QUIC 來保證數(shù)據(jù)的順序、完整性和正確性只酥，即使發(fā)生了丟包褥实，也由 QUIC 來負責數(shù)據(jù)的糾錯。

<figure style="display: block; margin: 22px auto; text-align: center;">[圖片上傳失敗...(image-5982c2-1530347615435)]

</figure>

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

QUIC 的優(yōu)點

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

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

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

在發(fā)生丟包時抡爹，TCP 會重傳丟失的包。而 QUIC芒划，則使用了一種非常神奇的前向糾錯算法冬竟，通過連續(xù)的幾個數(shù)據(jù)包的校驗和，可以直接恢復出丟失的包內(nèi)容民逼，而不需要重傳泵殴。

在移動端表現(xiàn)更好：用戶的網(wǎng)絡(luò)環(huán)境并不穩(wěn)定，Wi-Fi拼苍、4G笑诅、3G、2G 之間來回變化疮鲫，IP 一旦發(fā)生變化吆你，TCP 的連接是不可能保持的。而 QUIC 就不存在這樣的問題俊犯，通過 ID 來標識用戶（而不是 IP + 端口）妇多，在連接切換后直接恢復之前的連接會話。

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

QUIC 的缺點

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

目前只有 Chrome杖虾、Opera 瀏覽器支持烂瘫。

什么時候更適合使用 QUIC？

移動端由于 QUIC 并不使用 IP + 端口來標識客戶身份奇适，而是使用 ID坟比，這使得在網(wǎng)絡(luò)環(huán)境切換后還可以保持連接，非常適合用在移動網(wǎng)站上面嚷往，在手機信號不穩(wěn)定的情況下葛账，TCP + TLS 的開銷是非常大的！QUIC 的 0-RTT 可以極大限度地提升訪問速度皮仁。

總結(jié)

QUIC 實現(xiàn)的目標籍琳，就是利用 UDP 實現(xiàn)一個 TCP菲宴，支持 TCP 的所有特性，并且比 TCP 更快更好用趋急。

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