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

分享之前我還是要推薦下我自己建的iOS開發(fā)學(xué)習(xí)群：680565220儡司，群里都是學(xué)ios開發(fā)的娱挨，如果你正在學(xué)習(xí)ios ，小編歡迎你加入捕犬，今天分享的這個(gè)案例已經(jīng)上傳到群文件跷坝，大家都是軟件開發(fā)黨，不定期分享干貨（只有iOS軟件開發(fā)相關(guān)的）碉碉，包括我自己整理的一份2017最新的iOS進(jìn)階資料和高級(jí)開發(fā)教程柴钻，歡迎進(jìn)階中和進(jìn)想深入iOS的小伙伴。

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

HTTP 1.1

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

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

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

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

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

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

HTTP2.0

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

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

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

消息(Message)：消息由幀組成

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

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

單一連接：剛才也說到 1.1 在請(qǐng)求多的時(shí)候，會(huì)開啟6-8個(gè)連接录平，而 HTTP2 只會(huì)開啟一個(gè)連接麻车，這樣就減少握手帶來的延遲。

頭部壓縮：HTTP2.0 通過 HPACK 格式來壓縮頭部斗这，使用了哈夫曼編碼壓縮动猬、索引表來對(duì)頭部大小做優(yōu)化。索引表是把字符串和數(shù)字之間做一個(gè)匹配表箭，比如method: GET對(duì)應(yīng)索引表中的2赁咙，那么如果之前發(fā)送過這個(gè)值是，就會(huì)緩存起來免钻，之后使用時(shí)發(fā)現(xiàn)之前發(fā)送過該Header字段彼水，并且值相同，就會(huì)沿用之前的索引來指代那個(gè)Header值极舔。具體實(shí)驗(yàn)數(shù)據(jù)可以參考這里：HTTP/2 頭部壓縮技術(shù)介紹

Server Push：就是服務(wù)端可以主動(dòng)推送一些東西給客戶端凤覆，也被稱為緩存推送。推送的資源可以備客戶端日后之需姆怪，需要的時(shí)候直接拿出來用叛赚，提升了速率。具體的實(shí)驗(yàn)可以參考這里：iOS HTTP/2 Server Push 探索

除了上面講到的特性稽揭，HTTP2.0 還有流量控制俺附、流優(yōu)先級(jí)和依賴性等功能。更多細(xì)節(jié)可以參考：Hypertext Transfer Protocol Version 2 (HTTP/2)

iOS 客戶端接入HTTP 2.0

iOS 如何接入 HTTP 2.0呢溪掀？其實(shí)很簡單：

保證服務(wù)端支持 HTTP2.0事镣，并且留意下 NPN 或 ALPN

客戶端系統(tǒng)版本 iOS 9 +

使用 NSURLSession 代替 NSURLConnection

客戶端是使用 h2c 還是 h2，它們可以說是 HTTP2.0的兩個(gè)版本揪胃，h2 是使用 TLS 的HTTP2.0協(xié)議璃哟，h2c是運(yùn)行在明文 TCP 協(xié)議上的 HTTP2.0協(xié)議。瀏覽器目前只支持h2喊递，也就是說必須基于HTTPS部署随闪，但是客戶端可以不部署HTTPS，因?yàn)槲宜驹缫巡渴餒TTPS骚勘，所以我這里的實(shí)踐都是基于h2的

HTTP 2.0的協(xié)商機(jī)制

上面說了一堆名次铐伴，什么NPN撮奏、ALPN呀，還有h2当宴、h2c之類的畜吊，有點(diǎn)懵逼。NPN（Next Protocol Negotiation）是一個(gè) TLS 擴(kuò)展户矢，由 Google 在開發(fā) SPDY 協(xié)議時(shí)提出玲献。隨著 SPDY 被 HTTP/2 取代，NPN 也被修訂為 ALPN（Application Layer Protocol Negotiation梯浪，應(yīng)用層協(xié)議協(xié)商）捌年。二者目標(biāo)一致，但實(shí)現(xiàn)細(xì)節(jié)不一樣驱证，相互不兼容延窜。以下是它們主要差別：

NPN 是服務(wù)端發(fā)送所支持的 HTTP 協(xié)議列表，由客戶端選擇抹锄；而 ALPN 是客戶端發(fā)送所支持的 HTTP 協(xié)議列表，由服務(wù)端選擇荠藤；

NPN 的協(xié)商結(jié)果是在 Change Cipher Spec 之后加密發(fā)送給服務(wù)端伙单；而 ALPN 的協(xié)商結(jié)果是通過 Server Hello 明文發(fā)給客戶端

同時(shí)，目前很多地方開始停止對(duì)NPN的支持哈肖，僅支持 ALPN吻育，所以公司使用的話，最佳是直接使用 ALPN淤井。

下面就直接來看看 ALPN 的協(xié)商過程是怎樣的布疼，ALPN 作為 TLS 的一個(gè)擴(kuò)展，其過程可以通過 WireShark 查看 TLS握手過程來查看

下面通過 WireShark 來進(jìn)行調(diào)試币狠，接入真機(jī)游两，然后終端輸入

rvictl -s 設(shè)備 UDID來創(chuàng)建一個(gè)映射到 iPhone 的虛擬網(wǎng)卡，UUID 可以在 iTunes 中獲取到漩绵，運(yùn)行命令后會(huì)看到成功創(chuàng)建 rvi0 虛擬網(wǎng)卡的贱案，雙擊 rvi0 開始調(diào)試。

