• 參考：https://mp.weixin.qq.com/s/GICbiyJpINrHZ41u_4zT-A
  一、HTTP的歷史

早在 HTTP 建立之初，主要就是為了將超文本標(biāo)記語言(HTML)文檔從Web服務(wù)器傳送到客戶端的瀏覽器壮池。也是說對于前端來說，我們所寫的HTML頁面將要放在我們的 web 服務(wù)器上伦意，用戶端通過瀏覽器訪問url地址來獲取網(wǎng)頁的顯示內(nèi)容火窒，但是到了 WEB2.0 以來，我們的頁面變得復(fù)雜驮肉，不僅僅單純的是一些簡單的文字和圖片熏矿，同時我們的 HTML 頁面有了 CSS，Javascript离钝，來豐富我們的頁面展示票编，當(dāng) ajax 的出現(xiàn)，我們又多了一種向服務(wù)器端獲取數(shù)據(jù)的方法卵渴，這些其實(shí)都是基于 HTTP 協(xié)議的慧域。同樣到了移動互聯(lián)網(wǎng)時代，我們頁面可以跑在手機(jī)端瀏覽器里面浪读，但是和 PC 相比昔榴，手機(jī)端的網(wǎng)絡(luò)情況更加復(fù)雜，這使得我們開始了不得不對 HTTP 進(jìn)行深入理解并不斷優(yōu)化過程中碘橘。

image

二互订、HTTP的基本優(yōu)化

影響一個 HTTP 網(wǎng)絡(luò)請求的因素主要有兩個：帶寬和延遲。

• 帶寬：如果說我們還停留在撥號上網(wǎng)的階段痘拆，帶寬可能會成為一個比較嚴(yán)重影響請求的問題仰禽，但是現(xiàn)在網(wǎng)絡(luò)基礎(chǔ)建設(shè)已經(jīng)使得帶寬得到極大的提升，我們不再會擔(dān)心由帶寬而影響網(wǎng)速，那么就只剩下延遲了吐葵。

• 延遲：

• 瀏覽器阻塞（HOL blocking）：瀏覽器會因?yàn)橐恍┰蜃枞埱蠊婢尽g覽器對于同一個域名，同時只能有 4 個連接（這個根據(jù)瀏覽器內(nèi)核不同可能會有所差異）温峭，超過瀏覽器最大連接數(shù)限制猛铅，后續(xù)請求就會被阻塞。

• DNS 查詢（DNS Lookup）：瀏覽器需要知道目標(biāo)服務(wù)器的 IP 才能建立連接诚镰。將域名解析為 IP 的這個系統(tǒng)就是 DNS奕坟。這個通常可以利用DNS緩存結(jié)果來達(dá)到減少這個時間的目的清笨。

• 建立連接（Initial connection）：HTTP 是基于 TCP 協(xié)議的月杉，瀏覽器最快也要在第三次握手時才能捎帶 HTTP 請求報文，達(dá)到真正的建立連接抠艾，但是這些連接無法復(fù)用會導(dǎo)致每次請求都經(jīng)歷三次握手和慢啟動苛萎。三次握手在高延遲的場景下影響較明顯，慢啟動則對文件類大請求影響較大检号。

三腌歉、HTTP1.0和HTTP1.1的一些區(qū)別

HTTP1.0最早在網(wǎng)頁中使用是在1996年，那個時候只是使用一些較為簡單的網(wǎng)頁上和網(wǎng)絡(luò)請求上齐苛，而HTTP1.1則在1999年才開始廣泛應(yīng)用于現(xiàn)在的各大瀏覽器網(wǎng)絡(luò)請求中翘盖，同時HTTP1.1也是當(dāng)前使用最為廣泛的HTTP協(xié)議。 主要區(qū)別主要體現(xiàn)在：

1. 緩存處理凹蜂，在HTTP1.0中主要使用header里的If-Modified-Since,Expires來做為緩存判斷的標(biāo)準(zhǔn)馍驯，HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略玛痊。

