作者 | 阿文
責(zé)編 | 郭芮
出品 | CSDN（ID：CSDNnews）
超文本傳輸協(xié)議（HyperText Transfer Protocol）是一種用于分布式、協(xié)作式和超媒體信息系統(tǒng)的應(yīng)用層協(xié)議。自1990年代初以來(lái)，HTTP協(xié)議是整個(gè)Internet進(jìn)行數(shù)據(jù)通信的基礎(chǔ)。
在 HTTP/1.0 中，每一個(gè)TCP請(qǐng)求或響應(yīng)都會(huì)被分配一個(gè)新的連接，這就導(dǎo)致了連接啟動(dòng)緩慢，在此之后，如何規(guī)避 TCP 啟動(dòng)慢就一直是 HTTP協(xié)議改善的核心。此后，在HTTP/1.1中引入了keep-alive 的概念，其允許在同一個(gè) TCP 連接中對(duì)多個(gè)請(qǐng)求或響應(yīng)進(jìn)行序列號(hào)，從而使得不需要為每個(gè)請(qǐng)求都設(shè)置新的連接，避免建立新連接帶來(lái)的網(wǎng)絡(luò)開(kāi)銷。但是這個(gè)版本的keep-alive 連接不支持同時(shí)發(fā)送多個(gè)請(qǐng)求，隨著互聯(lián)網(wǎng)的迅猛發(fā)展又帶來(lái)了新的問(wèn)題：如何讓數(shù)據(jù)發(fā)送效率提高？
在2015年，HTTP發(fā)布了第二個(gè)版本，即HTTP/2，進(jìn)行了重大更新。例如：
- 在建立連接后，可以多路復(fù)用；
- 在建立連接后，一次的請(qǐng)求與被響應(yīng)，視為流；
- 數(shù)據(jù)傳輸分為二進(jìn)制幀片段。
而 HTTP/3是HTTP協(xié)議的第三個(gè)主要版本。在HTTP/3中，將棄用TCP協(xié)議，改為使用基于UDP協(xié)議的QUIC協(xié)議實(shí)現(xiàn)。實(shí)際上 HTTP/3 的前身是HTTP over QUIC，QUIC 是快速UDP網(wǎng)絡(luò)連接的簡(jiǎn)稱，由google公司研發(fā)，該協(xié)議旨在取代TCP協(xié)議，使網(wǎng)頁(yè)傳輸更快、更穩(wěn)定、更安全。
2018年10月，互聯(lián)網(wǎng)工程任務(wù)組（IETF） HTTP和QUIC工作組主席Mark Nottingham提出了將HTTP-over-QUIC更名為HTTP/3，以區(qū)分其特點(diǎn)以及與Google 公司的QUIC的獨(dú)立性。
1.為什么使用UDP+QUIC？
實(shí)際上，在此前的HTTP協(xié)議中一直是使用TCP作為傳輸協(xié)議。為什么在HTTP/3中要換成UDP呢？眾所周知，TCP 是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議，在數(shù)據(jù)傳輸過(guò)程中其加入了序列號(hào)、對(duì)收到的保溫進(jìn)行排序以檢測(cè)重復(fù)數(shù)據(jù)，數(shù)據(jù)重傳、擁塞控制、使用校驗(yàn)和確保無(wú)錯(cuò)傳輸、流控制等。使用TCP 協(xié)議進(jìn)行數(shù)據(jù)傳輸會(huì)經(jīng)過(guò)三次握手，在連接創(chuàng)建過(guò)程中，很多參數(shù)要被初始化，例如序號(hào)被初始化以保證按序傳輸和連接的強(qiáng)壯性，其目的是保證數(shù)傳輸和斷開(kāi)的可靠，確保所有數(shù)據(jù)都被完全傳輸。因此很多對(duì)業(yè)務(wù)穩(wěn)定性非常高的協(xié)議都一直采用TCP協(xié)議作為數(shù)據(jù)傳輸協(xié)議。
TCP 報(bào)頭：
事實(shí)上，在HTTP/2 之前的版本中，都是采用TCP 進(jìn)行數(shù)據(jù)傳輸?shù)摹６?HTTP/2 引入的多路復(fù)用技術(shù)改善了HTTP/1.1的keep-alive 帶來(lái)的缺陷，但是當(dāng)數(shù)據(jù)包丟失增加，HTTP/2的性能會(huì)由于TCP處理包重傳的方式（HOL阻塞）而下降，從而大大影響效率。因?yàn)樗械牧鞫际枪蚕硗粋€(gè)連接，當(dāng)數(shù)據(jù)包丟失超出閾值，HTTP/2的運(yùn)行效率可能還不如HTTP/1的效率高。
而UDP協(xié)議則比較簡(jiǎn)單，其特點(diǎn)如下：
- 無(wú)需建立連接，因此UDP不會(huì)引入建立連接的時(shí)延；
- 沒(méi)有TCP 那么復(fù)雜的報(bào)頭，例如重傳、序列號(hào)等等；
- 速度快，但是不保證數(shù)據(jù)的完整性。
其報(bào)頭如下：
那么既然使用UDP進(jìn)行數(shù)據(jù)傳輸如此不可靠，為什么 HTTP/3 會(huì)使用UDP？
事實(shí)上，這與整個(gè)互聯(lián)網(wǎng)快速發(fā)展的大背景有關(guān)系。隨著移動(dòng)互聯(lián)網(wǎng)快速發(fā)展以及物聯(lián)網(wǎng)以及5G技術(shù)的逐步興起，網(wǎng)絡(luò)交互的場(chǎng)景越來(lái)越豐富，大量的音頻、視頻、直播等數(shù)據(jù)在網(wǎng)絡(luò)傳上傳輸，用戶對(duì)網(wǎng)絡(luò)傳輸效率和 WEB 響應(yīng)速度的要求也越來(lái)越高。HTTP/3 協(xié)議當(dāng)然不能單獨(dú)使用UDP協(xié)議，它必須在QUIC的配合下才可以使用UDP，其把數(shù)據(jù)的完整性校驗(yàn)這一環(huán)節(jié)放在了UDP協(xié)議之上，QUIC的特點(diǎn)：
減少了 TCP 三次握手及 TLS 握手時(shí)間，使用TCP協(xié)議配合HTTPS，TLS 完全握手需要至少 2 個(gè) RTT 才能建立，簡(jiǎn)化握手需要 1 個(gè) RTT 的握手延遲，而QUIC在TLS握手時(shí)間上，由于建立在 UDP 的基礎(chǔ)上，同時(shí)又實(shí)現(xiàn)了 0RTT 的安全握手，所以在大部分情況下，只需要 0 個(gè) RTT 就能實(shí)現(xiàn)數(shù)據(jù)發(fā)送。
改進(jìn)的擁塞控制，QUIC 協(xié)議當(dāng)前默認(rèn)使用了 TCP 協(xié)議的 Cubic 擁塞控制算法，同時(shí)也支持 CubicBytes, Reno, RenoBytes, BBR, PCC 等擁塞控制算法。
避免隊(duì)頭阻塞的多路復(fù)用，隊(duì)頭阻塞主要是 TCP 協(xié)議的可靠性機(jī)制引入的。上面說(shuō)了TCP為了實(shí)現(xiàn)可靠性，使用了很多機(jī)制來(lái)保障數(shù)據(jù)的傳輸，例如使用序列號(hào)來(lái)標(biāo)識(shí)數(shù)據(jù)的順序，數(shù)據(jù)必須按照順序處理，如果前面的數(shù)據(jù)丟失，后面的數(shù)據(jù)就算到達(dá)了也不會(huì)通知應(yīng)用層來(lái)處理。而QUIC使用UDP，沒(méi)有三次握手和連接，只需要用戶端和服務(wù)端的應(yīng)用程序支持 QUIC 協(xié)議，完全避開(kāi)了操作系統(tǒng)和中間設(shè)備的限制，同時(shí)相比此前的HTTP/2的多路復(fù)用，QUIC 一個(gè)連接上的多個(gè)流之間沒(méi)有依賴。這樣可以更快地并行處理任務(wù)。
比TCP協(xié)議更安全，TCP 協(xié)議的頭部沒(méi)有加密和認(rèn)證，在傳輸過(guò)程中很容易被篡改，注入和竊聽(tīng)。而 QUIC 除了個(gè)別報(bào)文比如 PUBLIC_RESET 和 CHLO，所有報(bào)文頭部都是經(jīng)過(guò)認(rèn)證的，報(bào)文 Body 都是經(jīng)過(guò)加密的。
能夠連接遷移，什么是連接遷移？比如使用手機(jī)從無(wú)線網(wǎng)切換到移動(dòng)5G，這時(shí)客戶端的IP會(huì)改變，需要重新建立和服務(wù)端的 TCP 連接。而QUIC實(shí)現(xiàn)了任何一條 QUIC 連接不再以 IP 及端口進(jìn)行標(biāo)識(shí)，而是以一個(gè) 64 位的隨機(jī)數(shù)作為 ID 來(lái)標(biāo)識(shí)，這樣當(dāng)網(wǎng)絡(luò)變化，IP和端口改變，只要 ID 不變，這條連接依然維持著，上層業(yè)務(wù)邏輯感知不到變化，不會(huì)中斷，也就不需要重連。且由于這個(gè)ID是隨機(jī)的，產(chǎn)生沖突的概率非常小。
更科學(xué)的流量控制器，TCP 為了保證可靠性，窗口左邊沿向右滑動(dòng)時(shí)的長(zhǎng)度取決于已經(jīng)確認(rèn)的字節(jié)數(shù)。如果中間出現(xiàn)丟包，就算接收到了更大序號(hào)的 Segment，窗口也無(wú)法超過(guò)這個(gè)序列號(hào)。而QUIC 基于流和連接級(jí)別的流量控制，類似HTTP/2，通過(guò)window_update幀告訴對(duì)端自己可以接收的字節(jié)數(shù)，這樣發(fā)送方就不會(huì)發(fā)送超過(guò)這個(gè)數(shù)量的數(shù)據(jù)。通過(guò)BlockFrame告訴對(duì)端由于流量控制被阻塞了，無(wú)法發(fā)送數(shù)據(jù)。就算此前有些數(shù)據(jù)包沒(méi)有接收到，它的滑動(dòng)只取決于接收到的最大偏移字節(jié)數(shù)。
2 如何使用 HTTP/3？
好了，介紹了HTTP/3，那么我們?cè)趺床拍軌蚴褂肏TTP/3呢？事實(shí)上，現(xiàn)在很多云廠商都實(shí)現(xiàn)了 HTTP/3，比如騰訊云的負(fù)載均衡器、阿里云的CDN服務(wù)、CloudFlare等等。那么如果你是使用類似Nginx這樣的Web服務(wù)器如何使用HTTP/3呢？
以Nginx 為例，實(shí)際上，Nginx 在 2019 年 3 月 21 日公布了 1.17.x 版本的路線圖，其中談到了支持 QUIC 和 HTTP/3 的計(jì)劃。但是至今，Nginx 已經(jīng)發(fā)布了 1.17.8 的版本，在最新的1.17.8的 CHANGES 中也沒(méi)有發(fā)現(xiàn)HTTP/3的身影。估計(jì)如果希望原生的 Nginx 支持 HTTP/3 還需要繼續(xù)等待。
可喜的是邊緣計(jì)算廠商 CloudFlare 開(kāi)源了 QUIC 的實(shí)現(xiàn) quiche，使得 Nginx 提前支持 HTTP/3 ，quiche 項(xiàng)目地址: https://github.com/cloudflare/quiche/tree/master/extras/nginx 。
CloudFlare 已經(jīng)成功在其CDN業(yè)務(wù)中實(shí)現(xiàn)了QUIC的部署，基于HTTP3 Quic的實(shí)現(xiàn)靠的就是他們開(kāi)發(fā)的Quiche實(shí)現(xiàn)。
根據(jù) quiche 的文檔，需要下載源碼和 Nginx 一同編譯，而因?yàn)樾枰?BoringSSL 以及 quiche 開(kāi)發(fā)語(yǔ)言的不同，在編譯 Nginx 所需要的環(huán)境基礎(chǔ)上，還需要 cmake、rust、cargo、golang 等一系列工具的支持。
安裝步驟
1.下載的nginx并解壓，注意，這個(gè)補(bǔ)丁只支持1.16.x。
curl -O https://nginx.org/download/nginx-1.16.1.tar.gz
tar xzvf nginx-1.16.1.tar.gz
2.克隆quiche：
git clone --recursive https://github.com/cloudflare/quiche
3.使用patch將補(bǔ)丁引入：
cd nginx-1.16.1
patch -p01 < ../quiche/extras/nginx/nginx-1.16.patch
4.構(gòu)建nginx， 使其支持 HTTP/3：
./configure
--prefix=$PWD
--build="quiche-$(git --git-dir=../quiche/.git rev-parse --short HEAD)"
--with-http_ssl_module
--with-http_v2_module
--with-http_v3_module
--with-openssl=../quiche/deps/boringssl
--with-quiche=../quiche
5.執(zhí)行make：
make
6.然后配置nginx的vhost，一個(gè)HTTP/3的配置如下：
server {
listen 80;
# Enable HTTP/2 (optional).
listen 443 ssl http2;
# Enable QUIC and HTTP/3.
listen 443 quic reuseport;
server_name www.awen.me;
root /vdata/www/default;
index index.html;
ssl_certificate /usr/local/nginx/ssl/awen.me.crt;
ssl_certificate_key /usr/local/nginx/ssl/awen.me.key;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ……
# Add Alt-Svc header to negotiate HTTP/3.
add_header alt-svc 'h3-23=":443"; ma=86400';
……
}
更具體的配置和說(shuō)明，可以參考官方文檔https://github.com/cloudflare/quiche/tree/master/extras/nginx。
QUIC 的實(shí)現(xiàn)原理是首先客戶端發(fā)起 tcp 連接判斷服務(wù)端響應(yīng)頭是否有 alt-svc 頭，如有則嘗試使用 udp 443 去進(jìn)行連接。因此，我們看到上面的配置中 add_header alt-svc 'h3-23=":443"; ma=86400';，客戶端請(qǐng)求類似如下：
Alt-Svc 全稱為“Alternative-Service”，直譯為“備選服務(wù)”。該頭部列舉了當(dāng)前站點(diǎn)備選的訪問(wèn)方式列表。一般用于在提供 “QUIC” 等新興協(xié)議支持的同時(shí)，實(shí)現(xiàn)向下兼容。
h3-23=":443" 這部分內(nèi)容定義了替代服務(wù)使用的協(xié)議、主機(jī)名和端口，其中主機(jī)名和端口可選，多個(gè)替代服務(wù)之間用英文逗號(hào)分隔。
ma 是 max-age 的縮寫(xiě)，單位為秒。顯然，它表示瀏覽器在指定時(shí)間內(nèi)，可以直接使用替代服務(wù)地址。
客戶端訪問(wèn)
1.瀏覽器配置
以Chrome 為例進(jìn)行配置，開(kāi)啟 quic 的支持，chrome://flags 安裝如圖所示 Experimental QUIC protocol 設(shè)置為 enable 重啟瀏覽器：
2.如何判斷QUIC是否已經(jīng)生效？
第一種方法是安裝插件，在Chrome商店安裝 HTTP/2 and SPDY indicator，右上角有個(gè)閃電圖標(biāo)會(huì)顯示 google 已經(jīng)開(kāi)啟 quic/43版本的支持。如圖所示：
打開(kāi) chrome://net-internals/#quic 也可以看到當(dāng)前使用 quic 協(xié)議的站點(diǎn)連接情況。第二種方式是通過(guò)wireshark抓包也可以看到QUIC的數(shù)據(jù)包。
