先來(lái)一張圖來(lái)解釋杏愤。。已脓。
太模糊了珊楼？不急不急，讓我們分步分析度液。
http1.0
http1.0早在1996年就出現(xiàn)了厕宗』啵基本上滿足了ajax的需求，但是呢已慢，畢竟剛出來(lái)沒(méi)多久曲聂，在優(yōu)化上就得多下功夫，在http開(kāi)始普及之后佑惠，他的缺點(diǎn)也開(kāi)始展現(xiàn)
http1.0最大的問(wèn)題就是關(guān)于tcp連接的問(wèn)題朋腋，大家都知道tcp是連接型的協(xié)議，所以需要建立連接和斷開(kāi)連接膜楷。但是早期的http1.0只能在一個(gè)tcp上承載一個(gè)http旭咽，而且web端只能有6-8個(gè)鏈接，這就使高并發(fā)的狀態(tài)下帶寬利用率非常低赌厅。所以在99年穷绵，推出了http1.1。
http1.0與http1.1
下圖表示了其主要區(qū)別
來(lái)詳細(xì)說(shuō)一說(shuō)特愿。
緩存處理仲墨，在HTTP1.0中主要使用header里的If-Modified-Since,Expires來(lái)做為緩存判斷的標(biāo)準(zhǔn)，HTTP1.1則引入了更多的緩存控制策略例如Entity tag揍障，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來(lái)控制緩存策略目养。在這之中Etag也是最為重要的。它提供了精確的緩存定向亚兄』旎可以精確緩存某個(gè)文件而不是根據(jù)日期全部緩存。瀏覽器緩存控制
帶寬優(yōu)化及網(wǎng)絡(luò)連接的使用审胚，HTTP1.0中匈勋，存在一些浪費(fèi)帶寬的現(xiàn)象，例如客戶端只是需要某個(gè)對(duì)象的一部分膳叨，而服務(wù)器卻將整個(gè)對(duì)象送過(guò)來(lái)了洽洁，并且不支持?jǐn)帱c(diǎn)續(xù)傳功能，HTTP1.1則在請(qǐng)求頭引入了range頭域菲嘴，它允許只請(qǐng)求資源的某個(gè)部分饿自，即返回碼是206（Partial Content），這樣就方便了開(kāi)發(fā)者自由的選擇以便于充分利用帶寬和連接龄坪。
錯(cuò)誤通知的管理昭雌，在HTTP1.1中新增了24個(gè)錯(cuò)誤狀態(tài)響應(yīng)碼，如409（Conflict）表示請(qǐng)求的資源與資源的當(dāng)前狀態(tài)發(fā)生沖突健田；410（Gone）表示服務(wù)器上的某個(gè)資源被永久性的刪除烛卧。
Host頭處理，在HTTP1.0中認(rèn)為每臺(tái)服務(wù)器都綁定一個(gè)唯一的IP地址妓局，因此总放，請(qǐng)求消息中的URL并沒(méi)有傳遞主機(jī)名（hostname）呈宇。但隨著虛擬主機(jī)技術(shù)的發(fā)展，在一臺(tái)物理服務(wù)器上可以存在多個(gè)虛擬主機(jī)（Multi-homed Web Servers）局雄，并且它們共享一個(gè)IP地址甥啄。HTTP1.1的請(qǐng)求消息和響應(yīng)消息都應(yīng)支持Host頭域，且請(qǐng)求消息中如果沒(méi)有Host頭域會(huì)報(bào)告一個(gè)錯(cuò)誤（400 Bad Request）炬搭。Host,referer,origin三者區(qū)別
長(zhǎng)連接蜈漓，HTTP 1.1支持長(zhǎng)連接（PersistentConnection）和請(qǐng)求的流水線（Pipelining）處理，在一個(gè)TCP連接上可以傳送多個(gè)HTTP請(qǐng)求和響應(yīng)宫盔，減少了建立和關(guān)閉連接的消耗和延遲迎变，在HTTP1.1中默認(rèn)開(kāi)啟Connection： keep-alive，一定程度上彌補(bǔ)了HTTP1.0每次請(qǐng)求都要?jiǎng)?chuàng)建連接的缺點(diǎn)飘言。
好了，現(xiàn)在已經(jīng)優(yōu)化到http1.1了驼侠。但是是不是還有問(wèn)題呢姿鸿。有肯定是有的，在這之前我們先說(shuō)一下https倒源；
http與https
https其實(shí)和http差不多苛预，就是加了個(gè)s嘛，實(shí)質(zhì)上也是笋熬，https是http上加了一層安全套接層（SSL ：safe socket level）热某，也就是這樣。
http1.1與SPDY
然而http1.1還有幾個(gè)明顯的缺點(diǎn)胳螟，
一是會(huì)發(fā)生堵塞：請(qǐng)求到達(dá)的服務(wù)器的速度是不同的昔馋，如果先發(fā)的請(qǐng)求先到達(dá)可能會(huì)發(fā)生阻塞，這樣帶寬就降低了
二是不支持服務(wù)端推送糖耸，如果要求做一個(gè)服務(wù)端數(shù)據(jù)變動(dòng)頁(yè)面立即改變的組件就很難做秘遏。要用短輪詢和長(zhǎng)輪詢。這樣對(duì)帶寬影響也是很大的嘉竟。
...
所以邦危，GOOGLE推出了SPDY。
SPDY是基于https的舍扰，也就是這樣倦蚪。
嘛，SPDY解決的問(wèn)題還是很多的边苹。具體如下陵且。
降低延遲，針對(duì)HTTP高延遲的問(wèn)題勾给，SPDY優(yōu)雅的采取了多路復(fù)用（multiplexing）滩报。多路復(fù)用通過(guò)多個(gè)請(qǐng)求stream共享一個(gè)tcp連接的方式锅知，解決了HOL blocking的問(wèn)題，降低了延遲同時(shí)提高了帶寬的利用率脓钾。
請(qǐng)求優(yōu)先級(jí)（request prioritization）售睹。多路復(fù)用帶來(lái)一個(gè)新的問(wèn)題是，在連接共享的基礎(chǔ)之上有可能會(huì)導(dǎo)致關(guān)鍵請(qǐng)求被阻塞可训。SPDY允許給每個(gè)request設(shè)置優(yōu)先級(jí)昌妹，這樣重要的請(qǐng)求就會(huì)優(yōu)先得到響應(yīng)。比如瀏覽器加載首頁(yè)握截，首頁(yè)的html內(nèi)容應(yīng)該優(yōu)先展示飞崖，之后才是各種靜態(tài)資源文件，腳本文件等加載谨胞，這樣可以保證用戶能第一時(shí)間看到網(wǎng)頁(yè)內(nèi)容固歪。
header壓縮。前面提到HTTP1.x的header很多時(shí)候都是重復(fù)多余的胯努。選擇合適的壓縮算法可以減小包的大小和數(shù)量牢裳。
基于HTTPS的加密協(xié)議傳輸，大大提高了傳輸數(shù)據(jù)的可靠性叶沛。
服務(wù)端推送（server push）蒲讯，采用了SPDY的網(wǎng)頁(yè)，例如我的網(wǎng)頁(yè)有一個(gè)sytle.css的請(qǐng)求灰署，在客戶端收到sytle.css數(shù)據(jù)的同時(shí)判帮，服務(wù)端會(huì)將sytle.js的文件推送給客戶端，當(dāng)客戶端再次嘗試獲取sytle.js時(shí)就可以直接從緩存中獲取到溉箕，不用再發(fā)請(qǐng)求了晦墙。SPDY構(gòu)成圖：
SPDY與http２
結(jié)果httpSPDY這么好用，基本上大家都在用肴茄，就基于SPDY推出了 http2.0,而且把SPDY的優(yōu)勢(shì)用在了http上,也就是可以不用加密也能使用偎痛。而且稍微的把頭部壓縮算法換了一換。
具體來(lái)說(shuō)
- HTTP2.0 支持明文 HTTP 傳輸独郎，而 SPDY 強(qiáng)制使用 HTTPS
- HTTP2.0 消息頭的壓縮算法采用 HPACK http://http2.github.io/http2-spec/compression.html踩麦，而非 SPDY 采用的 DEFLATE http://zh.wikipedia.org/wiki/DEFLATE
綜合上文 來(lái)個(gè)完整的流程圖吧。
