此文只是方便重看，原文在：http://www.mamicode.com/info-detail-1199706.html

1.1 HTTP應用場景

http誕生之初主要是應用于web端內容獲取，那時候內容還不像現在這樣豐富，排版也沒那么精美，用戶交互的場景幾乎沒有。對于這種簡單的獲取網頁內容的場景，http表現得還算不錯。但隨著互聯網的發展和web2.0的誕生，更多的內容開始被展示（更多的圖片文件），排版變得更精美（更多的css），更復雜的交互也被引入（更多的js）。用戶打開一個網站首頁所加載的數據總量和請求的個數也在不斷增加。今天絕大部分的門戶網站首頁大小都會超過2M，請求數量可以多達100個。另一個廣泛的應用是在移動互聯網的客戶端app，不同性質的app對http的使用差異很大。對于電商類app，加載首頁的請求也可能多達10多個。對于微信這類IM，http請求可能僅限于語音和圖片文件的下載，請求出現的頻率并不算高。

1.2 因為延遲，所以慢

影響一個網絡請求的因素主要有兩個，帶寬和延遲。今天的網絡基礎建設已經使得帶寬得到極大的提升，大部分時候都是延遲在影響響應速度。http1.0被抱怨最多的就是連接無法復用，和head of line blocking這兩個問題。理解這兩個問題有一個十分重要的前提：客戶端是依據域名來向服務器建立連接，一般PC端瀏覽器會針對單個域名的server同時建立6～8個連接，手機端的連接數則一般控制在4～6個。顯然連接數并不是越多越好，資源開銷和整體延遲都會隨之增大。

連接無法復用會導致每次請求都經歷三次握手和慢啟動。三次握手在高延遲的場景下影響較明顯，慢啟動則對文件類大請求影響較大。

head of line blocking會導致帶寬無法被充分利用，以及后續健康請求被阻塞。假設有5個請求同時發出，如下圖：

[圖1] 

對于http1.0的實現，在第一個請求沒有收到回復之前，后續從應用層發出的請求只能排隊，請求2，3，4，5只能等請求1的response回來之后才能逐個發出。網絡通暢的時候性能影響不大，一旦請求1的request因為什么原因沒有抵達服務器，或者response因為網絡阻塞沒有及時返回，影響的就是所有后續請求，問題就變得比較嚴重了。

 

2. 開拓者SPDY

 

http1.0和1.1雖然存在這么多問題，業界也想出了各種優化的手段，但這些方法手段都是在嘗試繞開協議本身的缺陷，都有種隔靴搔癢，治標不治本的感覺。直到2012年google如一聲驚雷提出了SPDY的方案，大家才開始從正面看待和解決老版本http協議本身的問題，這也直接加速了http2.0的誕生。實際上，http2.0是以SPDY為原型進行討論和標準化的。為了給http2.0讓路，google已決定在2016年不再繼續支持SPDY開發，但在http2.0出生之前，SPDY已經有了相當規模的應用，作為一個過渡方案恐怕在還將一段時間內繼續存在。現在不少app客戶端和server都已經使用了SPDY來提升體驗，http2.0在老的設備和系統上還無法使用（iOS系統只有在iOS9+上才支持），所以可以預見未來幾年spdy將和http2.0共同服務的情況。

2.1 SPDY的目標

SPDY的目標在一開始就是瞄準http1.x的痛點，即延遲和安全性。我們上面通篇都在討論延遲，至于安全性，由于http是明文協議，其安全性也一直被業界詬病，不過這是另一個大的話題。如果以降低延遲為目標，應用層的http和傳輸層的tcp都是都有調整的空間，不過tcp作為更底層協議存在已達數十年之久，其實現已深植全球的網絡基礎設施當中，如果要動必然傷經動骨，業界響應度必然不高，所以SPDY的手術刀對準的是http。

• 降低延遲，客戶端的單連接單請求，server的FIFO響應隊列都是延遲的大頭。
• http最初設計都是客戶端發起請求，然后server響應，server無法主動push內容到客戶端。
• 壓縮http header，http1.x的header越來越膨脹，cookie和user agent很容易讓header的size增至1kb大小，甚至更多。而且由于http的無狀態特性，header必須每次request都重復攜帶，很浪費流量。

