HTTP 的第一次變革 — HTTP/2

網(wǎng)絡(luò)優(yōu)化系列專題艰垂，聊一聊面對復(fù)雜多變的移動網(wǎng)絡(luò)权薯，我們需要掌握哪些網(wǎng)絡(luò)基礎(chǔ)知識匙握，以及該如何做好網(wǎng)絡(luò)優(yōu)化這項工作骑篙。

網(wǎng)絡(luò)優(yōu)化系列專題

網(wǎng)絡(luò)優(yōu)化背景知識（待完善）

《關(guān)于 5G，你應(yīng)該知道的發(fā)展史》
《HTTP 發(fā)展的前世今生》
《網(wǎng)絡(luò)安全 — HTTPS》
《關(guān)于網(wǎng)絡(luò)優(yōu)化井辜，你需要了解什么修壕？》
《HTTP 的第一次變革 — HTTP/2》
《展望更好 — HTTP/3》

如何優(yōu)化網(wǎng)絡(luò)性能（待更）

...

在前面的《網(wǎng)絡(luò)安全系列》我們已經(jīng)介紹了安全部分的 HTTPS钉凌，通過引入 SSL/TLS 使 HTTP 在網(wǎng)絡(luò)通信過程中的安全達到了“極致”腐魂。但是這么多年以來 HTTP 本身在性能方面的提升卻在原地踏步帐偎。對于整體的數(shù)據(jù)傳輸并沒有提出更好的改進方案。甚至在 HTTP/1.x 我們還只能依賴 keep-alive 這種“長連接”技術(shù)蛔屹。

在《HTTP 發(fā)展的前世今生》中我們有講過削樊，Google 對 HTTP 的性能不滿而率先“起義” — SPDY 協(xié)議，并在自家的 Chrome 瀏覽器中大獲成功兔毒，從此開始倒逼 HTTP 協(xié)議的變革漫贞。

今天我們就來聊一聊 HTTP 協(xié)議的第一次重大變革 HTTP/2，看看它給我們帶來了哪些新的優(yōu)化內(nèi)容育叁。

為什么不是 HTTP/2.0迅脐？

先來解答一個疑惑，細(xì)心的朋友肯定會發(fā)現(xiàn)這次怎么不像之前的 “1.0”豪嗽、“1.1” 那樣叫 “2.0” 呢谴蔑？

對此 HTTP/2 工作組也給出了解釋，他們認(rèn)為以前 “1.0”昵骤、“1.1” 的版本管理方式造成了很多混亂和誤解，讓使用人員在實際應(yīng)用過程中難以區(qū)分它們之間的差異肯适，所以從這次決定 HTTP 協(xié)議將不再使用小版本號（minor version）变秦，只使用大版本號（marjor version），故從今往后的 HTTP 版本不會再有 HTTP/2.0框舔、2.1蹦玫，只會有 “HTTP/2”赎婚、“HTTP/3” ......

這也決定了 HTTP 在未來的發(fā)展中不會再有“零碎敲打”的小改良樱溉，HTTP 工作組在今后發(fā)布的每一個 HTTP 版本挣输，都必須與上一個版本有本質(zhì)上的不同。同樣這種“躍進程度”對于使用者來說也更容易區(qū)分了福贞。

兼容 HTTP/1

HTTP/1.x 的設(shè)計初衷主要是實現(xiàn)要簡單撩嚼，然而這種實現(xiàn)簡單卻是以犧牲應(yīng)用性能為代價的。而這也是 HTTP/2 要致力于解決的核心問題挖帘，所以 HTTP/2 的唯一目標(biāo)就是改進性能完丽。

由于 HTTPS 在安全方面已經(jīng)做的非常好了，所以 HTTP/2 直接沿用即可拇舀，不過它還是有一些要求的逻族，這個我們后面會講到。

但是由于 HTTP/1 龐大且沉重的歷史包袱骄崩，所以協(xié)議的修改必須小心謹(jǐn)慎聘鳞，兼容性是首要考慮的目標(biāo)，否則就會破壞到互聯(lián)網(wǎng)上無數(shù)現(xiàn)有的資產(chǎn)要拂，這方面 TLS 1.3 已經(jīng)有了先例（為了兼容 TLS 1.2 不得不進行“偽裝”）抠璃。

那么，HTTP/2 是怎么做的呢宇弛？

