http1.0 - http1.1 - http2.0區(qū)別和差異詳解

概況

HTTP是基于TCP/IP的應(yīng)用層協(xié)議。影響HTTP網(wǎng)絡(luò)請(qǐng)求的因素主要有兩個(gè)：寬帶和延遲。

  • 寬帶: 現(xiàn)在網(wǎng)絡(luò)基礎(chǔ)建設(shè)已經(jīng)很完善，寬帶得到了極大的提升，我們不在會(huì)擔(dān)心由寬帶而影響網(wǎng)速。

  • 延遲:
    1、 瀏覽器阻塞：瀏覽器會(huì)因?yàn)橐恍┰蜃枞?qǐng)求。瀏覽器對(duì)于同一個(gè)域名，同時(shí)只能有4個(gè)連接（瀏覽器內(nèi)核不同可能會(huì)有差異），當(dāng)超過(guò)瀏覽器最大連接數(shù)限制，后續(xù)請(qǐng)求就會(huì)被阻塞。

    2、DNS查詢：瀏覽器需要知道目標(biāo)服務(wù)器的IP才能建立連接。將域名解析為IP的這個(gè)系統(tǒng)就是DNS。通常可以利用DNS緩存結(jié)果達(dá)到減少這個(gè)時(shí)間的目的。

    3、建立連接：HTTP是基于TCP協(xié)議的，瀏覽器最快也要在第三次握手時(shí)才能捎帶HTTP請(qǐng)求報(bào)文，達(dá)到真正建立連接，但是這些連接無(wú)法復(fù)用會(huì)導(dǎo)致每次請(qǐng)求都經(jīng)歷三次握手和慢啟動(dòng)。三次握手在高延遲的場(chǎng)景下影響比較明顯，慢啟動(dòng)對(duì)大文件類請(qǐng)求影響比較大。

持久鏈接（Persistent Connection）

  • HTTP1.0需要使用connection: keep-alive參數(shù)來(lái)告知服務(wù)器端要建立一個(gè)長(zhǎng)連接，而HTTP1.1默認(rèn)支持長(zhǎng)連接。

  • HTTP1.0規(guī)定瀏覽器與服務(wù)器只保持短暫的連接，瀏覽器的每次請(qǐng)求都需要與服務(wù)器建立一個(gè)TCP連接，服務(wù)器完成請(qǐng)求處理后立即斷開TCP鏈接，服務(wù)器不跟蹤每個(gè)客戶記錄和請(qǐng)求。

  • 會(huì)話方式如下：
    1、建立連接
    2、發(fā)出請(qǐng)求信息
    3、回包響應(yīng)信息
    4、關(guān)掉連接

  • 小結(jié)：瀏覽器和web服務(wù)器連接很短，每次連接只處理一個(gè)請(qǐng)求和響應(yīng)。對(duì)每個(gè)請(qǐng)求，瀏覽器和web服務(wù)器都要建立一次單獨(dú)的鏈接，服務(wù)器回完包，會(huì)直接斷開鏈接，所以他們之間的通信是完全獨(dú)立分開的請(qǐng)求和響應(yīng)對(duì)，沒(méi)法做到連接狀態(tài)控制。同時(shí)建立和關(guān)掉鏈接會(huì)占用連接時(shí)間。

  • HTTP1.1支持長(zhǎng)連接（PersistentConnection）和請(qǐng)求的流水線（Pipelining）處理，在一個(gè)TCP連接上可以傳送多個(gè)HTTP請(qǐng)求和響應(yīng)，減少了建立和關(guān)閉連接的消耗和延遲。

  • HTTP1.1還允許客戶端不用等待上一次結(jié)果返回，就可以發(fā)送下一次請(qǐng)求。但服務(wù)器的回包策略必須按照接收到客戶端請(qǐng)求的先后順序依次回送響應(yīng)結(jié)果，以保證客戶端能夠區(qū)分每次請(qǐng)求的響應(yīng)內(nèi)容。

節(jié)約寬帶

  • HTTP1.1支持只發(fā)送header信息（不帶任何body信息），如果服務(wù)器認(rèn)為客戶端有權(quán)限請(qǐng)求服務(wù)器，則返回100，否則返回401。客戶端如果接受到100，才開始把請(qǐng)求body發(fā)送到服務(wù)器。

  • 當(dāng)服務(wù)器返回401的時(shí)候，客戶端就可以不用發(fā)送body了，節(jié)約了寬帶。

Range

  • HTTP1.1還支持傳送內(nèi)容的一部分。這樣當(dāng)客戶端已經(jīng)有一部分的資源后，只需要跟服務(wù)器請(qǐng)求另外的部分資源即可。這是支持文件斷點(diǎn)續(xù)傳的基礎(chǔ)。

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ī)，并且它們共享一個(gè)IP地址。

  • HTTP1.1的請(qǐng)求消息和響應(yīng)消息都支持Host頭域，且請(qǐng)求消息中沒(méi)有Host頭域會(huì)報(bào)告一個(gè)錯(cuò)誤（400 Bad Request）。