為了增加業界響應的可能性，聰明的google一開始就避開了從傳輸層動手，而且打算利用開源社區的力量以提高擴散的力度，對于協議使用者來說，也只需要在請求的header里設置user agent，然后在server端做好支持即可，極大的降低了部署的難度。SPDY的設計如下：

[圖6]

SPDY位于HTTP之下，TCP和SSL之上，這樣可以輕松兼容老版本的HTTP協議(將http1.x的內容封裝成一種新的frame格式)，同時可以使用已有的SSL功能。SPDY的功能可以分為基礎功能和高級功能兩部分，基礎功能默認啟用，高級功能需要手動啟用。

SPDY基礎功能

• 多路復用（multiplexing）。多路復用通過多個請求stream共享一個tcp連接的方式，解決了http1.x holb（head of line blocking）的問題，降低了延遲同時提高了帶寬的利用率。
• 請求優先級（request prioritization）。多路復用帶來一個新的問題是，在連接共享的基礎之上有可能會導致關鍵請求被阻塞。SPDY允許給每個request設置優先級，這樣重要的請求就會優先得到響應。比如瀏覽器加載首頁，首頁的html內容應該優先展示，之后才是各種靜態資源文件，腳本文件等加載，這樣可以保證用戶能第一時間看到網頁內容。
• header壓縮。前面提到過幾次http1.x的header很多時候都是重復多余的。選擇合適的壓縮算法可以減小包的大小和數量。SPDY對header的壓縮率可以達到80%以上，低帶寬環境下效果很大。

SPDY高級功能

• server推送（server push）。http1.x只能由客戶端發起請求，然后服務器被動的發送response。開啟server push之后，server通過X-Associated-Content header（X-開頭的header都屬于非標準的，自定義header）告知客戶端會有新的內容推送過來。在用戶第一次打開網站首頁的時候，server將資源主動推送過來可以極大的提升用戶體驗。
• server暗示（server hint）。和server push不同的是，server hint并不會主動推送內容，只是告訴有新的內容產生，內容的下載還是需要客戶端主動發起請求。server hint通過X-Subresources header來通知，一般應用場景是客戶端需要先查詢server狀態，然后再下載資源，可以節約一次查詢請求。

2.2 SPDY的成績

SPDY的成績可以用google官方的一個數字來說明：頁面加載時間相比于http1.x減少了64%。而且各大瀏覽器廠商在SPDY誕生之后的1年多里都陸續支持了SPDY，不少大廠app和server端框架也都將SPDY應用到了線上的產品當中。

google的官網也給出了他們自己做的一份測試數據。測試對象是25個訪問量排名靠前的網站首頁，家用網絡%1的丟包率，每個網站測試10次取平均值。結果如下：

[圖7]

不開啟ssl的時候提升在 27% - 60%，開啟之后為39% - 55%。 這份測試結果有兩點值得特別注意：

連接數的選擇

連接到底是基于域名來建立，還是不做區分所有子域名都共享一個連接，這個策略選擇上值得商榷。google的測試結果測試了兩種方案，看結果似乎是單一連接性能高于多域名連接方式。之所以出現這種情況是由于網頁所有的資源請求并不是同一時間發出，后續發出的子域名請求如果能復用之前的tcp連接當然性能更好。實際應用場景下應該也是單連接共享模式表現好。

帶寬的影響

測試基于兩種帶寬環境，一慢一快。網速快的環境下對減小延遲的提升更大，單連接模式下可以提升至60%。原因也比較簡單，帶寬越大，復用連接的請求完成越快，由于三次握手和慢啟動導致的延遲損耗就變得更明顯。

出了連接模式和帶寬之外，丟包率和RTT也是需要測試的參數。SPDY對header的壓縮有80%以上，整體包大小能減少大概40%，發送的包越少，自然受丟包率影響也就越小，所以丟包率大的惡劣環境下SPDY反而更能提升體驗。下圖是受丟包率影響的測試結果，丟包率超過2.5％之后就沒有提升了：

[圖8]

RTT越大，延遲會越大，在高RTT的場景下，由于SPDY的request是并發進行的，所有對包的利用率更高，反而能更明顯的減小總體延遲。測試結果如下：

[圖9]

SPDY從2012年誕生到2016停止維護，時間跨度對于網絡協議來說其實非常之短。如果HTTP2.0沒有出來，google或許能收集到更多業界產品的真實反饋和數據，畢竟google自己的測試環境相對簡單。但SPDY也完成了自己的使命，作為一貫扮演拓荒者角色的google應該也早就預見了這樣的結局。SPDY對產品網絡體驗的提升到底如何，恐怕只有各大廠產品經理才清楚了。