因為必須要保持功能上的兼容鸡典，HTTP/2 不會改動 HTTP 的語義部分：HTTP 方法、狀態(tài)碼枪芒、URI 及頭部字段等彻况，這些核心概念都保留不變。即基于 HTTP 的上層應(yīng)用也不需要做任何修改舅踪，可以無縫轉(zhuǎn)換到 HTTP/2纽甘。

特別要說的是，HTTP/2 沒有在 URI 中引入新的協(xié)議名抽碌，仍然用 “http” 表示明文協(xié)議悍赢，用 “https” 表示加密協(xié)議。這是一個了不起的決定货徙，這樣客戶端或服務(wù)器可以自動升降級協(xié)議左权，免去了選擇的麻煩，讓用戶在上網(wǎng)的時候都意識不到協(xié)議的切換痴颊，實現(xiàn)平滑過渡赏迟。

在 “語義” 保持基本不變的情況下，HTTP/2 在“語法”層做了“天翻地覆”地改造蠢棱，完全變更了原有 HTTP 報文的傳輸方式锌杀。

優(yōu)化了哪些問題

前面我們有說到甩栈，HTTP/2 的唯一目標(biāo)是改良性能，因此 HTTP/2 不會對之前的版本再做出任何妥協(xié)糕再，這次要“大刀闊斧”的進行改良量没，下面我們就一起來看下 HTTP/2 主要優(yōu)化了哪些內(nèi)容？

“大頭兒子”問題

如今突想，每個客戶端發(fā)起的 HTTP 請求殴蹄，至少會攜帶幾百甚至上千字節(jié)的頭部數(shù)據(jù)，用于描述傳輸?shù)馁Y源及其屬性蒿柳。在 HTTP/1.x 中這些元數(shù)據(jù)都是以純文本形式發(fā)送的饶套，通常會給每個請求增加 500 ~ 800 字節(jié)的額外開銷。

而且由于報文中一般會攜帶 “User Agent”垒探、“Cookie”妓蛮、“Accept” 和 “Server” 等許多固定的頭字段，此時情況將會變得更糟圾叼，下面我們以 cookie 為例蛤克。

Cookie

HTTP 本身是一種無狀態(tài)的協(xié)議（就是說服務(wù)器不必保存每次請求的客戶端信息），但是在增加了 cookie 之后使得 HTTP 具有了會話管理的能力夷蚊，然而過渡依賴這些狀態(tài)信息构挤，實現(xiàn)會話管理和個性化等功能時，可能會附加幾百甚至上千字節(jié)惕鼓。這么多的元數(shù)據(jù)跟隨請求傳遞筋现，必然會給應(yīng)用帶來明顯的性能損失。

HTTP 并沒有限制 cookie 的大小箱歧，但實踐中大多數(shù)瀏覽器會將其限制在一個固定范圍之內(nèi)矾飞，一般為 4KB。

要知道此時我們的 body 卻經(jīng)常只有幾十字節(jié)（比如 GET 請求呀邢、204/301/304 響應(yīng)）洒沦，可能更要命的是，成千上萬的請求響應(yīng)報文里有很多字段值都是重復(fù)的价淌，非常浪費申眼。
此時請求頭成了不折不扣的“大頭兒子”，而 cookie 則是這個“大頭兒子”中的重頭蝉衣。

注意這里并不是說 cookie 是萬惡之源括尸，但是它的確會帶來性能瓶頸，對此我們應(yīng)該合理的利用并消除這些不必要的請求字節(jié)病毡。

頭部壓縮

所以濒翻，HTTP/2 把“頭部壓縮” 作為性能改進的一個重點，優(yōu)化的方式大家也肯定想的到剪验，還是“壓縮”肴焊，不過壓縮并非這次的終點。

HTTP/2 并沒有使用傳統(tǒng)的壓縮算法功戚，而是開發(fā)了專門的 “HPACK” 算法娶眷，在客戶端和服務(wù)器兩端建立“字典”，用索引號表示重復(fù)的字符串啸臀，采用哈夫曼編碼來壓縮整數(shù)和字符串届宠，整體壓縮率可以達到 50% ~ 90%。

HTTP/2 是從 SPDY 發(fā)展而來乘粒，SPDY 早期采用 zlib 和自定義字典壓縮所有 HTTP 首部豌注，可以有效減少 85% ~ 88% 的首部開銷，從而顯著減少加載頁面的時間灯萍。由于后期出現(xiàn)了針對該算法的安全攻擊轧铁，于是 zlib 壓縮算法被撤銷。

下面我們看下由 Google 性能專家 Ilya Grigorik 在 Velocity 2015. SC 會議中分享的 HTTP/2 中有關(guān) HPACK 的頭部壓縮旦棉。