2. 帶寬優(yōu)化及網(wǎng)絡(luò)連接的使用汰瘫，HTTP1.0中，存在一些浪費(fèi)帶寬的現(xiàn)象擂煞，例如客戶端只是需要某個對象的一部分混弥，而服務(wù)器卻將整個對象送過來了，并且不支持?jǐn)帱c(diǎn)續(xù)傳功能对省，HTTP1.1則在請求頭引入了range頭域蝗拿，它允許只請求資源的某個部分，即返回碼是206（Partial Content）蒿涎，這樣就方便了開發(fā)者自由的選擇以便于充分利用帶寬和連接蛹磺。

3. 錯誤通知的管理，在HTTP1.1中新增了24個錯誤狀態(tài)響應(yīng)碼同仆，如409（Conflict）表示請求的資源與資源的當(dāng)前狀態(tài)發(fā)生沖突；410（Gone）表示服務(wù)器上的某個資源被永久性的刪除裙品。

4. Host頭處理俗批，在HTTP1.0中認(rèn)為每臺服務(wù)器都綁定一個唯一的IP地址俗或，因此，請求消息中的URL并沒有傳遞主機(jī)名（hostname）岁忘。但隨著虛擬主機(jī)技術(shù)的發(fā)展辛慰，在一臺物理服務(wù)器上可以存在多個虛擬主機(jī)（Multi-homed Web Servers），并且它們共享一個IP地址干像。HTTP1.1的請求消息和響應(yīng)消息都應(yīng)支持Host頭域帅腌，且請求消息中如果沒有Host頭域會報告一個錯誤（400 Bad Request）。

5. 長連接麻汰，HTTP 1.1支持長連接（PersistentConnection）和請求的流水線（Pipelining）處理速客，在一個TCP連接上可以傳送多個HTTP請求和響應(yīng)，減少了建立和關(guān)閉連接的消耗和延遲五鲫，在HTTP1.1中默認(rèn)開啟Connection： keep-alive溺职，一定程度上彌補(bǔ)了HTTP1.0每次請求都要創(chuàng)建連接的缺點(diǎn)。

四位喂、HTTPS與HTTP的一些區(qū)別

• HTTPS協(xié)議需要到CA申請證書浪耘，一般免費(fèi)證書很少，需要交費(fèi)塑崖。

• HTTP協(xié)議運(yùn)行在TCP之上七冲，所有傳輸?shù)膬?nèi)容都是明文，HTTPS運(yùn)行在SSL/TLS之上规婆，SSL/TLS運(yùn)行在TCP之上澜躺，所有傳輸?shù)膬?nèi)容都經(jīng)過加密的。

• HTTP和HTTPS使用的是完全不同的連接方式聋呢，用的端口也不一樣苗踪，前者是80，后者是443削锰。

• HTTPS可以有效的防止運(yùn)營商劫持通铲，解決了防劫持的一個大問題。

image

五器贩、SPDY：HTTP1.x的優(yōu)化

2012年google如一聲驚雷提出了SPDY的方案颅夺，優(yōu)化了HTTP1.X的請求延遲，解決了HTTP1.X的安全性蛹稍，具體如下：

1. 降低延遲吧黄，針對HTTP高延遲的問題，SPDY優(yōu)雅的采取了多路復(fù)用（multiplexing）唆姐。多路復(fù)用通過多個請求stream共享一個tcp連接的方式拗慨，解決了HOL blocking的問題，降低了延遲同時提高了帶寬的利用率。

2. 請求優(yōu)先級（request prioritization）赵抢。多路復(fù)用帶來一個新的問題是剧蹂，在連接共享的基礎(chǔ)之上有可能會導(dǎo)致關(guān)鍵請求被阻塞。SPDY允許給每個request設(shè)置優(yōu)先級烦却，這樣重要的請求就會優(yōu)先得到響應(yīng)宠叼。比如瀏覽器加載首頁，首頁的html內(nèi)容應(yīng)該優(yōu)先展示其爵，之后才是各種靜態(tài)資源文件冒冬，腳本文件等加載，這樣可以保證用戶能第一時間看到網(wǎng)頁內(nèi)容摩渺。

