長鏈接
- http1.0
- 每對Request/Response都使用一個新的連接。
- 不支持?jǐn)帱c續(xù)傳，每次都從RANGE:0（http1.1新增加字段）開始
其中HTTP1.0需要在request中增加”Connection： keep-alive“ header才能夠支持，而HTTP1.1默認(rèn)支持 - http1.1
- 默認(rèn)使用長鏈接，在同一個tcp鏈接可以傳送多個http請求和響應(yīng)，同時也支持更多的請求頭和響應(yīng)頭b.允許同時在一條條件上發(fā)送多個請求，但是服務(wù)端必須按照接收請求的先后順序發(fā)送應(yīng)答包c.host請求頭字段，明確標(biāo)識服務(wù)器上的web站點，http1.1還提供了身份認(rèn)證、狀態(tài)管理和cache緩存機(jī)制相關(guān)的頭
帶寬優(yōu)化
- HTTP/1.1中在請求消息中引入了range頭域，在響應(yīng)消息中Content-Range頭域聲明了返回的這部分對象的偏移值和長度。如果服務(wù)器相應(yīng)地返回了對象所請求范圍的內(nèi)容，則響應(yīng)碼為206（Partial Content），它可以防止Cache將響應(yīng)誤以為是完整的一個對象。
- HTTP/1.1加入了一個新的狀態(tài)碼100（Continue），客戶端事先發(fā)送一個只帶頭域的請求，拒絕發(fā)送401; 接受則發(fā)送100,客戶端就可以繼續(xù)發(fā)送帶實體的完整請求了
消息傳遞
- HTTP/1.1中引入了Chunkedtransfer-coding來解決緩存完整消息帶來的性能問題，發(fā)送方將消息分割成若干個任意大小的數(shù)據(jù)塊，每個數(shù)據(jù)塊在發(fā)送時都會附上塊的長度，最后用一個零長度的塊作為消息結(jié)束的標(biāo)志。這種方法允許發(fā)送方只緩沖消息的一個片段，避免緩沖整個消息帶來的過載
- 在HTTP/1.0中，有一個Content-MD5的頭域，要計算這個頭域需要發(fā)送方緩沖完整個消息后才能進(jìn)行。而HTTP/1.1中，采用chunked分塊傳遞的消息在最后一個塊（零長度）結(jié)束之后會再傳遞一個拖尾（trailer），它包含一個或多個頭域，這些頭域是發(fā)送方在傳遞完所有塊之后再計算出值的。發(fā)送方會在消息中包含一個Trailer頭域告訴接收方這個拖尾的存在。
響應(yīng)碼
- 在HTTP/1.1中新增了24個狀態(tài)響應(yīng)碼，如409（Conflict）表示請求的資源與資源的當(dāng)前狀態(tài)發(fā)生沖突；410（Gone）表示服務(wù)器上的某個資源被永久性的刪除。
多路復(fù)用
HTTP/1.1 協(xié)議中 「瀏覽器客戶端在同一時間，針對同一域名下的請求有一定數(shù)量限制，超過限制數(shù)目的請求會被阻塞；多路復(fù)用允許同時通過單一的 HTTP/2 連接發(fā)起多重的請求-響應(yīng)消息。
頭部壓縮
http1.1不支持頭部壓縮， http2.0 支持頭部壓縮的hpack算法
http2.0使用二進(jìn)制數(shù)據(jù)流（實現(xiàn)方便且健壯）
http2.0沒有改變http1.1的語義，而是在http1.1的header和body重新封裝了一層
流量控制
http2.0支持流量控制，和tcp的sliding window類似。http2.0 類似的使用receive window 的做法
更安全的ssl
使用tls的alpn來做協(xié)議升級，且通過黑名單機(jī)制禁用幾百種不再安全的加密算法
參考
https://www.zhihu.com/question/34074946
http://blog.csdn.net/hguisu/article/details/8608888
http://blog.csdn.net/forgotaboutgirl/article/details/6936982/