首先 HTTP/2 的頭部壓縮需要客戶端和服務(wù)器同時支持齿风，雙方：

維護一份相同的靜態(tài)字典（Static Table），包含常見的頭部名稱绑洛，以及特別常見的頭部名稱與值的組合救斑；
維護一份相同的動態(tài)字典（Dynamic Table），可以動態(tài)地添加內(nèi)容真屯；
支持基于靜態(tài)哈夫曼表的哈夫曼編碼（Huffman Coding）脸候。

靜態(tài)字典的作用有兩個，一個是對于完全匹配的頭部鍵值對绑蔫，例如: method:GET运沦，可以直接使用一個字符表示，另一個是對于頭部名稱可以匹配的鍵值對晾匠，例如 cookie : xxxxxx茶袒，可以將名稱使用一個字符表示。

使用字典可以極大地提升壓縮效果凉馆，其中靜態(tài)字典首次請求就可以使用薪寓。對于靜態(tài)、動態(tài)字段中不存在的內(nèi)容再使用哈夫曼編碼來減小體積澜共。

另外向叉，HTTP/2 對原來 HTTP 協(xié)議的請求行例如 Method、Path嗦董、Status 等母谎，在 HTTP/2 中被拆解成鍵值對放入頭部京革，此時也可以享受到字典和哈夫曼壓縮幸斥。另外 HTTP/2 中所有頭部 key 必須小寫。

利用 HTTP/2 協(xié)議本身帶來的性能優(yōu)化甲葬，雖然這部分元數(shù)據(jù)經(jīng)過了壓縮，那是不是意味著從此“高枕無憂”了呢懈贺？答案是否定的经窖，我們依然不能忽視它們存在所帶來的開銷梭灿。

如果你想更深入了解 HTTP/2 的頭部壓縮算法，你還可以繼續(xù)閱讀下面的文章堡妒。

全面了解 HTTP/2 壓縮算法
RFC 7541
HTTP/2 頭部壓縮技術(shù)介紹

二進制格式

相信大家早已習(xí)慣 HTTP/1 的純文本形式的報文了配乱，它的優(yōu)點是“一目了然”，用最簡單的工具就可以開發(fā)調(diào)試皮迟，非常方便。

對人類友好的往往對計算機并不那么“友好”佑钾，這次 HTTP/2 沒有再“妥協(xié)”，而是向以二進制為基礎(chǔ)的下層 TCP/IP 協(xié)議“靠攏”休溶，全面采用二進制格式扰她。

主要是純文本會有多義性，比如大小寫徒役、空白字符、回車換行忧勿、多字勺子等，程序在處理時必須用復(fù)雜的狀態(tài)機熏挎，這不僅導(dǎo)致效率低晌砾、還麻煩。而二進制里只有 “0” 和 “1”，可以嚴(yán)格規(guī)定對錯都伪，解析起來也沒有歧義积担，實現(xiàn)簡單，體積小磅轻、速度快逐虚。

二進制分幀層

以二進制格式為基礎(chǔ)， HTTP/2 決定改變延續(xù)了十多年的現(xiàn)狀叭爱，而這也是 HTTP/2 性能增強的核心撮躁，新增的二進制分幀層定義了如何封裝 HTTP 消息并在客戶端與服務(wù)器之間傳輸。

HTTP/2 在保持原有“語義”不變的前提下买雾，在 Socket 接口與應(yīng)用可見的高層 HTTP API 之間增加了一層二進制分幀層把曼，保證原來的不受到影響漓穿。不同的是數(shù)據(jù)傳輸期間的編碼方式發(fā)生了變化。HTTP/2 將所有傳輸?shù)男畔⒎指顬楦〉南⒑蛶鹱λ麄儾捎枚M制格式的編碼僚饭。

因此以二進制格式為基礎(chǔ)的 HTTP/2 開始了重大改革，把 TCP 協(xié)議的部分特性挪到了應(yīng)用層苇瓣，把原來固有的 “Header+Body” 的消息拆解成數(shù)個小段的二進制“幀”（Frame）偿乖，用 “HEADERS” 幀存放頭數(shù)據(jù)、“DATA” 幀存放實體數(shù)據(jù)贪薪。

這個好像與 “Chunked” 分塊編碼有點類似，都屬于“化整為零”的思路损话。但是 HTTP/2 數(shù)據(jù)分幀之后 “Header + Body” 的報文結(jié)構(gòu)就完全消失了，協(xié)議看到的只是一個個的數(shù)據(jù)“碎片”光涂。

