未來已來，沒有握手等待的新網絡——HTTP3協定簡介

最近在組會上講了關于HTTP3的相關知識，搜集了很多網上的文章，現在整理出來分享給大家，一起保持技術嗅覺

HTTP3 的起因

在HTTP協定的發展曆程上，Google毫無疑問穩坐第一把手，在坐擁Google搜尋、Gmail、Youtube等一衆全球流量最大的幾個網站的過程中，Google不斷推陳出新，以一己之力推動着HTTP的發展，從HTTP-over-SPDY被吸納為HTTP/2，到如今HTTP-over-QUIC被吸納為HTTP/3，Google可以說是獨領風騷。

QUIC (Quick UDP Internet Connections) 是由google開發的新一代網絡傳輸協定，初衷是利用工程師幾十年的經驗來改進網絡傳輸延遲。（以下的QUIC均指代HTTP3）

在HTTP2已經如此強大的背景下，為什麼還會有HTTP3的出現呢？首先我們要知道的是，TCP/IP出現是在上個世紀70年代，那個時候使用者的網絡情況單一（有線），網絡丢包時有發生，協定的更新非常緩慢，但經過了40多年的迅猛發展，現在網絡的情況已經比當時好了太多，且使用者的網絡環境變得更加多樣（4G、wifi、有線）且時常會有切換網絡的情況發生，這種情況下想要去更新協定就非常困難，因為TCP這類網絡協定棧的實作本來就依賴系統核心更新，而不管是終端裝置，中間裝置的系統更新都極其緩慢，一個更新可能需要5-15年的時間去普及。

舉個例子，浏覽器的相容性問題和速度花費了7年時間，才把IE 6、7這類需要各種奇技淫巧去hack的浏覽器給淘汰掉。

于是QUIC的設計師們決定在傳輸層抛棄TCP，擁抱UDP協定。UDP不需要握手建立連接配接，至于什麼防止IP攻擊，怎麼保證資料一緻性，這些都是UDP之上的工作，把很多工作從傳輸層移動到了應用層，如此一來，以後QUIC協定的更新完全不依賴于底層作業系統，隻需終端和伺服器更新到指定版本即可。

由此帶來的好處和能解決的問題如下：

1. 更快的協定更新。應用程式層面就能實作不同的擁塞控制算法，不需要作業系統，不需要核心支援。這是一個飛躍，因為傳統的 TCP 擁塞控制，必須要端到端的網絡協定棧支援，才能實作控制效果。而核心和作業系統的部署成本非常高，更新周期很長，這在産品快速疊代，網絡爆炸式增長的今天，顯然有點滿足不了需求。比如 TCP Fast Open，雖然在2013 年就被提出了，但是 Windows 很多系統版本依然不支援它。
2. 針對不同網絡的使用者提供不同的擁塞控制。單個應用程式的不同連接配接能支援配置不同的擁塞控制。就算是一台伺服器，接入的使用者網絡環境也千差萬别，結合大資料及人工智能處理，我們能為各個使用者提供不同的但又更加精準更加有效的擁塞控制。
3. 線上熱更新。應用程式不需要停機和更新就能實作擁塞控制的變更，我們在服務端隻需要修改一下配置，reload 一下，完全不需要停止服務就能實作擁塞控制的切換。

QUIC的整體架構

QUIC基于UDP協定實作了類似TCP+TLS+HTTP2的功能組合，可以把QUIC和現有的協定了解成以下結構：

對比HTTP2的優勢

• 降低建立連接配接的延遲，最好情況下是0 RTT，即不需要建立連接配接
• 連接配接遷移（無需考慮使用者網絡環境的切換）
• 無隊頭阻塞的多路複用
• 錯誤自動糾正
• 改進的擁塞控制

下面我們一條條來說：

0 RTT建立連接配接

RTT（round-trip time）顧名思義，就是伺服器和終端一次互動需要的時間。

傳統的TCP協定，我們需要進行3次握手，也就是1.5 RTT，才開始傳輸資料。開啟HTTP/2時，我們通常要建立連接配接，還要确定好加密版本，加密密鑰等資訊，TCP+TLS需要3 RTT，其中TCP耗費了1.5 RTT（三次握手），TLS耗費了1.5 RTT。

0 RTT 的效果是因為QUIC的用戶端會緩存伺服器端發的令牌和證書，當有資料需要再次發送的時候，用戶端可以直接使用舊的令牌和證書，這樣子就實作了 0 RTT 了。對于沒有緩存的情況，伺服器端會直接拒絕請求，并且傳回新生産的令牌和證書。 是以當令牌失效或者沒有緩存的情況下，QUIC還是需要一次握手才能開始傳輸資料。

是以這麼做的話，那麼防範重播攻擊（replay attack）就要從應用層着手了。

連接配接遷移

