即使千辛萬苦坷牛，還是把網(wǎng)站升級到http2了夸浅，遇坑如《phpcms v9站http升級到https加http2遇到到坑》谣沸。
因?yàn)槔碚撓啾扔?HTTP 1.x 玷过，在同時(shí)兼容?HTTP/1.1 完全語義苛蒲，進(jìn)一步減少了網(wǎng)絡(luò)延遲卤橄。
對于前端開發(fā)人員來說，無疑減少了在前端方面的優(yōu)化工作撤防。比如雪碧圖&文件合并||內(nèi)容內(nèi)嵌||域名分片
http1.0的缺點(diǎn)
http1.0被抱怨最多的就是連接無法復(fù)用虽风，和head of line blocking這兩個(gè)問題。理解這兩個(gè)問題有一個(gè)十分重要的前提：客戶端是依據(jù)域名來向服務(wù)器建立連接寄月，一般PC端瀏覽器會針對單個(gè)域名的server同時(shí)建立6～8個(gè)連接辜膝，手機(jī)端的連接數(shù)則一般控制在4～6個(gè)。顯然連接數(shù)并不是越多越好漾肮，資源開銷和整體延遲都會隨之增大厂抖。
連接無法復(fù)用會導(dǎo)致每次請求都經(jīng)歷三次握手和慢啟動。三次握手在高延遲的場景下影響較明顯克懊，慢啟動則對文件類大請求影響較大忱辅。
head of line blocking會導(dǎo)致帶寬無法被充分利用七蜘，以及后續(xù)健康請求被阻塞。假設(shè)有5個(gè)請求同時(shí)發(fā)出墙懂，對于http1.0的實(shí)現(xiàn)橡卤，在第一個(gè)請求沒有收到回復(fù)之前，后續(xù)從應(yīng)用層發(fā)出的請求只能排隊(duì)损搬，請求2碧库，3，4巧勤，5只能等請求1的response回來之后才能逐個(gè)發(fā)出嵌灰。一旦請求1的request因?yàn)槭裁丛驔]有抵達(dá)服務(wù)器，或者response因?yàn)榫W(wǎng)絡(luò)阻塞沒有及時(shí)返回颅悉，影響的就是所有后續(xù)請求沽瞭，問題就變得比較嚴(yán)重了。
對于http1.0的缺點(diǎn)優(yōu)化方案
解決連接無法復(fù)用
http1.0協(xié)議頭里可以設(shè)置Connection:Keep-Alive剩瓶。在header里設(shè)置Keep-Alive可以在一定時(shí)間內(nèi)復(fù)用連接驹溃，具體復(fù)用時(shí)間的長短可以由服務(wù)器控制，一般在15s左右儒搭。到http1.1之后Connection的默認(rèn)值就是Keep-Alive吠架，如果要關(guān)閉連接復(fù)用需要顯式的設(shè)置Connection:Close。一段時(shí)間內(nèi)的連接復(fù)用對PC端瀏覽器的體驗(yàn)幫助很大搂鲫，因?yàn)榇蟛糠值恼埱笤诩性谝恍《螘r(shí)間以內(nèi)傍药。但對移動app來說，成效不大魂仍，app端的請求比較分散且時(shí)間跨度相對較大拐辽。所以移動端app一般會從應(yīng)用層尋求其它解決方案，長連接方案或者偽長連接方案：
方案一：基于tcp的長鏈接
現(xiàn)在越來越多的移動端app都會建立一條自己的長鏈接通道擦酌，通道的實(shí)現(xiàn)是基于tcp協(xié)議俱诸。基于tcp的socket編程技術(shù)難度相對復(fù)雜很多赊舶，而且需要自己制定協(xié)議睁搭，但帶來的回報(bào)也很大。信息的上報(bào)和推送變得更及時(shí)笼平，在請求量爆發(fā)的時(shí)間點(diǎn)還能減輕服務(wù)器壓力（http短連接模式會頻繁的創(chuàng)建和銷毀連接）园骆。不止是IM app有這樣的通道，像淘寶這類電商類app都有自己的專屬長連接通道了≡⒌鳎現(xiàn)在業(yè)界也有不少成熟的方案可供選擇了锌唾，google的protobuf就是其中之一。
方案二：http long-polling
客戶端在初始狀態(tài)就會發(fā)送一個(gè)polling請求到服務(wù)器，服務(wù)器并不會馬上返回業(yè)務(wù)數(shù)據(jù)晌涕，而是等待有新的業(yè)務(wù)數(shù)據(jù)產(chǎn)生的時(shí)候再返回滋捶。所以連接會一直被保持，一旦結(jié)束馬上又會發(fā)起一個(gè)新的polling請求余黎，如此反復(fù)重窟，所以一直會有一個(gè)連接被保持。服務(wù)器有新的內(nèi)容產(chǎn)生的時(shí)候惧财，并不需要等待客戶端建立一個(gè)新的連接亲族。做法雖然簡單，但有些難題需要攻克才能實(shí)現(xiàn)穩(wěn)定可靠的業(yè)務(wù)框架：
和傳統(tǒng)的http短鏈接相比可缚，長連接會在用戶增長的時(shí)候極大的增加服務(wù)器壓力
移動端網(wǎng)絡(luò)環(huán)境復(fù)雜，像wifi和4g的網(wǎng)絡(luò)切換斋枢，進(jìn)電梯導(dǎo)致網(wǎng)絡(luò)臨時(shí)斷掉等帘靡，這些場景都需要考慮怎么重建健康的連接通道。
這種polling的方式穩(wěn)定性并不好瓤帚，需要做好數(shù)據(jù)可靠性的保證描姚，比如重發(fā)和ack機(jī)制。
polling的response有可能會被中間代理cache住戈次，要處理好業(yè)務(wù)數(shù)據(jù)的過期機(jī)制轩勘。
long-polling方式還有一些缺點(diǎn)是無法克服的，比如每次新的請求都會帶上重復(fù)的header信息怯邪，還有數(shù)據(jù)通道是單向的绊寻，主動權(quán)掌握在server這邊，客戶端有新的業(yè)務(wù)請求的時(shí)候無法及時(shí)傳送悬秉。
方案三：http streaming
同long-polling不同的是澄步，server并不會結(jié)束初始的streaming請求，而是持續(xù)的通過這個(gè)通道返回最新的業(yè)務(wù)數(shù)據(jù)和泌。顯然這個(gè)數(shù)據(jù)通道也是單向的村缸。streaming是通過在server response的頭部里增加”Transfer Encoding: chunked”來告訴客戶端后續(xù)還會有新的數(shù)據(jù)到來。除了和long－polling相同的難點(diǎn)之外武氓，streaming還有幾個(gè)缺陷：
有些代理服務(wù)器會等待服務(wù)器的response結(jié)束之后才會將結(jié)果推送到請求客戶端梯皿。對于streaming這種永遠(yuǎn)不會結(jié)束的方式來說，客戶端就會一直處于等待response的過程中县恕。
業(yè)務(wù)數(shù)據(jù)無法按照請求來做分割东羹，所以客戶端沒收到一塊數(shù)據(jù)都需要自己做協(xié)議解析，也就是說要做自己的協(xié)議定制弱睦。
streaming不會產(chǎn)生重復(fù)的header數(shù)據(jù)百姓。
方案四：web socket
WebSocket和傳統(tǒng)的tcp socket連接相似，也是基于tcp協(xié)議况木，提供雙向的數(shù)據(jù)通道垒拢。WebSocket優(yōu)勢在于提供了message的概念旬迹，比基于字節(jié)流的tcp socket使用更簡單，同時(shí)又提供了傳統(tǒng)的http所缺少的長連接功能求类。不過WebSocket相對較新奔垦，2010年才起草，并不是所有的瀏覽器都提供了支持尸疆。各大瀏覽器廠商最新的版本都提供了支持椿猎。
解決head of line blocking
Head of line blocking(以下簡稱為holb)是http2.0之前網(wǎng)絡(luò)體驗(yàn)的最大禍源。健康的請求會被不健康的請求影響寿弱，而且這種體驗(yàn)的損耗受網(wǎng)絡(luò)環(huán)境影響犯眠，出現(xiàn)隨機(jī)且難以監(jiān)控。為了解決holb帶來的延遲症革，協(xié)議設(shè)計(jì)者設(shè)計(jì)了一種新的pipelining機(jī)制筐咧。
不過pipelining并不是救世主，它也存在不少缺陷：
pipelining只能適用于http1.1噪矛，一般來說量蕊，支持http1.1的server都要求支持pipelining。
只有冪等的請求（GET艇挨，HEAD）能使用pipelining残炮，非冪等請求比如POST不能使用，因?yàn)檎埱笾g可能會存在先后依賴關(guān)系缩滨。
head of line blocking并沒有完全得到解決势就，server的response還是要求依次返回，遵循FIFO(first in first out)原則脉漏。也就是說如果請求1的response沒有回來蛋勺，2，3鸠删，4抱完，5的response也不會被送回來。
絕大部分的http代理服務(wù)器不支持pipelining刃泡。
和不支持pipelining的老服務(wù)器協(xié)商有問題巧娱。
可能會導(dǎo)致新的Front of queue blocking問題。
正是因?yàn)橛羞@么多的問題烘贴，各大瀏覽器廠商要么是根本就不支持pipelining禁添，要么就是默認(rèn)關(guān)掉了pipelining機(jī)制，而且啟用的條件十分苛刻桨踪±锨蹋可以參考chrome對于pipeling的問題描述。
HTTP2的優(yōu)勢
二進(jìn)制分幀
http1.x誕生的時(shí)候是明文協(xié)議，其格式由三部分組成：start line（request line或者status line）铺峭，header墓怀，body。要識別這3部分就要做協(xié)議解析卫键，http1.x的解析是基于文本傀履。基于文本協(xié)議的格式解析存在天然缺陷莉炉，文本的表現(xiàn)形式有多樣性钓账，要做到健壯性考慮的場景必然很多，二進(jìn)制則不同絮宁，只認(rèn)0和1的組合梆暮。基于這種考慮http2.0的協(xié)議解析決定采用二進(jìn)制格式绍昂，實(shí)現(xiàn)方便且健壯惕蹄。
http2.0用binary格式定義了一個(gè)一個(gè)的frame，和http1.x的格式對比如下圖：
http2.0的格式定義更接近tcp層的方式治专，這張二機(jī)制的方式十分高效且精簡。
length定義了整個(gè)frame的開始到結(jié)束
type定義frame的類型（一共10種）
flags用bit位定義一些重要的參數(shù)
stream id用作流控制
payload就是request的正文了
為什么么能在不改動 HTTP/1.x 的語義遭顶、方法张峰、狀態(tài)碼、URI 以及首部字段….. 的情況下, HTTP/2 是如何做到「突破 HTTP1.1 的性能限制棒旗，改進(jìn)傳輸性能喘批，實(shí)現(xiàn)低延遲和高吞吐量」？
關(guān)鍵之一就是在 應(yīng)用層(HTTP/2)和傳輸層(TCP or UDP)之間增加一個(gè)二進(jìn)制分幀層铣揉。
在二進(jìn)制分幀層中饶深， HTTP/2 會將所有傳輸?shù)男畔⒎指顬楦〉南⒑蛶╢rame）,并對它們采用二進(jìn)制格式的編碼 ，其中 HTTP1.x 的首部信息會被封裝到 HEADER frame逛拱，而相應(yīng)的 Request Body 則封裝到 DATA frame 里面敌厘。
HTTP/2 通信都在一個(gè)連接上完成，這個(gè)連接可以承載任意數(shù)量的雙向數(shù)據(jù)流朽合。
在過去俱两，HTTP 性能優(yōu)化的關(guān)鍵并不在于高帶寬，而是低延遲曹步。TCP 連接會隨著時(shí)間進(jìn)行自我「調(diào)諧」宪彩，起初會限制連接的最大速度，如果數(shù)據(jù)成功傳輸讲婚，會隨著時(shí)間的推移提高傳輸?shù)乃俣饶蚩住＿@種調(diào)諧則被稱為 TCP 慢啟動。具體復(fù)習(xí)：《再深談TCP/IP三步握手&四步揮手原理及衍生問題—長文解剖IP》、《從網(wǎng)卡發(fā)送數(shù)據(jù)再談TCP/IP協(xié)議—網(wǎng)絡(luò)傳輸速度計(jì)算-網(wǎng)卡構(gòu)造》
由于這種原因活合，讓原本就具有突發(fā)性和短時(shí)性的 HTTP 連接變的十分低效雏婶。
HTTP/2 通過讓所有數(shù)據(jù)流共用同一個(gè)連接，可以更有效地使用 TCP 連接芜辕，讓高帶寬也能真正的服務(wù)于 HTTP 的性能提升尚骄。
總結(jié)：
單連接多資源的方式，減少服務(wù)端的鏈接壓力,內(nèi)存占用更少,連接吞吐量更大
由于 TCP 連接的減少而使網(wǎng)絡(luò)擁塞狀況得以改善侵续，同時(shí)慢啟動時(shí)間的減少,使擁塞和丟包恢復(fù)速度更快
多路復(fù)用 (Multiplexing)||連接共享
多路復(fù)用允許同時(shí)通過單一的 HTTP/2 連接發(fā)起多重的請求-響應(yīng)消息倔丈。
眾所周知 ，在 HTTP/1.1 協(xié)議中 「瀏覽器客戶端在同一時(shí)間状蜗，針對同一域名下的請求有一定數(shù)量限制需五。超過限制數(shù)目的請求會被阻塞」。
Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. A proxy SHOULD use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users. These guidelines are intended to improve HTTP response times and avoid congestion.
source：RFC-2616-8.1.4 Practical Considerations
比如TCP建立連接時(shí)三次握手有1.5個(gè)RTT（round-trip time）的延遲轧坎，為了避免每次請求的都經(jīng)歷握手帶來的延遲宏邮，應(yīng)用層會選擇不同策略的http長鏈接方案。又比如TCP在建立連接的初期有慢啟動（slow start）的特性缸血，所以連接的重用總是比新建連接性能要好蜜氨。
下圖總結(jié)了不同瀏覽器對該限制的數(shù)目。
來源:Roundup on Parallel Connections?
這也是為何一些站點(diǎn)會有多個(gè)靜態(tài)資源 CDN 域名的原因之一
上面協(xié)議解析中提到的stream id就是用作連接共享機(jī)制的：
一個(gè)request對應(yīng)一個(gè)stream并分配一個(gè)id捎泻，這樣一個(gè)連接上可以有多個(gè)stream飒炎，每個(gè)stream的frame可以隨機(jī)的混雜在一起，接收方可以根據(jù)stream id將frame再歸屬到各自不同的request里面笆豁。因而 HTTP/2 能多路復(fù)用(Multiplexing) 郎汪，允許同時(shí)通過單一的 HTTP/2 連接發(fā)起多重的請求-響應(yīng)消息。
因此 HTTP/2 可以很容易的去實(shí)現(xiàn)多流并行而不用依賴建立多個(gè) TCP 連接闯狱，HTTP/2 把 HTTP 協(xié)議通信的基本單位縮小為一個(gè)一個(gè)的幀煞赢，這些幀對應(yīng)著邏輯流中的消息。并行地在同一個(gè) TCP 連接上雙向交換消息哄孤。
前面還提到過連接共享之后照筑，需要優(yōu)先級和請求依賴的機(jī)制配合才能解決關(guān)鍵請求被阻塞的問題。http2.0里的每個(gè)stream都可以設(shè)置又優(yōu)先級（Priority）和依賴（Dependency）瘦陈。優(yōu)先級高的stream會被server優(yōu)先處理和返回給客戶端朦肘，stream還可以依賴其它的sub streams。優(yōu)先級和依賴都是可以動態(tài)調(diào)整的双饥。動態(tài)調(diào)整在有些場景下很有用媒抠，假想用戶在用你的app瀏覽商品的時(shí)候，快速的滑動到了商品列表的底部咏花，但前面的請求先發(fā)出趴生，如果不把后面的請求優(yōu)先級設(shè)高阀趴，用戶當(dāng)前瀏覽的圖片要到最后才能下載完成，顯然體驗(yàn)沒有設(shè)置優(yōu)先級好苍匆。同理依賴在有些場景下也有妙用刘急。
首部壓縮（Header Compression）
http1.x的header由于cookie和user agent很容易膨脹，而且每次都要重復(fù)發(fā)送浸踩。
HTTP/1.1并不支持 HTTP 首部壓縮叔汁，為此 SPDY 和 HTTP/2 應(yīng)運(yùn)而生
這里普及一個(gè)小知識點(diǎn)。現(xiàn)在大家都知道tcp有slow start的特性检碗，三次握手之后開始發(fā)送tcp segment漂佩，第一次能發(fā)送的沒有被ack的segment數(shù)量是由initial tcp window大小決定的仲吏。這個(gè)initial tcp window根據(jù)平臺的實(shí)現(xiàn)會有差異，但一般是2個(gè)segment或者是4k的大小（一個(gè)segment大概是1500個(gè)字節(jié)）着绊，也就是說當(dāng)你發(fā)送的包大小超過這個(gè)值的時(shí)候端考，要等前面的包被ack之后才能發(fā)送后續(xù)的包哨苛，顯然這種情況下延遲更高幢码。intial window也并不是越大越好，太大會導(dǎo)致網(wǎng)絡(luò)節(jié)點(diǎn)的阻塞奏甫，丟包率就會增加戈轿，具體細(xì)節(jié)可以參考IETF這篇文章。http的header現(xiàn)在膨脹到有可能會超過這個(gè)intial window的值了阵子，所以更顯得壓縮header的重要性思杯。
壓縮算法的選擇
SPDY/2使用的是gzip壓縮算法，但后來出現(xiàn)的兩種攻擊方式BREACH和CRIME使得即使走ssl的SPDY也可以被破解內(nèi)容款筑，最后綜合考慮采用的是一種叫HPACK的壓縮算法。這兩個(gè)漏洞和相關(guān)算法可以點(diǎn)擊鏈接查看更多的細(xì)節(jié)腾么，不過這種漏洞主要存在于瀏覽器端奈梳，因?yàn)樾枰ㄟ^javascript來注入內(nèi)容并觀察payload的變化。
現(xiàn)在SPDY 使用的是通用的DEFLATE算法解虱，而 HTTP/2 則使用了專門為首部壓縮而設(shè)計(jì)的HPACK算法攘须。
http2.0使用encoder來減少需要傳輸?shù)膆eader大小，通訊雙方各自cache一份header fields表殴泰，既避免了重復(fù)header的傳輸于宙，又減小了需要傳輸?shù)拇笮 ８咝У膲嚎s算法可以很大的壓縮header悍汛，減少發(fā)送包的數(shù)量從而降低延遲捞魁。
服務(wù)端推送（Server Push）
服務(wù)端推送是一種在客戶端請求之前發(fā)送數(shù)據(jù)的機(jī)制。在 HTTP/2 中离咐，服務(wù)器可以對客戶端的一個(gè)請求發(fā)送多個(gè)響應(yīng)谱俭。Server Push 讓 HTTP1.x 時(shí)代使用內(nèi)嵌資源的優(yōu)化手段變得沒有意義奉件；如果一個(gè)請求是由你的主頁發(fā)起的，服務(wù)器很可能會響應(yīng)主頁內(nèi)容昆著、logo 以及樣式表县貌，因?yàn)樗揽蛻舳藭玫竭@些東西。這相當(dāng)于在一個(gè) HTML 文檔內(nèi)集合了所有的資源凑懂，不過與之相比煤痕，服務(wù)器推送還有一個(gè)很大的優(yōu)勢：可以緩存！也讓在遵循同源的情況下接谨，不同頁面之間可以共享緩存資源成為可能摆碉。
http2.0引入RST_STREAM類型的frame，可以在不斷開連接的前提下取消某個(gè)request的stream疤坝，表現(xiàn)更好兆解。
重置連接表現(xiàn)更好
很多app客戶端都有取消圖片下載的功能場景，對于http1.x來說跑揉，是通過設(shè)置tcp segment里的reset flag來通知對端關(guān)閉連接的锅睛。這種方式會直接斷開連接，下次再發(fā)請求就必須重新建立連接历谍。http2.0引入RST_STREAM類型的frame现拒，可以在不斷開連接的前提下取消某個(gè)request的stream，表現(xiàn)更好望侈。
流量控制（Flow Control）
TCP協(xié)議通過sliding window的算法來做流量控制印蔬。發(fā)送方有個(gè)sending window，接收方有receive window脱衙。http2.0的flow control是類似receive window的做法侥猬，數(shù)據(jù)的接收方通過告知對方自己的flow window大小表明自己還能接收多少數(shù)據(jù)。只有Data類型的frame才有flow control的功能捐韩。對于flow control退唠，如果接收方在flow window為零的情況下依然更多的frame，則會返回block類型的frame荤胁，這張場景一般表明http2.0的部署出了問題瞧预。
更安全的SSL
HTTP2.0使用了tls的拓展ALPN來做協(xié)議升級，除此之外加密這塊還有一個(gè)改動仅政，HTTP2.0對tls的安全性做了近一步加強(qiáng)垢油，通過黑名單機(jī)制禁用了幾百種不再安全的加密算法，一些加密算法可能還在被繼續(xù)使用圆丹。如果在ssl協(xié)商過程當(dāng)中滩愁，客戶端和server的cipher suite沒有交集，直接就會導(dǎo)致協(xié)商失敗辫封，從而請求失敗惊楼。在server端部署http2.0的時(shí)候要特別注意這一點(diǎn)玖瘸。
關(guān)于 HTTP/2 的 Server Push 以及 HTTP/2 的緩存策略
典型問題:
「如果客戶端早已在緩存中有了一份 copy 怎么辦？」還要 Push 嗎?
詳情參考另一個(gè)答案:
HTTP/2 對現(xiàn)在的網(wǎng)頁訪問檀咙，有什么大的優(yōu)化呢雅倒？體現(xiàn)在什么地方
PS:
強(qiáng)烈推薦閱讀 ?Mark Nottingham 在Velocity Beijing 2015的 speech：HTTP/2 for Front-End Developers,關(guān)于 HTTP/2 下的前端性能優(yōu)化相關(guān)。
Slide 地址：HTTP/2 for Front-End Developers
按照OSI網(wǎng)絡(luò)分層模型弧可，IP是網(wǎng)絡(luò)層協(xié)議蔑匣，TCP是傳輸層協(xié)議，而HTTP是應(yīng)用層的協(xié)議棕诵。在這三者之間裁良，SPDY和WebSocket都是與HTTP相關(guān)的協(xié)議，而TCP是HTTP底層的協(xié)議校套。
HTTP2的發(fā)展歷史
一价脾、http
HTTP協(xié)議經(jīng)過多年的使用，發(fā)現(xiàn)了一些不足笛匙，主要是性能方面的侨把，包括：
HTTP的連接問題，HTTP客戶端和服務(wù)器之間的交互是采用請求/應(yīng)答模式妹孙，在客戶端請求時(shí)秋柄，會建立一個(gè)HTTP連接，然后發(fā)送請求消息蠢正，服務(wù)端給出應(yīng)答消息骇笔，然后連接就關(guān)閉了。（后來的HTTP1.1支持持久連接）
因?yàn)門CP連接的建立過程是有開銷的嚣崭，如果使用了SSL/TLS開銷就更大笨触。
在瀏覽器里，一個(gè)網(wǎng)頁包含許多資源雹舀，包括HTML芦劣，CSS，JavaScript葱跋，圖片等等持寄，這樣在加載一個(gè)網(wǎng)頁時(shí)要同時(shí)打開連接到同一服務(wù)器的多個(gè)連接源梭。
HTTP消息頭問題娱俺，現(xiàn)在的客戶端會發(fā)送大量的HTTP消息頭，由于一個(gè)網(wǎng)頁可能需要50-100個(gè)請求废麻，就會有相當(dāng)大的消息頭的數(shù)據(jù)量荠卷。
HTTP通信方式問題，HTTP的請求/應(yīng)答方式的會話都是客戶端發(fā)起的烛愧，缺乏服務(wù)器通知客戶端的機(jī)制油宜，在需要通知的場景掂碱，如聊天室，游戲慎冤，客戶端應(yīng)用需要不斷地輪詢服務(wù)器疼燥。
而SPDY和WebSocket是從不同的角度來解決這些不足中的一部分。除了這兩個(gè)技術(shù)蚁堤，還有其他技術(shù)也在針對這些不足提出改進(jìn)醉者。
二、SPDY
SPDY的主要目的是減少50%以上的頁面加載時(shí)間披诗，但是呢不增加部署的復(fù)雜性撬即，不影響客戶端和服務(wù)端的Web應(yīng)用，只需要瀏覽器和Web服務(wù)器支持SPDY呈队。主要有以下幾：
多路復(fù)用剥槐，一個(gè)TCP連接上同時(shí)跑多個(gè)HTTP請求。請求可設(shè)定優(yōu)先級宪摧。
去除不需要的HTTP頭粒竖，壓縮HTTP頭，以減少需要的網(wǎng)絡(luò)帶寬绍刮。
使用了SSL作為傳輸協(xié)議提供數(shù)據(jù)安全温圆。
對傳輸?shù)臄?shù)據(jù)使用gzip進(jìn)行壓縮
提供服務(wù)方發(fā)起通信，并向客戶端推送數(shù)據(jù)的機(jī)制孩革。
實(shí)質(zhì)上岁歉，SPDY就是想不影響HTTP語義的情況下，替換HTTP底層傳輸?shù)膮f(xié)議來加快頁面加載時(shí)間膝蜈。
SPDY的解決辦法就是設(shè)計(jì)了一個(gè)會話層協(xié)議--幀協(xié)議锅移，解決多路復(fù)用，優(yōu)先級等問題饱搏，然后在其上實(shí)現(xiàn)了HTTP的語義非剃。
SPDY的誕生和表現(xiàn)說明了兩件事情：一是在現(xiàn)有互聯(lián)網(wǎng)設(shè)施基礎(chǔ)和http協(xié)議廣泛使用的前提下，是可以通過修改協(xié)議層來優(yōu)化http1.x的推沸。二是針對http1.x的修改確實(shí)效果明顯而且業(yè)界反饋很好备绽。正是這兩點(diǎn)讓IETF（Internet Enginerring Task Force）開始正式考慮制定HTTP2.0的計(jì)劃，最后決定以SPDY／3為藍(lán)圖起草HTTP2.0鬓催，SPDY的部分設(shè)計(jì)人員也被邀請參與了HTTP2.0的設(shè)計(jì)肺素。
三、WebSocket
WebSocket則提供使用一個(gè)TCP連接進(jìn)行雙向通訊的機(jī)制宇驾，包括網(wǎng)絡(luò)協(xié)議和API倍靡，以取代網(wǎng)頁和服務(wù)器采用HTTP輪詢進(jìn)行雙向通訊的機(jī)制。
本質(zhì)上來說课舍，WebSocket是不限于HTTP協(xié)議的塌西，但是由于現(xiàn)存大量的HTTP基礎(chǔ)設(shè)施他挎，代理，過濾捡需，身份認(rèn)證等等办桨，WebSocket借用HTTP和HTTPS的端口。
由于使用HTTP的端口站辉，因此TCP連接建立后的握手消息是基于HTTP的崔挖，由服務(wù)器判斷這是一個(gè)HTTP協(xié)議，還是WebSocket協(xié)議庵寞。 WebSocket連接除了建立和關(guān)閉時(shí)的握手狸相，數(shù)據(jù)傳輸和HTTP沒丁點(diǎn)關(guān)系了。
WebSocket也有自己一套幀協(xié)議捐川。
四脓鹃、SPDY和WebSocket的關(guān)系
SPDY和WebSocket的關(guān)系比較復(fù)雜。
補(bǔ)充關(guān)系古沥，二者側(cè)重點(diǎn)不同瘸右。SPDY更側(cè)重于給Web頁面的加載提速，而WebSocket更強(qiáng)調(diào)為Web應(yīng)用提供一種雙向的通訊機(jī)制以及API岩齿。
競爭關(guān)系太颤，二者解決的問題有交集，比如在服務(wù)器推送上SPDY和WebSocket都提供了方案盹沈。
承載關(guān)系龄章，試想，如果SPDY的標(biāo)準(zhǔn)化早于WebSocket乞封，WebSocket完全可以側(cè)重于API做裙，利用SPDY的幀機(jī)制和多路復(fù)用機(jī)制實(shí)現(xiàn)該API。 Google提出草案肃晚，說WebSocket可以跑在SPDY之上锚贱。WebSocket的連接建立在SPDY的流之上，將WebSocket的幀映射到SPDY的幀上关串。
融合關(guān)系拧廊，如微軟在HTTP Speed+Mobility中所做的。
http2的競爭兄弟
1. HTTP Speed+Mobility
還有一個(gè)有趣的技術(shù)叫做HTTP Speed+Mobility晋修，和SPDY一樣都是HTTP 2.0標(biāo)準(zhǔn)的競爭者吧碾，HTTP Speed+Mobility來自微軟。HTTP SM借鑒了SPDY和WebSocket的協(xié)議飞蚓，將二者揉為一體滤港，又有所取舍廊蜒。
HTTP SM的設(shè)計(jì)原則包括：
保留HTTP的語義趴拧，這一點(diǎn)和SPDY一致溅漾，但也正應(yīng)如此，拋棄了SPDY里的ServerPush著榴。
遵守分層的網(wǎng)絡(luò)架構(gòu)添履，TCP能做的，HTTP SM不做脑又，因此去除了SPDY的流控暮胧。
使用現(xiàn)有標(biāo)準(zhǔn)，因此使用HTTP/1.1 Upgrade header機(jī)制问麸，借用了WebSocket的握手機(jī)制和幀格式（RFC6455）往衷。
客戶端掌握內(nèi)容的控制，因此不強(qiáng)制使用壓縮和SSL/TLS严卖。
考慮到網(wǎng)絡(luò)的費(fèi)用和電力席舍，這點(diǎn)考慮到了移動設(shè)備以及物聯(lián)網(wǎng)，提供了Credit Control機(jī)制哮笆。
HTTP SM分以下幾層：
會話層和幀協(xié)議来颤，這部分取自WebSocket協(xié)議。包括握手機(jī)制稠肘，以及幀格式福铅。
流層（包括多路復(fù)用），這部分主要借鑒SPDY项阴，包括多路復(fù)用滑黔，流優(yōu)先級，但增加了Credit Control环揽。這部分作為 WebSocket協(xié)議的擴(kuò)展拷沸。
HTTP層，在流層上實(shí)現(xiàn)HTTP語義薯演，這部分也借鑒自SPDY撞芍。
2.? Network-Friendly HTTP
NF是HTTP 2.0候選方案之一，主要提出以下改進(jìn)：
對HTTP頭的名稱進(jìn)行二進(jìn)制編碼
對通用HTTP頭進(jìn)行分組
請求/應(yīng)答的多路復(fù)用
分層模型
NF同樣定義了幀和流跨扮，
3. WAKA
WAKA也是HTTP 2.0候選方案之一序无，是HTTP協(xié)議原作者Roy Fielding提出的一個(gè)提案。
WAKA支持多路復(fù)用衡创，支持優(yōu)先級帝嗡。WAKA提出了兩個(gè)新的HTTP方法，RENDER和MONITOR璃氢。
參考資料：
Gitbook 《HTTP2 講解》 by Calvin Zhang and Simon Xia：http2講解 ?- GitBook
HTTPS哟玷、SPDY 以及 HTTP/2 性能簡單對比：A Simple Performance Comparison of HTTPS, SPDY and HTTP/2
HTTP/2 的壓縮算法--HPACK（RFC7541）：HPACK: Header Compression for HTTP/2
NGINX HTTP/2 白皮書：https://www.nginx.com/wp-content/uploads/2015/09/NGINX_HTTP2_White_Paper_v4.pdf
NGINX Blog--提升 HTTP/2 性能的 7個(gè)小建議：
7 Tips for Faster HTTP/2 Performance（原文）
[譯]使用HTTP/2提升性能的7個(gè)建議（李松峰譯）
O'Reilly?HTTP2-high-perf-browser-networking：http://www.oreilly.com/webops-perf/free/files/HTTP2-high-perf-browser-networking.pdf
HTTP/2 新特性淺析：HTTP/2 新特性淺析
Kevin blog 關(guān)于 HTTP/2 的系列歸檔：HTTP/2 | 凱文叔叔的網(wǎng)志
Can i use 上關(guān)于支持HTTP/2 的瀏覽器：Can I use... Support tables for HTML5, CSS3, etc
http://http2-explained.haxx.se/content/en/part5.html
https://www.chromium.org/spdy/spdy-whitepape
本文主要內(nèi)容來源:《HTTP 2.0的那些事》
文章由本人精煉而成，原文：再談HTTP2性能提升之背后原理-HTTP2歷史解剖 - Network - 周陸軍的個(gè)人網(wǎng)站
