http1.0現(xiàn)狀：
帶寬：
如果說我們還停留在撥號上網(wǎng)的階段，帶寬可能會成為一個(gè)比較嚴(yán)重影響請求的問題，但是現(xiàn)在網(wǎng)絡(luò)基礎(chǔ)建設(shè)已經(jīng)使得帶寬得到極大的提升，我們不再會擔(dān)心由帶寬而影響網(wǎng)速，那么就只剩下延遲了。
延遲
瀏覽器阻塞（HOL blocking）
瀏覽器會因?yàn)橐恍┰蜃枞埱蟆g覽器對于同一個(gè)域名，同時(shí)只能有 4 個(gè)連接（這個(gè)根據(jù)瀏覽器內(nèi)核不同可能會有所差異），超過瀏覽器最大連接數(shù)限制，后續(xù)請求就會被阻塞。
DNS 查詢（DNS Lookup）
瀏覽器需要知道目標(biāo)服務(wù)器的 IP 才能建立連接。將域名解析為 IP 的這個(gè)系統(tǒng)就是 DNS。這個(gè)通?？梢岳肈NS緩存結(jié)果來達(dá)到減少這個(gè)時(shí)間的目的。
建立連接（Initial connection）
HTTP 是基于 TCP 協(xié)議的，瀏覽器最快也要在第三次握手時(shí)才能捎帶 HTTP 請求報(bào)文，達(dá)到真正的建立連接，但是這些連接無法復(fù)用會導(dǎo)致每次請求都經(jīng)歷三次握手和慢啟動。三次握手在高延遲的場景下影響較明顯，慢啟動則對文件類大請求影響較大。
HTTPS與HTTP的一些區(qū)別
1.HTTPS協(xié)議需要到CA申請證書，一般免費(fèi)證書很少，需要交費(fèi)。
2.HTTP協(xié)議運(yùn)行在TCP之上，所有傳輸?shù)膬?nèi)容都是明文，HTTPS運(yùn)行在SSL/TLS之上，SSL/TLS運(yùn)行在TCP之上，所有傳輸?shù)膬?nèi)容都經(jīng)過加密的。
3.HTTP和HTTPS使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。
4.HTTPS可以有效的防止運(yùn)營商劫持，解決了防劫持的一個(gè)大問題。
SPDY：HTTP1.x的優(yōu)化
2012年google如一聲驚雷提出了SPDY的方案，優(yōu)化了HTTP1.X的請求延遲，解決了HTTP1.X的安全性，具體如下：
降低延遲
針對HTTP高延遲的問題，SPDY優(yōu)雅的采取了多路復(fù)用（multiplexing）。多路復(fù)用通過多個(gè)請求stream共享一個(gè)tcp連接的方式，解決了HOL blocking的問題，降低了延遲同時(shí)提高了帶寬的利用率。
請求優(yōu)先級（request prioritization）。
多路復(fù)用帶來一個(gè)新的問題是，在連接共享的基礎(chǔ)之上有可能會導(dǎo)致關(guān)鍵請求被阻塞。SPDY允許給每個(gè)request設(shè)置優(yōu)先級，這樣重要的請求就會優(yōu)先得到響應(yīng)。比如瀏覽器加載首頁，首頁的html內(nèi)容應(yīng)該優(yōu)先展示，之后才是各種靜態(tài)資源文件，腳本文件等加載，這樣可以保證用戶能第一時(shí)間看到網(wǎng)頁內(nèi)容。
header壓縮。
前面提到HTTP1.x的header很多時(shí)候都是重復(fù)多余的。選擇合適的壓縮算法可以減小包的大小和數(shù)量。
基于HTTPS的加密協(xié)議傳輸，大大提高了傳輸數(shù)據(jù)的可靠性。
服務(wù)端推送（server push），
采用了SPDY的網(wǎng)頁，例如我的網(wǎng)頁有一個(gè)sytle.css的請求，在客戶端收到sytle.css數(shù)據(jù)的同時(shí)，服務(wù)端會將sytle.js的文件推送給客戶端，當(dāng)客戶端再次嘗試獲取sytle.js時(shí)就可以直接從緩存中獲取到，不用再發(fā)請求了。SPDY構(gòu)成圖：
SPDY位于HTTP之下，TCP和SSL之上，這樣可以輕松兼容老版本的HTTP協(xié)議(將HTTP1.x的內(nèi)容封裝成一種新的frame格式)，同時(shí)可以使用已有的SSL功能。
HTTP2.0
可以說是SPDY的升級版（其實(shí)原本也是基于SPDY設(shè)計(jì)的），但是，HTTP2.0 跟 SPDY 仍有不同的地方，如下：
HTTP2.0和SPDY的區(qū)別：
1.HTTP2.0 支持明文 HTTP 傳輸，而 SPDY 強(qiáng)制使用 HTTPS
2.HTTP2.0 消息頭的壓縮算法采用 HPACK 了解HPACK，而非 SPDY 采用的 DEFLATE 了解DEFLATE
HTTP2.0和HTTP1.X相比的新特性
1.新的二進(jìn)制格式（Binary Format），HTTP1.x的解析是基于文本?；谖谋緟f(xié)議的格式解析存在天然缺陷，文本的表現(xiàn)形式有多樣性，要做到健壯性考慮的場景必然很多，二進(jìn)制則不同，只認(rèn)0和1的組合。基于這種考慮HTTP2.0的協(xié)議解析決定采用二進(jìn)制格式，實(shí)現(xiàn)方便且健壯。
2.多路復(fù)用（MultiPlexing），即連接共享，即每一個(gè)request都是是用作連接共享機(jī)制的。一個(gè)request對應(yīng)一個(gè)id，這樣一個(gè)連接上可以有多個(gè)request，每個(gè)連接的request可以隨機(jī)的混雜在一起，接收方可以根據(jù)request的 id將request再歸屬到各自不同的服務(wù)端請求里面。
3.header壓縮，如上文中所言，對前面提到過HTTP1.x的header帶有大量信息，而且每次都要重復(fù)發(fā)送，HTTP2.0使用encoder來減少需要傳輸?shù)膆eader大小，通訊雙方各自cache一份header fields表，既避免了重復(fù)header的傳輸，又減小了需要傳輸?shù)拇笮 ?br>
4.服務(wù)端推送（server push），同SPDY一樣，HTTP2.0也具有server push功能。
HTTP2.0的升級改造
1.前文說了HTTP2.0其實(shí)可以支持非HTTPS的，但是現(xiàn)在主流的瀏覽器像chrome，firefox表示還是只支持基于 TLS 部署的HTTP2.0協(xié)議，所以要想升級成HTTP2.0還是先升級HTTPS為好。
2.當(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/)。
3.使用了HTTP2.0那么，原本的HTTP1.x怎么辦，這個(gè)問題其實(shí)不用擔(dān)心，HTTP2.0完全兼容HTTP1.x的語義，對于不支持HTTP2.0的瀏覽器，NGINX會自動向下兼容的。
HTTP2.0的多路復(fù)用和HTTP1.X中的長連接復(fù)用的區(qū)別
1.HTTP/1.* 一次請求-響應(yīng)，建立一個(gè)連接，用完關(guān)閉；每一個(gè)請求都要建立一個(gè)連接；
2.HTTP/1.1 Pipeling解決方式為，若干個(gè)請求排隊(duì)串行化單線程處理，后面的請求等待前面請求的返回才能獲得執(zhí)行機(jī)會，一旦有某請求超時(shí)等，后續(xù)請求只能被阻塞，毫無辦法，也就是人們常說的線頭阻塞；
3.HTTP/2多個(gè)請求可同時(shí)在一個(gè)連接上并行執(zhí)行。某個(gè)請求任務(wù)耗時(shí)嚴(yán)重，不會影響到其它連接的正常執(zhí)行；
具體如圖：
為什么需要頭部壓縮？
假定一個(gè)頁面有100個(gè)資源需要加載（這個(gè)數(shù)量對于今天的Web而言還是挺保守的）, 而每一次請求都有1kb的消息頭（這同樣也并不少見，因?yàn)镃ookie和引用等東西的存在）, 則至少需要多消耗100kb來獲取這些消息頭。HTTP2.0可以維護(hù)一個(gè)字典，差量更新HTTP頭部，大大降低因頭部傳輸產(chǎn)生的流量。具體參考：HTTP/2 頭部壓縮技術(shù)介紹
HTTP2.0多路復(fù)用有多好？
HTTP 性能優(yōu)化的關(guān)鍵并不在于高帶寬，而是低延遲。TCP 連接會隨著時(shí)間進(jìn)行自我「調(diào)諧」，起初會限制連接的最大速度，如果數(shù)據(jù)成功傳輸，會隨著時(shí)間的推移提高傳輸?shù)乃俣?。這種調(diào)諧則被稱為 TCP 慢啟動。由于這種原因，讓原本就具有突發(fā)性和短時(shí)性的 HTTP 連接變的十分低效。
HTTP/2 通過讓所有數(shù)據(jù)流共用同一個(gè)連接，可以更有效地使用 TCP 連接，讓高帶寬也能真正的服務(wù)于 HTTP 的性能提升。
