http協(xié)議早期為互聯(lián)網(wǎng)的普及做出了巨大的貢獻(xiàn)，構(gòu)建了現(xiàn)代互聯(lián)網(wǎng)的基礎(chǔ)架構(gòu)，但是由于協(xié)議制定的時(shí)間較早，在很多方面還是有著局限性，在互聯(lián)網(wǎng)高速發(fā)展，信息爆炸的今天，難免有些捉襟見肘。主要體現(xiàn)在以下幾個(gè)方面：
- 傳輸報(bào)文為ascii文本形式，對于http header不會(huì)進(jìn)行壓縮。這樣對于可讀性是比較友好，但對于計(jì)算機(jī)不太友好，此外傳輸效率較低
- 請求只能由客戶端發(fā)起，不能由服務(wù)端發(fā)起。這種模式限制了一些主動(dòng)推送或者有雙工需求的使用場景，當(dāng)然也有比如websocket之類的解決方案，但那嚴(yán)格來說已經(jīng)不屬于http協(xié)議的范疇了。
- 同步阻塞通訊：其實(shí)在http/1.1中已經(jīng)默認(rèn)使用了持久連接（persistent connection），可以做到多個(gè)請求復(fù)用同一個(gè)tcp連接，同時(shí)利用管道機(jī)制（pipelining），可以讓請求同時(shí)在一個(gè)tcp連接上發(fā)送，但是http本質(zhì)上還是一個(gè)請求/響應(yīng)模型，服務(wù)端仍然需要按照請求的順序依次回復(fù)，不能亂序回復(fù)。這樣要是前面的回應(yīng)特別慢，后面就會(huì)有許多請求排隊(duì)等著。這稱為"隊(duì)頭堵塞"（Head-of-line blocking）。
- 由于隊(duì)頭堵塞問題的存在，在客戶端要下載大量資源的情況下，不得不和服務(wù)器建立多個(gè)TCP連接（大部分瀏覽器允許最多建立6個(gè)和指定服務(wù)器的持久連接），達(dá)到并發(fā)傳輸?shù)男Ч?，而眾所周知，建立和銷毀tcp連接的成本是非常高昂的（如果是https就更高），同時(shí)也增加了服務(wù)端的資源消耗。
基于以上的這些痛點(diǎn)，催生出了http/2。
HTTP/2SPDYhttp/2起源于谷歌的SPDY項(xiàng)目（沒錯(cuò)，又是谷歌-_-）,于 2009 年年中發(fā)布，其主要目標(biāo)是通過解決 HTTP/1.1 中廣為人知的一些性能限制來減少網(wǎng)頁的加載延遲(那些廣為人知的限制我在上面都提到了)。具體來說，這個(gè)項(xiàng)目設(shè)定的目標(biāo)如下：
- 頁面加載時(shí)間 (PLT) 減少 50%。
- 無需網(wǎng)站作者修改任何內(nèi)容。
- 將部署復(fù)雜性降至最低，無需變更網(wǎng)絡(luò)基礎(chǔ)設(shè)施。
- 與開源社區(qū)合作開發(fā)這個(gè)新協(xié)議。
- 收集真實(shí)性能數(shù)據(jù)，驗(yàn)證這個(gè)實(shí)驗(yàn)性協(xié)議是否有效。
到了2012 年，這個(gè)新的實(shí)驗(yàn)性協(xié)議得到了 Chrome、Firefox 和 Opera 的支持，越來越多的大型網(wǎng)站（如 Google、Twitter、Facebook）和小型網(wǎng)站開始在其基礎(chǔ)設(shè)施內(nèi)部署 SPDY。事實(shí)上，在被行業(yè)越來越多的采用之后，SPDY 已經(jīng)具備了成為一個(gè)標(biāo)準(zhǔn)的條件。
觀察到這一趨勢后，HTTP 工作組 (HTTP-WG) 將這一工作提上議事日程，吸取 SPDY 的經(jīng)驗(yàn)教訓(xùn)，并在此基礎(chǔ)上制定了官方“HTTP/2”標(biāo)準(zhǔn)。在擬定宣言草案、向社會(huì)征集 HTTP/2 建議并經(jīng)過內(nèi)部討論之后，HTTP-WG 決定將 SPDY 規(guī)范作為新 HTTP/2 協(xié)議的基礎(chǔ)。2015 年初，IESG 審閱了新的 HTTP/2 標(biāo)準(zhǔn)并批準(zhǔn)發(fā)布。
2、HTTP2的壓力測試關(guān)注點(diǎn)
現(xiàn)網(wǎng)中已經(jīng)存在大量的基于HTTP2協(xié)議的WEB服務(wù)，對于HTTP2協(xié)議，瀏覽器訪問web服務(wù)存在較大的差異，主要體現(xiàn)在相同的并發(fā)量的情況下，WEB服務(wù)會(huì)受到突發(fā)性HTTP請求的沖擊。主要原因是對于瀏覽器訪問一個(gè)頁面，HTTP/1.1協(xié)議，瀏覽器最并發(fā)量控制在6個(gè)以內(nèi)。但對于HTTP2的請求最高并量幾乎沒有限制，如下所示。
要對支持HTTP2協(xié)議的網(wǎng)站進(jìn)行壓力測試，必須是基于HTTP/2協(xié)議的請求并發(fā)（一般支持HTTP2協(xié)議的WEB服務(wù)，都會(huì)同時(shí)支持HTTP/1.1,與客戶端之間建立鏈接時(shí)，必須進(jìn)行握手，互方協(xié)商需要使用的協(xié)議，如果測試工具不支持HTTP/2協(xié)議，下發(fā)HTTP/1.1的協(xié)議請求，WEB服務(wù)器也可以正常提供服務(wù)，這時(shí)測試的結(jié)果就不是你想要的結(jié)果）。
要想證明性能測試工具下的HTTP協(xié)議是HTTP/1.1還是HTTP2,可以通過抓包工具抓取server heloo的報(bào)文進(jìn)行確認(rèn)。如下所示：server hello報(bào)文中的ALPN Next Protocol:h2 ,是判斷發(fā)送HTTP請求協(xié)議版本的重要判斷依據(jù)。
3、支持HTTP2協(xié)議的壓力測試工具
國內(nèi)常用的Jmeter,LoadRunner 12性能測試工具，這兩個(gè)均不支持HTTP2協(xié)議的請求。下圖是通過LR 12.55導(dǎo)入chrome HAR包，發(fā)送HTTP請求的抓包圖。報(bào)文中沒有ALPN Next Protocol:h2的關(guān)鍵字（LR 沒有采用ie錄制腳本的原因是ie不支持HTTP/2)。目前國內(nèi)阿里PTS,騰訊WeTest,華為CPTS均不支持HTTP2協(xié)議。本文采用奇林軟件kylinTOP
4、HTTP2壓力測試
4.1、錄制腳本
打開HTTP2開關(guān)，點(diǎn)擊確認(rèn)，彈出如下對話框，輸入要錄制的URL
錄制生成如下腳本
調(diào)試腳本
調(diào)試過程可以看到HTTP請求的瀑布圖，幾科所有HTTP請求都是同時(shí)并發(fā)。目前kylinTOP工具在處理HTTP/2協(xié)議的HTTP的請求并發(fā)模型依據(jù)請求的父子關(guān)系，按照一定的算法進(jìn)行并發(fā)。從并法的瀑布圖看，與HTTP2協(xié)議的標(biāo)準(zhǔn)相一致（HTTP2標(biāo)準(zhǔn)并發(fā)是按照盡可能的并發(fā)，除非兩個(gè)請求有依賴關(guān)系。最高并發(fā)可以達(dá)到300都有可能）。