進(jìn)入之后止吐，在手機(jī)上訪問頁面會(huì)有源源不斷的請(qǐng)求顯示在 WireShark 的界面上宝踪，數(shù)據(jù)太多而不利于我們針對(duì)性調(diào)試，你可以過濾下域名碍扔，只關(guān)注你想測試的 ip 地址瘩燥，比如： ip.addr==111.89.211.191 ，當(dāng)然你的 ip 要支持 HTTP2.0才會(huì)有預(yù)想的效果哦

下面不同，就開始通過查看 TLS 握手的過程分析HTTP2.0 的協(xié)商過程厉膀，剛才也說道 ALPN 協(xié)商結(jié)果是在 Client hello 和 Server hello 中顯示的，那就先來看一下Client hello

可以看到客戶端在 Client hello 中列出了自己支持的各種應(yīng)用層協(xié)議，比如 spdy3站蝠、h2汰具。那么接著看 Server hello 是如何回復(fù)的

服務(wù)端會(huì)根據(jù) client hello 中的協(xié)議列表，發(fā)過去自己支持的網(wǎng)絡(luò)協(xié)議菱魔，假如服務(wù)端支持 h2留荔，則直接返回h2，協(xié)商成功澜倦，如果不支持 h2聚蝶，則返回一個(gè)其他支持的協(xié)議，比如HTTP1.1藻治、spdy3

這個(gè)是h2的協(xié)商過程碘勉，對(duì)于剛才提到的 h2c 的協(xié)商過程，與此不同桩卵，h2c 利用的是HTTP Upgrade 機(jī)制验靡，客戶端會(huì)發(fā)送一個(gè) http 1.1的請(qǐng)求到服務(wù)端，這個(gè)請(qǐng)求中包含了 http2的升級(jí)字段雏节，例如：

GET /default.htmHTTP/1.1Host: server.example.comConnection: Upgrade, HTTP2-Settings ?Upgrade: h2c ?HTTP2-Settings:

服務(wù)端收到這個(gè)請(qǐng)求后胜嗓，如果支持 Upgrade 中 列舉的協(xié)議，這里是 h2c钩乍，就會(huì)返回支持的響應(yīng)：

HTTP/1.1101Switching Protocols ?Connection:Upgrade ?Upgrade:h2c ?[ HTTP/2connection ...

當(dāng)然辞州，不支持的話，服務(wù)器會(huì)返回一個(gè)不包含 Upgrade 的報(bào)頭字段的響應(yīng)寥粹。

我的客戶端支持了嗎变过？

一切準(zhǔn)備就緒之后，也是時(shí)候?qū)Y(jié)果進(jìn)行驗(yàn)證了涝涤，除了剛才提到的 WireShark 之外媚狰，你還可以使用下面的幾個(gè)工具來對(duì) HTTP 2.0 進(jìn)行測試

Chrome 上的一個(gè)插件，HTTP/2 and SPDY indicator會(huì)在你訪問 http2.0 的網(wǎng)頁的時(shí)候妄痪，以小閃電的形式進(jìn)行指示

點(diǎn)擊小閃電哈雏，會(huì)進(jìn)入一個(gè)頁面，列舉了當(dāng)前瀏覽器訪問的全部 http2.0的請(qǐng)求衫生，所以裳瘪，你可以把你想要測試的客戶端接口在瀏覽器訪問，然后在這個(gè)頁面驗(yàn)證下是否支持 http2.0

charles：這個(gè)大家應(yīng)該都用過罪针，4.0 以上的新版本對(duì) HTTP2.0做了支持彭羹，為了方便，你也可以在 charles 上進(jìn)行調(diào)試泪酱，但是我發(fā)現(xiàn)好像存在 http2.0的一些 bug派殷，目前還沒搞清楚什么原因

使用 nghttp2 來調(diào)試还最，這是一個(gè) C 語言實(shí)現(xiàn)的 HTTP2.0的庫，具體使用方法可以參考：使用 nghttp2 調(diào)試 HTTP/2 流量

再者簡單粗暴毡惜，直接在 iOS 代碼中打印拓轻，_CFURLResponse 中包含了 httpversion，獲取方法就是基于 CFNetwork 相關(guān)的 API 來做经伙，這里直接丟出關(guān)鍵代碼扶叉，完整代碼可以參考getHTTPVersion

#import"NSURLResponse+Help.h"#import@implementationNSURLResponse(Help)typedefCFHTTPMessageRef(*MYURLResponseGetHTTPResponse)(CFURLRefresponse); ?- (NSString*)getHTTPVersion {NSURLResponse*response =self;NSString*version;NSString*funName =@"CFURLResponseGetHTTPResponse"; ? ? ?MYURLResponseGetHTTPResponse originURLResponseGetHTTPResponse = ? ? ?dlsym(RTLD_DEFAULT, [funName UTF8String]); ? ? ?SEL theSelector =NSSelectorFromString(@"_CFURLResponse");if([response respondsToSelector:theSelector] &&NULL!= originURLResponseGetHTTPResponse) {CFTypeRefcfResponse =CFBridgingRetain([response performSelector:theSelector]);if(NULL!= cfResponse) {CFHTTPMessageRefmessage = originURLResponseGetHTTPResponse(cfResponse);CFStringRefcfVersion =CFHTTPMessageCopyVersion(message);if(NULL!= cfVersion) { ? ? ? ? ? ? ? ? ?version = (__bridgeNSString*)cfVersion;CFRelease(cfVersion); ? ? ? ? ? ? ?}CFRelease(cfResponse); ? ? ? ? ?} ? ? ?}if(nil== version ||0== version.length) { ? ? ? ? ?version =@"獲取失敗"; ? ? ?}returnversion; ?}@end

歡迎大家與我交流,分享新鮮的技術(shù)~