一條 TCP 連接配接是由四元組辨別的（源 IP，源端口，目的 IP，目的端口）。連接配接遷移指的就是當其中任何一個元素發生變化時，這條連接配接依然維持着，能夠保持業務邏輯不中斷。這裡面主要關注的是用戶端的變化，因為用戶端不可控并且網絡環境經常發生變化，而服務端的 IP 和端口一般都是固定的。

比如大家使用手機在 WIFI 和 4G 移動網絡切換時，用戶端的 IP 肯定會發生變化，需要重建立立和服務端的 TCP 連接配接。

那 QUIC 是如何做到連接配接遷移呢？很簡單，任何一條 QUIC 連接配接不再以 IP 及端口四元組辨別，而是以一個 64 位的随機數作為 ID 來辨別，這樣就算 IP 或者端口發生變化時，隻要 ID 不變，這條連接配接依然維持着，上層業務邏輯感覺不到變化，不會中斷，也就不需要重連，且這個 ID 是用戶端随機産生的，并且長度有 64 位，是以沖突機率非常低。

無隊頭阻塞的多路複用

多路複用是 HTTP2 最強大的特性，但QUIC 的多路複用相比 HTTP2 有一個很大的優勢。

QUIC 一個連接配接上的多個 stream（HTTP 請求） 之間沒有依賴。這樣假如 stream2 丢了一個 udp packet，也隻會影響 stream2 的處理。不會影響 stream2 之前及之後的 stream 的處理。

這也就在很大程度上緩解甚至消除了隊頭阻塞的影響。

如上圖所示，HTTP2 在一個 TCP 連接配接上同時發送 4 個 Stream。其中 Stream1 已經正确到達，并被應用層讀取。但是 Stream2 的第三個 tcp segment 丢失了，TCP 為了保證資料的可靠性，需要發送端重傳第 3 個 segment 才能通知應用層讀取接下去的資料，雖然這個時候 Stream3 和 Stream4 的全部資料已經到達了接收端，但都被阻塞住了。

不僅如此，由于 HTTP2 強制使用 TLS，還存在一個 TLS 協定層面的隊頭阻塞。

QUIC 的多路複用為什麼能避免上述問題呢？

1. QUIC 最基本的傳輸單元是 Packet，整個加密和認證過程都是基于 Packet 的，不會跨越多個 Packet。這樣就能避免 TLS 協定存在的隊頭阻塞。
2. Stream 之間互相獨立，比如 Stream2 丢了一個 Pakcet，不會影響 Stream3 和 Stream4。

這裡要提及一下，QUIC也是有可能存在隊頭阻塞的，若QUIC 使用 Hpack 壓縮算法，由于算法的限制，丢失一個頭部資料時，可能遇到隊頭阻塞。

總體來說，QUIC 在傳輸大量資料時，比如視訊，受到隊頭阻塞的影響很小。

QUIC 所帶來的挑戰

99%+以上的手機移動終端、電腦終端，都使用私有IP，都需要NAT裝置來完成私有IP與全球IP的轉換。這意味着NAT裝置通常會記憶使用者的通信狀态，一旦使用者完成了通信，NAT裝置會釋放這些記憶。

對于基于TCP的HTTP、HTTPS傳輸，NAT裝置可以根據TCP封包頭的SYN / FIN狀态位，知道通信什麼時候開始，什麼時候結束，對應記憶的開始、記憶的結束。

但是基于UDP傳輸的HTTP/3，NAT裝置收到流量會知道連接配接什麼時候開始，但是卻無法知道流量什麼時候結束。

1. NAT裝置的記憶如果短于使用者會話時間，則使用者會話會中斷。
2. NAT裝置的記憶如果大大長于使用者會話時間，則意味着NAT裝置的端口資源會白白被占用！

最有效的解決方案，是讓QUIC周期性地發送Keepalive消息，重新整理NAT裝置的記憶，避免NAT裝置釋放自己的記憶。

我的感想

1. 未來網絡協定的發展已經被幾家大公司主導的了，廣大開發者需要耐心等待協定的更新。
2. 網絡協定的更新應當是能夠被快速更新的，這樣才能适應這個快速變化的時代。
3. 協定的更新是有迹可循的，善用前人留下的财富才是王道。TCP所遺留下來的東西沒有被抛棄，隻是實作從傳輸層移動到了應用層。

限于篇幅，本文不再詳細介紹QUIC的細節，有興趣的可以參考下面的引用資料。

參考資料：

1. https://www.nanog.org/sites/default/files//meetings/NANOG64/1051/20150603_Rogan_Quic_Next_Generation_v1.pdf
2. https://docs.google.com/document/d/1gY9-YNDNAB1eip-RTPbqphgySwSNSDHLq9D5Bty4FSU/edit
3. https://genuifx.github.io/2018/11/27/keynote-for-http3-quic/
4. https://zhuanlan.zhihu.com/p/27938635
5. https://www.zhihu.com/question/302412059/answer/533223530
6. https://zhuanlan.zhihu.com/p/32553477