3. 救世主HTTP2.0

SPDY的誕生和表現說明了兩件事情：一是在現有互聯網設施基礎和http協議廣泛使用的前提下，是可以通過修改協議層來優化http1.x的。二是針對http1.x的修改確實效果明顯而且業界反饋很好。正是這兩點讓IETF（Internet Enginerring Task Force）開始正式考慮制定HTTP2.0的計劃，最后決定以SPDY／3為藍圖起草HTTP2.0，SPDY的部分設計人員也被邀請參與了HTTP2.0的設計。

3.1 HTTP2.0需要考慮的問題

HTTP2.0與SPDY的起點不同，SPDY可以說是google的“玩具”，最早出現在自家的chrome瀏覽器和server上，好不好玩以及別人會不會跟著一起玩對google來說無關痛癢。但HTTP2.0作為業界標準還沒出生就是眾人矚目的焦點，一開始如果有什么瑕疵或者不兼容的問題影響可能又是數十年之久，所以考慮的問題和角度要非常之廣。我們來看下HTTP2.0一些重要的設計前提：

• 客戶端向server發送request這種基本模型不會變。
• 老的scheme不會變，使用http://和https://的服務和應用不會要做任何更改，不會有http2://。
• 使用http1.x的客戶端和服務器可以無縫的通過代理方式轉接到http2.0上。
• 不識別http2.0的代理服務器可以將請求降級到http1.x。

因為客戶端和server之間在確立使用http1.x還是http2.0之前，必須要要確認對方是否支持http2.0，所以這里必須要有個協商的過程。最簡單的協商也要有一問一答，客戶端問server答，即使這種最簡單的方式也多了一個RTT的延遲，我們之所以要修改http1.x就是為了降低延遲，顯然這個RTT我們是無法接受的。google制定SPDY的時候也遇到了這個問題，他們的辦法是強制SPDY走https，在SSL層完成這個協商過程。ssl層的協商在http協議通信之前，所以是最適合的載體。google為此做了一個tls的拓展，叫NPN（Next Protocol Negotiation），從名字上也可以看出，這個拓展主要目的就是為了協商下一個要使用的協議。HTTP2.0雖然也采用了相同的方式，不過HTTP2.0經過激烈的討論，最終還是沒有強制HTTP2.0要走ssl層，大部分瀏覽器廠商（除了IE）卻只實現了基于https的2.0協議。HTTP2.0沒有使用NPN，而是另一個tls的拓展叫ALPN（Application Layer Protocol Negotiation）。SPDY也打算從NPN遷移到ALPN了。

各瀏覽器（除了IE）之所以只實現了基于SSL的HTTP2.0，另一個原因是走SSL請求的成功率會更高，被SSL封裝的request不會被監聽和修改，這樣網絡中間的網絡設備就無法基于http1.x的認知去干涉修改request，http2.0的request如果被意外的修改，請求的成功率自然會下降。

HTTP2.0協議沒有強制使用SSL是因為聽到了很多的反對聲音，畢竟https和http相比，在不優化的前提下性能差了不少，要把https優化到幾乎不增加延遲的程度又需要花費不少力氣。IETF面對這種兩難的處境做了妥協，但大部分瀏覽器廠商（除了IE）并不買帳，他們只認https2.0。對于app開發者來說，他們可以堅持使用沒有ssl的http2.0，不過要承擔一個多余的RTT延遲和請求可能被破壞的代價。

3.1 HTTP2.0主要改動

HTTP2.0作為新版協議，改動細節必然很多，不過對應用開發者和服務提供商來說，影響較大的就幾點。

新的二進制格式（Binary Format）

http1.x誕生的時候是明文協議，其格式由三部分組成：start line（request line或者status line），header，body。要識別這3部分就要做協議解析，http1.x的解析是基于文本。基于文本協議的格式解析存在天然缺陷，文本的表現形式有多樣性，要做到健壯性考慮的場景必然很多，二進制則不同，只認0和1的組合。基于這種考慮http2.0的協議解析決定采用二進制格式，實現方便且健壯。

