前面的文章也提到了目前的移動端網(wǎng)絡(luò)常見性能問題，以及對應(yīng)的優(yōu)化策略，如果把HTTP1.1 替換為 HTTP2.0，可以說是網(wǎng)絡(luò)性能優(yōu)化的一步大棋。這幾天對 iOS HTTP2.0 進(jìn)行了簡單的調(diào)研、測試，在此做個簡單的總結(jié)

　　本文的大概思路是介紹 HTTP1.1 的弊端、HTTP2.0 的優(yōu)勢、HTTP2.0 的協(xié)商機(jī)制、iOS 客戶端如何接入 HTTP2.0，以及如何對其進(jìn)行調(diào)試。主要還是加深記憶、方便后期查閱，文末的資料相比本文或許是更有價值的。

　　HTTP 1.1

　　雖然 HTTP1.1 默認(rèn)是開啟 Keep-Alive 長連接的，一定程度上彌補(bǔ)了HTTP1.0每次請求都要創(chuàng)建連接的缺點(diǎn)，但是依然存在 head of line blocking，如果出現(xiàn)一個較差的網(wǎng)絡(luò)請求，會影響后續(xù)的網(wǎng)絡(luò)請求。為什么呢？如果你發(fā)出1、2、3 三個網(wǎng)絡(luò)請求，那么 Response 的順序 2、3 要在第一個網(wǎng)絡(luò)請求之后，以此類推

　　針對同一域名，在請求較多的情況下，HTTP1.1 會開辟多個連接，據(jù)說瀏覽器一般是6-8 個，較多連接也會導(dǎo)致延遲增大，資源消耗等問題

　　HTTP1.1 不安全，可能存在被篡改、被竊聽、被偽裝等問題。當(dāng)然，前陣子 Apple 推廣 HTTPS 的時候，相信很多人已經(jīng)接入 HTTPS

　　HTTP 的頭部沒有壓縮，header 的大小也是傳輸?shù)呢?fù)擔(dān)，帶來更多的流量消耗和傳輸延遲。并且很多 header 是相同的，重復(fù)傳輸是沒有必要的。

　　服務(wù)端無法主動推送資源到客戶端

　　HTTP1.1的格式是文本格式，基于文本做一些擴(kuò)展、優(yōu)化相對比較困難，但是文本格式易于閱讀和調(diào)試，但HTTPS之后，也變成二進(jìn)制格式了，這個優(yōu)勢也不復(fù)存在

　　HTTP 2.0

　　在 HTTP2.0中，上面的問題幾乎都不存在了。HTTP2.0 的設(shè)計來源于 Google 的 SPDY 協(xié)議，如果對 SPDY 協(xié)議不了解的話，也可以先對 SPDY 進(jìn)行了解，不過這不影響繼續(xù)閱讀本文

　　HTTP 2.0 使用新的二進(jìn)制格式：基本的協(xié)議單位是幀，每個幀都有不同的類型和用途，規(guī)范中定義了10種不同的幀。例如，報頭（HEADERS）和數(shù)據(jù)（DATA）幀組成了基本的HTTP 請求和響應(yīng)；其他幀例如 設(shè)置（SETTINGS），窗口更新（WINDOW_UPDATE）， 和推送承諾（PUSH_PROMISE）是用來實現(xiàn)HTTP/2的其他功能。那些請求和響應(yīng)的幀數(shù)據(jù)通過流來進(jìn)行數(shù)據(jù)交換。新的二進(jìn)制格式是流量控制、優(yōu)先級、server push等功能的基礎(chǔ)

　　流（Stream）：一個Stream是包含一條或多條信息、ID和優(yōu)先級的雙向通道

　　消息（Message）：消息由幀組成

　　幀（Frame）：幀有不同的類型，并且是混合的。他們通過stream id被重新組裝進(jìn)消息中

　　多路復(fù)用：也就是連接共享，剛才說到 HTTP1.1的 head of line blocking，那么在多路復(fù)用的情況下，blocking 已經(jīng)不存在了。每個連接中 可以包含多個流，而每個流中交錯包含著來自兩端的幀。也就是說同一個連接中是來自不同流的數(shù)據(jù)包混合在一起，如下圖所示，每一塊代表幀，而相同顏色塊來自同一個流，每個流都有自己的 ID，在接收端會根據(jù) ID 進(jìn)行重裝組合，就是通過這樣一種方式來實現(xiàn)多路復(fù)用。