背景
這篇文檔會(huì)從技術(shù)和協(xié)議層面來(lái)介紹http2。文檔起源于2014年4月我在斯德哥爾摩做了一次相關(guān)的演講，在那之后我對(duì)演講內(nèi)容的細(xì)節(jié)進(jìn)行了一些解釋和補(bǔ)充，從而寫出了這篇文檔。
正式版http2規(guī)格標(biāo)準(zhǔn)叫做RFC 7540睬关，發(fā)布于2015年5月15日：http://www.rfc- editor.org/rfc/rfc7540.txt 如果你有在這篇文章中發(fā)現(xiàn)任何我的失誤造成的錯(cuò)誤或疏漏，請(qǐng)幫我指正毡证。我會(huì)在后續(xù)版本 中修改电爹。
為了讓閱讀體驗(yàn)更流暢，在這篇文章中我會(huì)使用“http2”來(lái)指代這一新協(xié)議料睛，但請(qǐng)記住該協(xié)議的正式名字是HTTP/2丐箩。HTTP的現(xiàn)狀
當(dāng)前，幾乎所有互聯(lián)網(wǎng)上的內(nèi)容都采用HTTP 1.1作為通信協(xié)議恤煞。人們?cè)谠搮f(xié)議上投入了大量精力屎勘，因此基于該協(xié)議的基礎(chǔ)架構(gòu)得以日臻完善。得益于此阱州，在現(xiàn)有的HTTP協(xié)議之上構(gòu)建新的方案會(huì)比從底層建立新的協(xié)議要容易得多。
2.1 HTTP 1.1過(guò)于龐大
HTTP剛誕生的時(shí)候被看作一個(gè)相對(duì)簡(jiǎn)單直觀的協(xié)議法梯，但時(shí)間證明了早期的設(shè)計(jì)并不盡人意苔货。 于1996年發(fā)布的、描述HTTP 1.0規(guī)范的RFC 1945只有60頁(yè)立哑，但僅僅3年之后夜惭，描述HTTP1.1規(guī)范的RFC 2616就驟增至176頁(yè)。當(dāng)我們?cè)贗ETF小組對(duì)該規(guī)范進(jìn)行更新時(shí)铛绰，更是被拆分成了總頁(yè)數(shù)更多的六個(gè)文檔（這就是RFC 7230及其文件族的由來(lái)與誕生）诈茧。總而言之捂掰，HTTP1.1包含了太多細(xì)節(jié)和可選內(nèi)容敢会，這讓它變得過(guò)于龐大。
2.2 過(guò)多的可選項(xiàng)
HTTP 1.1不僅包含了非常多的細(xì)枝末節(jié)这嚣，也為未來(lái)的擴(kuò)展預(yù)留了很多選項(xiàng)鸥昏。這種事無(wú)巨細(xì)的風(fēng)格導(dǎo)致在現(xiàn)有的軟件生態(tài)中，幾乎沒有任何實(shí)際場(chǎng)景真正實(shí)現(xiàn)了協(xié)議中提及的所有細(xì)節(jié)姐帚， 甚至要弄清楚“所有細(xì)節(jié)”到底包括哪些內(nèi)容都非常困難吏垮。這也導(dǎo)致了很多最初不常用的功能在后來(lái)的實(shí)現(xiàn)中得到很少支持，而有些最初實(shí)現(xiàn)了的功能，卻又很少被使用膳汪。
隨著時(shí)間推移唯蝶，當(dāng)客戶端和服務(wù)器開始增加對(duì)于這些功能的使用時(shí)，**互用性
** （interoperability）問(wèn)題就暴露了出來(lái)遗嗽。HTTP管線化（HTTP Pipelining）就是一個(gè)非常好的例子粘我。
2.3 未能被充分利用的TCP
HTTP 1.1很難完全使用出TCP協(xié)議能提供的所有強(qiáng)大能力。HTTP客戶端和瀏覽器必須要另辟蹊徑媳谁，去尋找新的解決方案來(lái)降低頁(yè)面載入時(shí)間涂滴。
與此同時(shí)，人們也嘗試使用新的協(xié)議來(lái)替代TCP晴音，但結(jié)果證明這也非常困難柔纵。無(wú)奈之下，我 們只能嘗試同時(shí)改進(jìn)TCP協(xié)議本身和基于TCP的上層協(xié)議锤躁。
簡(jiǎn)單來(lái)說(shuō)搁料，我們可以通過(guò)更好的利用TCP來(lái)減少傳輸過(guò)程中的中斷，并充分挖掘利用那些本 可以用于發(fā)送/接受更多數(shù)據(jù)的時(shí)間系羞。下面幾段我們將會(huì)著重討論這些問(wèn)題郭计。
2.4 傳輸大小和資源數(shù)量
如果仔細(xì)觀察那些最流行的網(wǎng)站首頁(yè)所需要下載的資源，會(huì)發(fā)現(xiàn)一個(gè)非常明顯的趨勢(shì)椒振。近年 來(lái)加載網(wǎng)站首頁(yè)接受的數(shù)據(jù)量在逐漸增加昭伸，并已經(jīng)超過(guò)了1.9MB。但更重要的是：平均每個(gè)頁(yè)面為了完成渲染需要加載超過(guò)100個(gè)獨(dú)立資源澎迎。
正如下圖所示庐杨，這種趨勢(shì)已經(jīng)持續(xù)了很長(zhǎng)一段時(shí)間，并且沒有減緩的跡象夹供。該圖表中綠色直 線展示了傳輸數(shù)據(jù)大小的增長(zhǎng)灵份，紅色直線展示了平均請(qǐng)求資源數(shù)量的增長(zhǎng)。
- {failImgCache = [];}if(failImgCache.indexOf(src) == -1 && src.trim().length){failImgCache.push(src);}$(this).closest('.md-image').addClass('md-img-error').removeClass('md-img-loaded');" onload="var src = window.removeLastModifyQuery(this.getAttribute('src'));if(!src.trim()) return;if(loadedImgCache.indexOf(src) == -1 && src.trim().length){loadedImgCache.push(src);}$(this).closest('.md-image').addClass('md-img-loaded').removeClass('md-img-error');" style="box-sizing: border-box; border-width: 0px 4px 0px 2px; border-right-style: solid; border-left-style: solid; border-right-color: transparent; border-left-color: transparent; vertical-align: middle; max-width: 100%; cursor: default;">
2.5 惱人的延遲
HTTP 1.1對(duì)網(wǎng)絡(luò)延遲非常敏感哮洽。部分原因是HTTP Pipelining還存有很多問(wèn)題填渠，所以對(duì)大部分用戶來(lái)說(shuō)這項(xiàng)技術(shù)是被默認(rèn)關(guān)閉的。 - {failImgCache = [];}if(failImgCache.indexOf(src) == -1 && src.trim().length){failImgCache.push(src);}$(this).closest('.md-image').addClass('md-img-error').removeClass('md-img-loaded');" onload="var src = window.removeLastModifyQuery(this.getAttribute('src'));if(!src.trim()) return;if(loadedImgCache.indexOf(src) == -1 && src.trim().length){loadedImgCache.push(src);}$(this).closest('.md-image').addClass('md-img-loaded').removeClass('md-img-error');" style="box-sizing: border-box; border-width: 0px 4px 0px 2px; border-right-style: solid; border-left-style: solid; border-right-color: transparent; border-left-color: transparent; vertical-align: middle; max-width: 100%; cursor: default;">
HTTP 1.1對(duì)網(wǎng)絡(luò)延遲非常敏感鸟辅。部分原因是HTTP Pipelining還存有很多問(wèn)題氛什，所以對(duì)大部分用戶來(lái)說(shuō)這項(xiàng)技術(shù)是被默認(rèn)關(guān)閉的。
雖然近幾年來(lái)網(wǎng)絡(luò)帶寬增長(zhǎng)非撤肆梗快屉更，然而我們卻并沒有看到網(wǎng)絡(luò)延遲有對(duì)應(yīng)程度的降低。在 高延遲的網(wǎng)絡(luò)環(huán)境中（比如移動(dòng)設(shè)備）洒缀，即使擁有高連接速率瑰谜，也很難獲得優(yōu)質(zhì)快速的網(wǎng)絡(luò) 體驗(yàn)欺冀。
另外一個(gè)需要低延遲的場(chǎng)景是某些視頻服務(wù)，如視頻會(huì)議萨脑、游戲和其它類似無(wú)法預(yù)先發(fā)送資 源請(qǐng)求的情況隐轩。
2.6 線頭阻塞（Head of line blocking）
HTTP Pipelining是這樣一種技術(shù)：在等待上一個(gè)請(qǐng)求響應(yīng)的同時(shí)，發(fā)送下一個(gè)請(qǐng)求渤早。(譯者 注：作者這個(gè)解釋并不完全正確职车，HTTP Pipelining其實(shí)是把多個(gè)HTTP請(qǐng)求放到一個(gè)TCP連接 中一一發(fā)送，而在發(fā)送過(guò)程中不需要等待服務(wù)器對(duì)前一個(gè)請(qǐng)求的響應(yīng)鹊杖；只不過(guò)悴灵，客戶端還是 要按照發(fā)送請(qǐng)求的順序來(lái)接收響應(yīng)。)但就像在超市收銀臺(tái)或者銀行柜臺(tái)排隊(duì)時(shí)一樣骂蓖，你并不 知道前面的顧客是干脆利索的還是會(huì)跟收銀員/柜員磨蹭到世界末日（譯者注：不管怎么說(shuō)积瞒， 服務(wù)器（即收銀員/柜員）是要按照順序處理請(qǐng)求的，如果前一個(gè)請(qǐng)求非常耗時(shí)（顧客磨 蹭）登下，那么后續(xù)請(qǐng)求都會(huì)受到影響）茫孔，這就是所謂的**線頭阻塞（Head of line blocking）
**
當(dāng)然，你可以在選擇隊(duì)伍時(shí)就做足準(zhǔn)備被芳，去排一個(gè)你認(rèn)為最快的隊(duì)伍缰贝，或者甚至另起一個(gè)新 的隊(duì)伍（譯者注：即新建一個(gè)TCP連接）。但不管怎么樣畔濒，你總歸得先選擇一個(gè)隊(duì)伍剩晴，而且 一旦選定之后，就不能更換隊(duì)伍侵状。
但是赞弥，另起新隊(duì)伍會(huì)導(dǎo)致資源耗費(fèi)和性能損失（譯者注：新建 TCP 連接的開銷非常大）。這種另起新隊(duì)伍的方式只在新隊(duì)伍數(shù)量很少的情況下有作用壹将，因此它并不具備可擴(kuò)展性嗤攻。（譯者注：這段話意思是說(shuō)毛嫉，靠大量新建連接是不能有效解決延遲問(wèn)題的诽俯，即HTTP Pipelining并不能徹底解決Head of line blocking問(wèn)題。）所以針對(duì)此問(wèn)題并沒有完美的解決方案承粤。
這就是為什么暴区，即使在2015年的今天，大部分桌面瀏覽器仍然會(huì)選擇默認(rèn)關(guān)閉HTTP pipelining這一功能的原因辛臊。
3 那些年仙粱，克服延遲之道
再困難的問(wèn)題也有解決的方案，但這些方案卻良莠不齊彻舰。
3.1 Spriting
Spriting是一種將很多較小的圖片合并成一張大圖伐割，再用JavaScript或者CSS將小圖重新“切 割”出來(lái)的技術(shù)候味。
網(wǎng)站可以利用這一技巧來(lái)達(dá)到提速的目的——在HTTP 1.1里，下載一張大圖比下載100張小圖 快得多隔心。
但是當(dāng)某些頁(yè)面只需要顯示其中幾張小圖時(shí)白群，這種方案的缺點(diǎn)就凸顯出來(lái)了：它必須將整張 大圖都從cache里取出，而不能將最頻繁使用的那些圖片保留在cache里硬霍。
3.2 內(nèi)聯(lián)（Inlining）
Inlining是另外一種防止發(fā)送很多小圖請(qǐng)求的技巧帜慢，它將圖片的原始數(shù)據(jù)嵌入在CSS文件里面 的URL里。而這種方案的優(yōu)缺點(diǎn)跟Spriting很類似唯卖。
.icon1 {
background: url(data:image/png;base64,<data>) no-repeat;
}
.icon2 {
background: url(data:image/png;base64,<data>) no-repeat;
}
10 那些年粱玲，克服延遲之道
3.3 拼接（Concatenation）
大型網(wǎng)站往往會(huì)包含大量的JavaScript文件。一些前端工具可以幫助開發(fā)人員將這些文件合并 為一個(gè)大的文件拜轨，從而讓瀏覽器能只花費(fèi)一個(gè)請(qǐng)求就將其下載完抽减，而不是發(fā)無(wú)數(shù)請(qǐng)求去分別 下載那些瑣碎的JavaScript文件。但凡事往往有利有弊撩轰，如果某頁(yè)面只需要其中一小部分代 碼胯甩，它也必須下載完整的那份；而文件中一個(gè)小小的改動(dòng)也會(huì)造成大量數(shù)據(jù)的被重新下載堪嫂。
這種方案也給開發(fā)者造成了很大的不便偎箫。
3.4 分片（Sharding）
最后一個(gè)我要說(shuō)的性能優(yōu)化技術(shù)叫做Sharding。顧名思義皆串，Sharding就是把你的服務(wù)分散在 盡可能多的主機(jī)上淹办。這種方案乍一聽比較奇怪，但是實(shí)際上在這背后卻蘊(yùn)藏了它獨(dú)辟蹊徑的 道理恶复！
最初的HTTP 1.1規(guī)范提到一個(gè)客戶端最多只能對(duì)同一主機(jī)建立兩個(gè)TCP連接怜森。因此，為了不 和規(guī)范沖突谤牡，一些聰明的網(wǎng)站使用了新的主機(jī)名副硅，這樣的話，用戶就能和網(wǎng)站建立更多的連 接翅萤，從而降低載入時(shí)間恐疲。
后來(lái)，兩個(gè)連接的限制被取消了套么，現(xiàn)在的客戶端可以輕松地和每個(gè)主機(jī)建立6-8個(gè)連接培己。但由 于連接的上限依然存在，所以網(wǎng)站還是會(huì)用這種技術(shù)來(lái)提升連接的數(shù)量胚泌。而隨著資源個(gè)數(shù)的 提升（上面章節(jié)的圖例）省咨，網(wǎng)站會(huì)需要更多的連接來(lái)保證HTTP協(xié)議的效率，從而提升載入速 度玷室。在現(xiàn)今的網(wǎng)站上零蓉，使用50甚至100個(gè)連接來(lái)打開一個(gè)頁(yè)面已經(jīng)并不罕見笤受。根 據(jù)httparchive.org的最新記錄顯示，在Top 30萬(wàn)個(gè)URL中平均使用40（５蟹洹）個(gè)TCP連接來(lái)顯示 頁(yè)面感论，而且這個(gè)數(shù)字仍然在緩慢的增長(zhǎng)中。
另外一個(gè)將圖片或者其他資源分發(fā)到不同主機(jī)的理由是可以不使用cookies紊册，畢竟現(xiàn)今cookies 的大小已經(jīng)非潮纫蓿可觀了。無(wú)cookies的圖片服務(wù)器往往意味著更小的HTTP請(qǐng)求以及更好的性 能囊陡！
下面的圖片展示了訪問(wèn)一個(gè)瑞典著名網(wǎng)站的時(shí)產(chǎn)生的數(shù)據(jù)包芳绩，請(qǐng)注意這些請(qǐng)求是如何被分發(fā) 到不同主機(jī)的。