有人可能會覺得基于文本的http調試方便很多，像firebug，chrome，charles等不少工具都可以即時調試修改請求。實際上現在很多請求都是走https了，要調試https請求必須有私鑰才行。http2.0的絕大部分request應該都是走https，所以調試方便無法作為一個有力的考慮因素了。curl，tcpdump，wireshark這些工具會更適合http2.0的調試。

http2.0用binary格式定義了一個一個的frame，和http1.x的格式對比如下圖：

[圖10]

http2.0的格式定義更接近tcp層的方式，這張二機制的方式十分高效且精簡。length定義了整個frame的開始到結束，type定義frame的類型（一共10種），flags用bit位定義一些重要的參數，stream id用作流控制，剩下的payload就是request的正文了。

雖然看上去協議的格式和http1.x完全不同了，實際上http2.0并沒有改變http1.x的語義，只是把原來http1.x的header和body部分用frame重新封裝了一層而已。調試的時候瀏覽器甚至會把http2.0的frame自動還原成http1.x的格式。具體的協議關系可以用下圖表示：

[圖11]

連接共享

http2.0要解決的一大難題就是多路復用（MultiPlexing），即連接共享。上面協議解析中提到的stream id就是用作連接共享機制的。一個request對應一個stream并分配一個id，這樣一個連接上可以有多個stream，每個stream的frame可以隨機的混雜在一起，接收方可以根據stream id將frame再歸屬到各自不同的request里面。

前面還提到過連接共享之后，需要優先級和請求依賴的機制配合才能解決關鍵請求被阻塞的問題。http2.0里的每個stream都可以設置又優先級（Priority）和依賴（Dependency）。優先級高的stream會被server優先處理和返回給客戶端，stream還可以依賴其它的sub streams。優先級和依賴都是可以動態調整的。動態調整在有些場景下很有用，假想用戶在用你的app瀏覽商品的時候，快速的滑動到了商品列表的底部，但前面的請求先發出，如果不把后面的請求優先級設高，用戶當前瀏覽的圖片要到最后才能下載完成，顯然體驗沒有設置優先級好。同理依賴在有些場景下也有妙用。

header壓縮

前面提到過http1.x的header由于cookie和user agent很容易膨脹，而且每次都要重復發送。http2.0使用encoder來減少需要傳輸的header大小，通訊雙方各自cache一份header fields表，既避免了重復header的傳輸，又減小了需要傳輸的大小。高效的壓縮算法可以很大的壓縮header，減少發送包的數量從而降低延遲。

這里普及一個小知識點。現在大家都知道tcp有slow start的特性，三次握手之后開始發送tcp segment，第一次能發送的沒有被ack的segment數量是由initial tcp window大小決定的。這個initial tcp window根據平臺的實現會有差異，但一般是2個segment或者是4k的大小（一個segment大概是1500個字節），也就是說當你發送的包大小超過這個值的時候，要等前面的包被ack之后才能發送后續的包，顯然這種情況下延遲更高。intial window也并不是越大越好，太大會導致網絡節點的阻塞，丟包率就會增加，具體細節可以參考IETF這篇文章。http的header現在膨脹到有可能會超過這個intial window的值了，所以更顯得壓縮header的重要性。

壓縮算法的選擇

SPDY/2使用的是gzip壓縮算法，但后來出現的兩種攻擊方式BREACH和CRIME使得即使走ssl的SPDY也可以被破解內容，最后綜合考慮采用的是一種叫HPACK的壓縮算法。這兩個漏洞和相關算法可以點擊鏈接查看更多的細節，不過這種漏洞主要存在于瀏覽器端，因為需要通過javascript來注入內容并觀察payload的變化。

重置連接表現更好

很多app客戶端都有取消圖片下載的功能場景，對于http1.x來說，是通過設置tcp segment里的reset flag來通知對端關閉連接的。這種方式會直接斷開連接，下次再發請求就必須重新建立連接。http2.0引入RST_STREAM類型的frame，可以在不斷開連接的前提下取消某個request的stream，表現更好。

Server Push

Server Push的功能前面已經提到過，http2.0能通過push的方式將客戶端需要的內容預先推送過去，所以也叫“cache push”。另外有一點值得注意的是，客戶端如果退出某個業務場景，出于流量或者其它因素需要取消server push，也可以通過發送RST_STREAM類型的frame來做到。

流量控制（Flow Control）