3. header壓縮简烤。前面提到HTTP1.x的header很多時候都是重復(fù)多余的。選擇合適的壓縮算法可以減小包的大小和數(shù)量证逻。

4. 基于HTTPS的加密協(xié)議傳輸乐埠，大大提高了傳輸數(shù)據(jù)的可靠性。

5. 服務(wù)端推送（server push）囚企，采用了SPDY的網(wǎng)頁丈咐，例如我的網(wǎng)頁有一個sytle.css的請求，在客戶端收到sytle.css數(shù)據(jù)的同時龙宏，服務(wù)端會將sytle.js的文件推送給客戶端棵逊，當(dāng)客戶端再次嘗試獲取sytle.js時就可以直接從緩存中獲取到，不用再發(fā)請求了银酗。SPDY構(gòu)成圖：

image

SPDY位于HTTP之下辆影，TCP和SSL之上，這樣可以輕松兼容老版本的HTTP協(xié)議(將HTTP1.x的內(nèi)容封裝成一種新的frame格式)黍特，同時可以使用已有的SSL功能蛙讥。

六、HTTP2.0性能驚人

HTTP/2: the Future of the Internet https://link.zhihu.com/?target=https://http2.akamai.com/demo 是 Akamai 公司建立的一個官方的演示灭衷，用以說明 HTTP/2 相比于之前的 HTTP/1.1 在性能上的大幅度提升次慢。 同時請求 379 張圖片，從Load time 的對比可以看出 HTTP/2 在速度上的優(yōu)勢翔曲。

image

七迫像、HTTP2.0：SPDY的升級版

HTTP2.0可以說是SPDY的升級版（其實(shí)原本也是基于SPDY設(shè)計的），但是瞳遍，HTTP2.0 跟 SPDY 仍有不同的地方闻妓，如下：

HTTP2.0和SPDY的區(qū)別：

1. HTTP2.0 支持明文 HTTP 傳輸，而 SPDY 強(qiáng)制使用 HTTPS

2. HTTP2.0 消息頭的壓縮算法采用 HPACK http://http2.github.io/http2-spec/compression.html掠械，而非 SPDY 采用的 DEFLATE http://zh.wikipedia.org/wiki/DEFLATE

八由缆、HTTP2.0和HTTP1.X相比的新特性

• 新的二進(jìn)制格式（Binary Format）注祖，HTTP1.x的解析是基于文本±绻Γ基于文本協(xié)議的格式解析存在天然缺陷氓轰，文本的表現(xiàn)形式有多樣性，要做到健壯性考慮的場景必然很多浸卦，二進(jìn)制則不同，只認(rèn)0和1的組合案糙∠尴樱基于這種考慮HTTP2.0的協(xié)議解析決定采用二進(jìn)制格式，實(shí)現(xiàn)方便且健壯时捌。

• 多路復(fù)用（MultiPlexing）怒医，即連接共享，即每一個request都是是用作連接共享機(jī)制的奢讨。一個request對應(yīng)一個id稚叹，這樣一個連接上可以有多個request，每個連接的request可以隨機(jī)的混雜在一起拿诸，接收方可以根據(jù)request的 id將request再歸屬到各自不同的服務(wù)端請求里面扒袖。

• header壓縮，如上文中所言亩码，對前面提到過HTTP1.x的header帶有大量信息季率，而且每次都要重復(fù)發(fā)送，HTTP2.0使用encoder來減少需要傳輸?shù)膆eader大小描沟，通訊雙方各自cache一份header fields表飒泻，既避免了重復(fù)header的傳輸，又減小了需要傳輸?shù)拇笮　?/p>

• 服務(wù)端推送（server push）吏廉，同SPDY一樣泞遗，HTTP2.0也具有server push功能。

九席覆、HTTP2.0的升級改造