虛擬的“流”

消息的“碎片”到達目的地后應(yīng)該怎么組裝起來呢拧烦？

HTTP/2 為此定義了一個“流”（Stream）的概念，它是二進制幀的雙向傳輸序列齐佳，同一個消息往返的幀會被分配一個唯一的流 ID债沮。你可以把它想象成是一個虛擬的“數(shù)據(jù)流”，在里面流動的是一串有先后順序的數(shù)據(jù)幀疫衩，這些數(shù)據(jù)幀按照次序組裝起來就是 HTTP/1 里的請求報文和響應(yīng)報文了。

這個流實際是虛擬的童芹，實際上并不存在鲤拿，所以 HTTP/2 就可以在一個 TCP 連接上用 “流”同時發(fā)送多個“碎片化”消息，這就是常說的“多路復(fù)用”（Multiplexing）— 多個往返通信都復(fù)用一個 TCP 連接來處理嗜价。

HTTP/2 的多路復(fù)用與 keep-alive 有本質(zhì)上的差異幕庐，多路復(fù)用多個請求沒有先后順序，而 keep-alive 多個請求必須排隊瑟由，這就是所說的 HTTP 隊首阻塞冤寿。

為了更好地利用連接，加大吞吐量督怜，HTTP/2 還添加了一些控制幀來管理虛擬的”流“，實現(xiàn)了優(yōu)先級和流量控制蚪腋，這些特性也和 TCP 協(xié)議非常相似。

解決隊首阻塞

在 HTTP 1.x 中立帖，如果客戶端想發(fā)送多個并行的請求悠砚，那么必須使用多個 TCP 連接。這種模型只能保證每個連接每次只交付一個響應(yīng)（多個響應(yīng)必須排隊）灌旧。更糟糕的是，這種模型會導(dǎo)致 HTTP 的隊首阻塞描融，導(dǎo)致底層的 TCP 連接空閑使效率變得低下宗苍。

HTTP/1.1 的管道使請求隊列（FIFO）從客戶端（請求隊列）遷移到服務(wù)器（響應(yīng)隊列）薄榛，消除了發(fā)送請求和響應(yīng)的等待時間，不過這種僅并行處理請求的能力并不能解決 HTTP 本質(zhì)上的隊首阻塞（其實是把多個HTTP請求放到一個TCP連接中一一發(fā)送丽啡，而在發(fā)送過程中不需要等待服務(wù)器對前一個請求的響應(yīng)硬猫；只不過，客戶端還是要按照發(fā)送請求的順序來接收響應(yīng)）坑雅。

而 HTTP/2 的流是虛擬的衬横，消息是一些有序的“幀”序列。在“連接”層面蜂林，消息是亂序收發(fā)的“幀”。多個請求/響應(yīng)之間沒有了順序關(guān)系矮锈，不需要排隊等待睁蕾，也就不會再出現(xiàn) “HTTP” 隊首阻塞的問題，降低了延遲猫缭，大幅度提高了 TCP 通道的利用率。

總的來說猜丹，HTTP/2 的二進制分幀機制解決了 HTTP 1.x 中存在隊首阻塞的問題，也消除了并行處理和發(fā)送請求及響應(yīng)時需要依賴多個 TCP 連接的方案藏杖。

Server Push

HTTP/2 還在一定程度上調(diào)整了傳統(tǒng)的”請求 - 應(yīng)答“工作模式脉顿，服務(wù)器不再是完全被動地響應(yīng)請求，也可以新建”流“主動向客戶端發(fā)送消息来吩。比如蔽莱，在瀏覽器剛請求 HTML 的時候就提前把可能用到的 JS、CSS 文件發(fā)給客戶端盗冷，減少等待的延遲，這被稱為“服務(wù)器推送”（Server Push柑司，也叫 Cache Push）锅劝。

強化安全

由于 HTTPS 在安全方面已經(jīng)做的很好了，已經(jīng)成為互聯(lián)網(wǎng)安全的趨勢讼育。而且主流的瀏覽器 Chrome稠集、Firefox 等都公開宣布只支持加密的 HTTP/2。也就是說目前在互聯(lián)網(wǎng)上能見到的 HTTP/2 都是用了 “https” 的協(xié)議名剥纷，即跑在 TLS 上面。