TCP協議通過sliding window的算法來做流量控制。發送方有個sending window，接收方有receive window。http2.0的flow control是類似receive window的做法，數據的接收方通過告知對方自己的flow window大小表明自己還能接收多少數據。只有Data類型的frame才有flow control的功能。對于flow control，如果接收方在flow window為零的情況下依然更多的frame，則會返回block類型的frame，這張場景一般表明http2.0的部署出了問題。

Nagle Algorithm vs TCP Delayed Ack

tcp協議優化的一個經典場景是：Nagle算法和Berkeley的delayed ack算法的對立。http2.0并沒有對tcp層做任何修改，所以這種對立導致的高延遲問題依然存在。要么通過TCP_NODELAY禁用Nagle算法，要么通過TCP_QUICKACK禁用delayed ack算法。貌似http2.0官方建議是設置TCP_NODELAY。

更安全的SSL

HTTP2.0使用了tls的拓展ALPN來做協議升級，除此之外加密這塊還有一個改動，HTTP2.0對tls的安全性做了近一步加強，通過黑名單機制禁用了幾百種不再安全的加密算法，一些加密算法可能還在被繼續使用。如果在ssl協商過程當中，客戶端和server的cipher suite沒有交集，直接就會導致協商失敗，從而請求失敗。在server端部署http2.0的時候要特別注意這一點。

3.2 HTTP2.0里的負能量

SPDY和HTTP2.0之間的曖昧關系，以及google作為SPDY的創造者，這兩點很容易讓陰謀論者懷疑google是否會成為協議的最終收益方。這其實是廢話，google當然會受益，任何新協議使用者都會從中受益，至于誰吃肉，誰喝湯看的是自己的本事。從整個協議的變遷史也可以粗略看出，新協議的誕生完全是針對業界現存問題對癥下藥，并沒有google業務相關的痕跡存在，google至始至終只扮演了一個角色：you can you up。

HTTP2.0不會是萬金油，但抹了也不會有副作用。HTTP2.0最大的亮點在于多路復用，而多路復用的好處只有在http請求量大的場景下才明顯，所以有人會覺得只適用于瀏覽器瀏覽大型站點的時候。這么說其實沒錯，但http2.0的好處不僅僅是multiplexing，請求壓縮，優先級控制，server push等等都是亮點。對于內容型移動端app來說，比如淘寶app，http請求量大，多路復用還是能產生明顯的體驗提升。多路復用對延遲的改變可以參考下這個測試網址。

HTTP2.0對于ssl的依賴使得有些開發者望而生畏。不少開發者對ssl還停留在高延遲，CPU性能損耗，配置麻煩的印象中。其實ssl于http結合對性能的影響已經可以優化到忽略的程度了，網上也有不少文章可以參考。HTTP2.0也可以不走ssl，有些場景確實可能不適合https，比如對代理服務器的cache依賴，對于內容安全性不敏感的get請求可以通過代理服務器緩存來優化體驗。

3.3 HTTP2.0的現狀

HTTP2.0作為新版本的網絡協議肯定需要一段時間去普及，但HTTP本身屬于應用層協議，和當年的網絡層協議IPV6不同，離底層協議越遠，對網絡基礎硬件設施的影響就越小。HTTP2.0甚至還特意的考慮了與HTTP1.x的兼容問題，只是在HTTP1.x的下面做了一層framing layer，更使得其普及的阻力變小。所以不出意外，HTTP2.0的普及速度可能會遠超大部分人的預期。

Firefox 2015年在其瀏覽器流量中檢測到，有13%的http流量已經使用了http2.0，27%的https也是http2.0，而且還處于持續的增長當中。一般用戶察覺不到是否使用了http2.0，不過可以裝這樣一個插件，安裝之后如果網站是http2.0的，在地址欄的最右邊會有個閃電圖標。還可以使用這個網站來測試。對于開發者來說，可以通過Web Developer的Network來查看協議細節，如下圖：

[圖12]

其中Version：HTTP／2.0已經很明確表明協議類型，Firefox還在header里面插入了X-Firefox-Spdy:“h2”，也可以看出是否使用http2.0。

Chrome在2015年檢測到的http2.0流量大概有18%。不過這個數字本來會更高，因為Chrome現在很大一部分流量都在試驗QUIC（google正在開辟的另一塊疆土）。Chrome上也可以使用類似的插件來判斷網站是否是使用http2.0。