• 前文說了HTTP2.0其實(shí)可以支持非HTTPS的史辙，但是現(xiàn)在主流的瀏覽器像chrome，firefox表示還是只支持基于 TLS 部署的HTTP2.0協(xié)議娜睛，所以要想升級成HTTP2.0還是先升級HTTPS為好髓霞。

• 當(dāng)你的網(wǎng)站已經(jīng)升級HTTPS之后，那么升級HTTP2.0就簡單很多畦戒，如果你使用NGINX方库，只要在配置文件中啟動相應(yīng)的協(xié)議就可以了，可以參考**NGINX白皮書障斋，NGINX配置HTTP2.0官方指南 **https://www.nginx.com/blog/nginx-1-9-5/纵潦。

• 使用了HTTP2.0那么徐鹤，原本的HTTP1.x怎么辦，這個問題其實(shí)不用擔(dān)心邀层，HTTP2.0完全兼容HTTP1.x的語義返敬，對于不支持HTTP2.0的瀏覽器，NGINX會自動向下兼容的寥院。

十劲赠、附注

HTTP2.0的多路復(fù)用和HTTP1.X中的長連接復(fù)用有什么區(qū)別？

• HTTP/1.* 一次請求-響應(yīng)秸谢，建立一個連接凛澎，用完關(guān)閉；每一個請求都要建立一個連接估蹄；

• HTTP/1.1 Pipeling解決方式為塑煎，若干個請求排隊串行化單線程處理，后面的請求等待前面請求的返回才能獲得執(zhí)行機(jī)會臭蚁，一旦有某請求超時等最铁，后續(xù)請求只能被阻塞，毫無辦法垮兑，也就是人們常說的線頭阻塞冷尉；

• HTTP/2多個請求可同時在一個連接上并行執(zhí)行。某個請求任務(wù)耗時嚴(yán)重甥角，不會影響到其它連接的正常執(zhí)行网严；
  具體如圖：

image

服務(wù)器推送到底是什么？
服務(wù)端推送能把客戶端所需要的資源伴隨著index.html一起發(fā)送到客戶端嗤无，省去了客戶端重復(fù)請求的步驟震束。正因?yàn)闆]有發(fā)起請求，建立連接等操作当犯，所以靜態(tài)資源通過服務(wù)端推送的方式可以極大地提升速度垢村。具體如下：

• 普通的客戶端請求過程：

image

• 服務(wù)端推送的過程：

image

為什么需要頭部壓縮？
假定一個頁面有100個資源需要加載（這個數(shù)量對于今天的Web而言還是挺保守的）, 而每一次請求都有1kb的消息頭（這同樣也并不少見嚎卫，因?yàn)镃ookie和引用等東西的存在）, 則至少需要多消耗100kb來獲取這些消息頭嘉栓。HTTP2.0可以維護(hù)一個字典，差量更新HTTP頭部拓诸，大大降低因頭部傳輸產(chǎn)生的流量侵佃。具體參考：HTTP/2 頭部壓縮技術(shù)介紹

HTTP2.0多路復(fù)用有多好？
HTTP 性能優(yōu)化的關(guān)鍵并不在于高帶寬奠支，而是低延遲馋辈。TCP 連接會隨著時間進(jìn)行自我「調(diào)諧」，起初會限制連接的最大速度倍谜，如果數(shù)據(jù)成功傳輸迈螟，會隨著時間的推移提高傳輸?shù)乃俣炔媛铡＿@種調(diào)諧則被稱為 TCP 慢啟動。由于這種原因答毫，讓原本就具有突發(fā)性和短時性的 HTTP 連接變的十分低效褥民。
HTTP/2 通過讓所有數(shù)據(jù)流共用同一個連接，可以更有效地使用 TCP 連接洗搂，讓高帶寬也能真正的服務(wù)于 HTTP 的性能提升消返。

十一、參考

HTTP/2.0 相比1.0有哪些重大改進(jìn)蚕脏？
深入研究：HTTP2 的真正性能到底如何
HTTP/2 頭部壓縮技術(shù)介紹