不過有一點要說的是晦鞋，HTTP/2 是在 2015 年開始制定標(biāo)準(zhǔn)棺克，而當(dāng)時的互聯(lián)網(wǎng)還是基于 TLS 1.2线定，此時出現(xiàn)了很多 SSL/TLS 的漏洞和弱點。而最新的 TLS 1.3 還在定制中纱皆。所以 HTTP/2 廢除了那些弱密碼套件芭商，比如 DES、RC4近迁、CBC簸州、SHA-1 等都不能在 HTTP/2 中使用。所以加密版本的 HTTP/2 在安全方面屬于做了強化搏存，要求下層的安全協(xié)議必須是 TLS 1.2 以上（相當(dāng)于 TLS 1.25 版本）助琐，還要支持前向安全和 SNI面氓。

為了區(qū)分“加密”和“明文”這兩個版本，HTTP/2 協(xié)議定義了兩個字符串標(biāo)識符：“h2” 表示加密的 HTTP/2舌界，“h2c” 表示明文的 HTTP/2呻拌，多出的那個字母 “c” 表示的是 “clear text”。

協(xié)議棧

下面我們簡要對比下 HTTP/1靴拱、HTTPS 和 HTTP/2 的協(xié)議棧猾普，如下 HTTP/2 是建立在 “HPack” “Stream” “TLS 1.2” 基礎(chǔ)之上的，比 HTTP/1初家、HTTPS 更加復(fù)雜乌助。

雖然 HTTP/2 的底層實現(xiàn)很復(fù)雜他托，但它在“語義”層面兼容了 HTTP/2仆葡，但其特性與 HTTP/2 完全不同（與 SPDY 相似）。

另外 HTTP/2 的多路復(fù)用本質(zhì)上使用的是同一條 TCP 連接登刺，改進性能的同時也解決了之前的隊首阻塞問題嗡呼。如果所有域名的請求都集中在同一條連接上，在網(wǎng)絡(luò)擁塞的時候容易出現(xiàn) TCP 隊首阻塞的問題南窗。關(guān)于這部分感興趣的朋友可以繼續(xù)學(xué)習(xí) H3 的相關(guān)內(nèi)容万伤。

最后

總的來說 HTTP/2 的目的就是通過支持請求與響應(yīng)的多路復(fù)用來減少延遲，把很多以前我們針對 HTTP/1.x 想出來的“歪招兒”一筆勾銷敌买，通過壓縮 HTTP 首部字段將協(xié)議開銷降至最低，同時增加對請求優(yōu)先級和服務(wù)器推送的支持聋庵。

實踐及應(yīng)用

雖然 H2 十分強大芙粱，不過后端在做支持時還是需要額外的改造，這個時候可以考慮在統(tǒng)一接入層做改造脱货，在接入層將數(shù)據(jù)轉(zhuǎn)換到 HTTP/1.1 再轉(zhuǎn)發(fā)到對應(yīng)域名的服務(wù)器律姨。

這樣所有的服務(wù)都不用做任何改造便可以享受到 H2 帶來的優(yōu)化。另一個是同一條 H2 連接只支持同一個域名扣孟，對于客戶端網(wǎng)絡(luò)框架來說缓淹，無論是 OkHttp 還是 Chromium 對 H2 的連接塔逃，同一個域名只會保留一條料仗。在一些需要訪問第三方請求，特別是文件下載或者視頻播放等場景可能會遇到單連限速的問題格粪。這個時候我們可以通過修改網(wǎng)絡(luò)庫實現(xiàn)氛改，也可以簡單的禁用 HTTT/2 協(xié)議來解決。

今天我們簡略介紹了 HTTP/2 的一些重要特性疆导。H2 的底層實現(xiàn)還是很復(fù)雜的葛躏，感興趣的朋友可以繼續(xù)深入學(xué)習(xí)這部分內(nèi)容。文中如有不妥或有更好的分析結(jié)果败富，歡迎您的分享留言或指正摩窃！

文章如果對你有幫助，請留個贊吧猾愿。

彩蛋-最好的網(wǎng)絡(luò)優(yōu)化

消除和減少不必要的網(wǎng)絡(luò)延遲匪蟀，把傳輸?shù)淖止?jié)數(shù)降到最少宰僧。這兩個根本問題永遠是網(wǎng)絡(luò)優(yōu)化的核心材彪，對任何應(yīng)用都有效琴儿。
最快的請求是不用請求造成，不管使用什么協(xié)議，也不管是什么類型的應(yīng)用晒屎，減少請求次數(shù)總是最好的性能優(yōu)化手段缓升。