責(zé)編：錢曙光，關(guān)注架構(gòu)和算法領(lǐng)域，尋求報道或者投稿請發(fā)郵件qianshg@csdn.net，另有「CSDN 高級架構(gòu)師群」，內(nèi)有諸多知名互聯(lián)網(wǎng)公司的大牛架構(gòu)師，歡迎架構(gòu)師加微信qshuguang2008申請入群，備注姓名+公司+職位。
　　如今確定下來的HTTP/2規(guī)格已經(jīng)引發(fā)了web性能社區(qū)的廣泛關(guān)注。新協(xié)議旨在解決老舊的HTTP/1.x協(xié)議相關(guān)的常見網(wǎng)絡(luò)性能問題，同時還要保留老協(xié)議的現(xiàn)有語義。
　　今年早些時候，我們開始針對靜態(tài)資源進(jìn)行小規(guī)模部署；在對新的基礎(chǔ)架構(gòu)建立信心后，我們開始將靜態(tài)資源全部轉(zhuǎn)向HTTP/2之上。令人驚訝的是：平臺的某些部分速度明顯變慢。本文涵蓋了我們在采用HTTP/2時，由于性能倒退而做的調(diào)查，這些故事并非web性能、特別是與HTTP/2相關(guān)的萬能靈藥，但希望我們分享的經(jīng)驗?zāi)軐Υ蠹矣兴鶐椭?br /> 　　為什么選擇HTTP/2？
　　不論怎樣，HTTP/2已經(jīng)與free performance的概念聯(lián)系起來了，它是怎樣讓我們對web性能的所有認(rèn)知都成了錯誤？
　　事實上，HTTP/2的性能只是眾多細(xì)微差別之一。
　　與針對每個資源都創(chuàng)建新連接的HTTP/1.x不同，HTTP/2在每個主機(jī)上最多只創(chuàng)建一個連接，通過使用二進(jìn)制分幀協(xié)議（binary framing protocol）的合串流（multiplexed stream）實現(xiàn)。二進(jìn)制分幀負(fù)責(zé)匹配多個并發(fā)請求，以作出回應(yīng)。
　　出自Ilya Grigorik的PPT：讓我們優(yōu)化HTTP/2
　　
　　由于不再限于每個連接處理一個事務(wù)，在很大程度上解決了隊首堵塞的問題，創(chuàng)建的連接更少也意味著延遲與TCP擁塞控制問題的減少。結(jié)合之后，由于減少了服務(wù)器與客戶端之間往返的數(shù)據(jù)量與時間，這些特性會帶來大幅的性能提升。
　　
　　監(jiān)控HTTP/2的性能
　　我們使用Calibre對終端用戶性能進(jìn)行人工監(jiān)控，同時收集不同的指標(biāo)，將這些數(shù)據(jù)的一小部分通過高可視化的Geckoboard展示在辦公室里。
　　墨爾本辦公室中，受到Etsy啟發(fā)的性能展示界面
　　
　　我們使用了下列指標(biāo)來指代用戶感知的頁面加載性能與HTTP/2成功的表現(xiàn)，選擇這些指標(biāo)的原因在于：它們會受到頁面加載生命周期中不同方面的影響。
　　DOMContentLoaded事件因同步腳本延遲；首次繪制的時間因CSS與字體等影響渲染的因素而推遲；視覺完形的時間因圖片與潛在異步腳本等不影響渲染的因素而推遲；速度指標(biāo)（Speed Index）受到視覺完形速率的影響。
　　測試并驗證HTTP/2的成功
　　我們先將圖片縮略圖CDN遷移到CloudFlare上，后者本身支持HTTP/2。初始的基準(zhǔn)測試顯示：CloudFlare的延遲與反應(yīng)時間與我們現(xiàn)有CDN的相應(yīng)指標(biāo)可堪相比。
　　作為設(shè)計類網(wǎng)站，我們的大部分頁面都是以圖片為主的，通常都會有超過50張的圖片。在HTTP/1.x中，有許多微資源的頁面會因一些小變化而造成連接延遲，從而受到不利影響。對于這些受到延遲影響的頁面，我們希望視覺完形地更快一些，至于速度有多快要取決于連接延遲與圖片數(shù)量，可以預(yù)料在高延遲、低帶寬的3G網(wǎng)絡(luò)上也會出現(xiàn)這種趨勢。
　　對于受到帶寬限制的頁面，我們希望不會出現(xiàn)明顯的變化。