HTTP2.0

  • 目前iOS系統(tǒng)網(wǎng)絡(luò)請(qǐng)求框架NSURLSessionTask使用的就是HTTP2.0

  • 新的二進(jìn)制格式，HTTP1.x的解析是基于文本?；谖谋緟f(xié)議的格式解析存在天然缺陷，文本的表現(xiàn)形式有多樣性，
    要做到健壯性考慮的場(chǎng)景必然很多。二進(jìn)制則不同，只認(rèn)0和1的組合。基于這種考慮HTTP2.0的協(xié)議解析決定采用二進(jìn)制格式，實(shí)現(xiàn)方便其健壯。

  • 多路復(fù)用，既連接共享，每一個(gè)request都是是用作連接共享機(jī)制的。一個(gè)request對(duì)應(yīng)一個(gè)id，這樣一個(gè)連接上可以有多個(gè)request，每個(gè)鏈接的request可以隨機(jī)的混雜在一起，接收方可以根據(jù)request的id將request在歸屬到各自不同的服務(wù)端請(qǐng)求里面。多路復(fù)用。

  • header壓縮，HTTP1.x的header帶有大量信息，而且每次都要重復(fù)發(fā)送，HTTP2.0使用encoder來(lái)減少需要傳輸?shù)膆eader大小，通訊雙方各自cache一份 header fields表，既避免了重復(fù)header的傳輸，又減小了需要傳輸?shù)拇笮　?/p>

  • 服務(wù)端推送，同SPDY一樣，HTTP2.0也具有server push功能，具體看下面提到的SPDY。

HTTPS

  • HTTP 有以下安全性問(wèn)題：

    1、使用明文進(jìn)行通信，內(nèi)容可能會(huì)被竊聽；
    2、不驗(yàn)證通信方的身份，通信方的身份有可能遭遇偽裝；
    3、無(wú)法證明報(bào)文的完整性，報(bào)文有可能遭篡改。

  • HTTPS可以理解為 HTTP+SSL/TLS， 即 HTTP 下加入 SSL 層，HTTPS 的安全基礎(chǔ)是 SSL，因此加密的詳細(xì)內(nèi)容就需要 SSL，用于安全的 HTTP 數(shù)據(jù)傳輸。

  • HTTPS 并不是新協(xié)議，而是讓 HTTP 先和 SSL（Secure Sockets Layer）通信，再由 SSL 和 TCP 通信。也就是說(shuō) HTTPS 使用了隧道進(jìn)行通信。通過(guò)使用 SSL，HTTPs 具有了加密（防竊聽）、認(rèn)證（防偽裝）和完整性保護(hù)（防篡改）

對(duì)稱秘鑰加密和非對(duì)稱秘鑰加密

1、對(duì)稱密鑰加密
  • 對(duì)稱密鑰加密（Symmetric-Key Encryption），加密和解密使用同一密鑰
  • 優(yōu)點(diǎn)：運(yùn)算速度快；缺點(diǎn)：密鑰容易被獲??；
2、公開密鑰加密

  • 公開密鑰加密（Public-Key Encryption），也稱為非對(duì)稱密鑰加密，使用一對(duì)密鑰進(jìn)行加密和解密，分別為公開密鑰和私有密鑰。公開密鑰所有人都可以獲得，通信發(fā)送方獲得接收方的公開密鑰之后，就可以使用公開密鑰進(jìn)行加密，接收方收到通信內(nèi)容后使用私有密鑰解密。

  • 優(yōu)點(diǎn)：更加安全；缺點(diǎn)：運(yùn)算速度慢；

3、注:
  • HTTPS采用混合的加密機(jī)制，使用公開密鑰加密用于傳輸對(duì)稱密鑰來(lái)保證安全性，之后使用對(duì)稱密鑰加密進(jìn)行通信來(lái)保證效率。
HTTPS性能問(wèn)題

  • HTTPS 降低用戶訪問(wèn)速度。SSL握手，HTTPS 對(duì)速度會(huì)有一定程度的降低，但是只要經(jīng)過(guò)合理優(yōu)化和部署，HTTPS 對(duì)速度的影響完全可以接受。在很多場(chǎng)景下，HTTPS 速度完全不遜于 HTTP，如果使用 SPDY，HTTPS 的速度甚至還要比 HTTP 快。

  • 相對(duì)于HTTPS降低訪問(wèn)速度，其實(shí)更需要關(guān)心的是服務(wù)器端的CPU壓力，HTTPS中大量的密鑰算法計(jì)算，會(huì)消耗大量的CPU資源，只有足夠的優(yōu)化，HTTPS 的機(jī)器成本才不會(huì)明顯增加。

使用SPDY

  • 2012年google如一聲驚雷提出了SPDY的方案，大家才開始從正面看待和解決老版本HTTP協(xié)議本身的問(wèn)題，SPDY可以說(shuō)是綜合了HTTPS和HTTP兩者有點(diǎn)于一體的傳輸協(xié)議，主要解決：

  • 降低延遲，針對(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構(gòu)成圖

參考文獻(xiàn)：
http://oncenote.com/2014/10/21/Security-1-HTTPS/
http://oncenote.com/2015/09/16/Security-2-HTTPS2/
http://www.itdecent.cn/p/4b5d2d47833d
https://mp.weixin.qq.com/s/-fLLTtip509K6pNOTkflPQ

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡(jiǎn)書系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容