前面的文章也提到了目前的移動端網(wǎng)絡(luò)常見性能問題，以及對應(yīng)的優(yōu)化策略，如果把HTTP1.1 替換為 HTTP2.0，可以說是網(wǎng)絡(luò)性能優(yōu)化的一步大棋。這幾天對 iOS HTTP2.0 進(jìn)行了簡單的調(diào)研、測試，在此做個(gè)簡單的總結(jié)
本文的大概思路是介紹 HTTP1.1 的弊端、HTTP2.0 的優(yōu)勢、HTTP2.0 的協(xié)商機(jī)制、iOS 客戶端如何接入 HTTP2.0，以及如何對其進(jìn)行調(diào)試。主要還是加深記憶、方便后期查閱，文末的資料相比本文或許是更有價(jià)值的。
HTTP 1.1
雖然 HTTP1.1 默認(rèn)是開啟 Keep-Alive 長連接的，一定程度上彌補(bǔ)了HTTP1.0每次請求都要?jiǎng)?chuàng)建連接的缺點(diǎn)，但是依然存在 head of line blocking，如果出現(xiàn)一個(gè)較差的網(wǎng)絡(luò)請求，會影響后續(xù)的網(wǎng)絡(luò)請求。為什么呢？如果你發(fā)出1、2、3 三個(gè)網(wǎng)絡(luò)請求，那么 Response 的順序 2、3 要在第一個(gè)網(wǎng)絡(luò)請求之后，以此類推
針對同一域名，在請求較多的情況下，HTTP1.1 會開辟多個(gè)連接，據(jù)說瀏覽器一般是6-8 個(gè)，較多連接也會導(dǎo)致延遲增大，資源消耗等問題
HTTP1.1 不安全，可能存在被篡改、被竊聽、被偽裝等問題。當(dāng)然，前陣子 Apple 推廣 HTTPS 的時(shí)候，相信很多人已經(jīng)接入 HTTPS
HTTP 的頭部沒有壓縮，header 的大小也是傳輸?shù)呢?fù)擔(dān)，帶來更多的流量消耗和傳輸延遲。并且很多 header 是相同的，重復(fù)傳輸是沒有必要的。
服務(wù)端無法主動推送資源到客戶端
HTTP1.1的格式是文本格式，基于文本做一些擴(kuò)展、優(yōu)化相對比較困難，但是文本格式易于閱讀和調(diào)試，但HTTPS之后，也變成二進(jìn)制格式了，這個(gè)優(yōu)勢也不復(fù)存在
HTTP2.0
在 HTTP2.0中，上面的問題幾乎都不存在了。HTTP2.0 的設(shè)計(jì)來源于 Google 的 SPDY 協(xié)議，如果對 SPDY 協(xié)議不了解的話，也可以先對 SPDY 進(jìn)行了解，不過這不影響繼續(xù)閱讀本文
- HTTP 2.0 使用新的二進(jìn)制格式：基本的協(xié)議單位是幀，每個(gè)幀都有不同的類型和用途，規(guī)范中定義了10種不同的幀。例如，報(bào)頭
(HEADERS)和數(shù)據(jù)(DATA)幀組成了基本的HTTP 請求和響應(yīng)；其他幀例如 設(shè)置(SETTINGS),窗口更新(WINDOW_UPDATE), 和推送承諾(PUSH_PROMISE)是用來實(shí)現(xiàn)HTTP/2的其他功能。那些請求和響應(yīng)的幀數(shù)據(jù)通過流來進(jìn)行數(shù)據(jù)交換。新的二進(jìn)制格式是流量控制、優(yōu)先級、server push等功能的基礎(chǔ)。
流(Stream)：一個(gè)Stream是包含一條或多條信息、ID和優(yōu)先級的雙向通道
消息(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，在接收端會根據(jù) ID 進(jìn)行重裝組合，就是通過這樣一種方式來實(shí)現(xiàn)多路復(fù)用。
單一連接：剛才也說到 1.1 在請求多的時(shí)候，會開啟6-8個(gè)連接，而 HTTP2 只會開啟一個(gè)連接，這樣就減少握手帶來的延遲。
頭部壓縮：HTTP2.0 通過 HPACK 格式來壓縮頭部，使用了哈夫曼編碼壓縮、索引表來對頭部大小做優(yōu)化。索引表是把字符串和數(shù)字之間做一個(gè)匹配，比如
method: GET對應(yīng)索引表中的2，那么如果之前發(fā)送過這個(gè)值是，就會緩存起來，之后使用時(shí)發(fā)現(xiàn)之前發(fā)送過該Header字段，并且值相同，就會沿用之前的索引來指代那個(gè)Header值。具體實(shí)驗(yàn)數(shù)據(jù)可以參考這里：HTTP/2 頭部壓縮技術(shù)介紹
- Server Push：就是服務(wù)端可以主動推送一些東西給客戶端，也被稱為緩存推送。推送的資源可以備客戶端日后之需，需要的時(shí)候直接拿出來用，提升了速率。具體的實(shí)驗(yàn)可以參考這里：iOS HTTP/2 Server Push 探索
除了上面講到的特性，HTTP2.0 還有流量控制、流優(yōu)先級和依賴性等功能。更多細(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í)，目前很多地方開始停止對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)行命令后會看到成功創(chuàng)建 rvi0 虛擬網(wǎng)卡的，雙擊 rvi0 開始調(diào)試。
進(jìn)入之后，在手機(jī)上訪問頁面會有源源不斷的請求顯示在 WireShark 的界面上，數(shù)據(jù)太多而不利于我們針對性調(diào)試，你可以過濾下域名，只關(guān)注你想測試的 ip 地址，比如： ip.addr==111.89.211.191 ，當(dāng)然你的 ip 要支持 HTTP2.0才會有預(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ù)端會根據(jù) client hello 中的協(xié)議列表，發(fā)過去自己支持的網(wǎng)絡(luò)協(xié)議，假如服務(wù)端支持 h2，則直接返回h2，協(xié)商成功，如果不支持 h2，則返回一個(gè)其他支持的協(xié)議，比如HTTP1.1、spdy3
這個(gè)是h2的協(xié)商過程，對于剛才提到的 h2c 的協(xié)商過程，與此不同，h2c 利用的是HTTP Upgrade 機(jī)制，客戶端會發(fā)送一個(gè) http 1.1的請求到服務(wù)端，這個(gè)請求中包含了 http2的升級字段，例如：
GET /default.htm HTTP/1.1
Host: server.example.com
Connection: Upgrade, HTTP2-Settings
Upgrade: h2c
HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>
服務(wù)端收到這個(gè)請求后，如果支持 Upgrade 中 列舉的協(xié)議，這里是 h2c，就會返回支持的響應(yīng)：
HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: h2c
[ HTTP/2 connection ...
當(dāng)然，不支持的話，服務(wù)器會返回一個(gè)不包含 Upgrade 的報(bào)頭字段的響應(yīng)。
我的客戶端支持了嗎？
一切準(zhǔn)備就緒之后，也是時(shí)候?qū)Y(jié)果進(jìn)行驗(yàn)證了，除了剛才提到的 WireShark 之外，你還可以使用下面的幾個(gè)工具來對 HTTP 2.0 進(jìn)行測試
- Chrome 上的一個(gè)插件，HTTP/2 and SPDY indicator 會在你訪問 http2.0 的網(wǎng)頁的時(shí)候，以小閃電的形式進(jìn)行指示
點(diǎn)擊小閃電，會進(jìn)入一個(gè)頁面，列舉了當(dāng)前瀏覽器訪問的全部 http2.0的請求，所以，你可以把你想要測試的客戶端接口在瀏覽器訪問，然后在這個(gè)頁面驗(yàn)證下是否支持 http2.0
charles：這個(gè)大家應(yīng)該都用過，4.0 以上的新版本對 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 <dlfcn.h> @implementation NSURLResponse (Help) typedef CFHTTPMessageRef (*MYURLResponseGetHTTPResponse)(CFURLRef response); - (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) { CFTypeRef cfResponse = CFBridgingRetain([response performSelector:theSelector]); if (NULL != cfResponse) { CFHTTPMessageRef message = originURLResponseGetHTTPResponse(cfResponse); CFStringRef cfVersion = CFHTTPMessageCopyVersion(message); if (NULL != cfVersion) { version = (__bridge NSString *)cfVersion; CFRelease(cfVersion); } CFRelease(cfResponse); } } if (nil == version || 0 == version.length) { version = @"獲取失敗"; } return version; } @end
