http1.0與http1.1的區(qū)別
主要區(qū)別主要體現(xiàn)在：

緩存處理

在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)控制緩存策略。

帶寬優(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）。

長(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)。

分塊編碼

這里我們先了解一下什么是分塊編碼。

簡(jiǎn)單來(lái)說(shuō)分塊編碼就是把數(shù)據(jù)拆分成一個(gè)個(gè)的數(shù)據(jù)塊。

然而，為什么會(huì)有這種情況呢？

通常情況下，http響應(yīng)消息以message body的形式作為整包發(fā)送給客戶端的，用content-length表示消息體的長(zhǎng)度，這個(gè)長(zhǎng)度對(duì)于客戶端來(lái)說(shuō)非常重要，因?yàn)槌志眠B接不會(huì)馬上結(jié)束，而是可以發(fā)送多次請(qǐng)求/響應(yīng)，客戶端需要知道哪個(gè)位置才是響應(yīng)消息的結(jié)束，以及后續(xù)響應(yīng)的開(kāi)始，因此這個(gè)content-length就顯得尤為重要，服務(wù)端必須精確地告訴客戶端這個(gè)值，如果content-length比實(shí)際長(zhǎng)度短，就會(huì)出現(xiàn)截?cái)?，如果比?shí)際長(zhǎng)度長(zhǎng)，就可能出現(xiàn)一直處于pending狀態(tài)。
在這種情況下，在復(fù)雜頁(yè)面中可能就會(huì)出現(xiàn)這樣的情況，如果是要把消息完全創(chuàng)建好之后再計(jì)算出其content-length，這時(shí)候客戶端就會(huì)有一段等待時(shí)間，頁(yè)面越復(fù)雜數(shù)據(jù)越復(fù)雜計(jì)算時(shí)間越長(zhǎng)，可能用戶就會(huì)受不了。
分塊傳輸編碼就是針對(duì)這個(gè)情況作出的一種解決方案。它將數(shù)據(jù)分解成一系列數(shù)據(jù)塊，并以多個(gè)塊發(fā)送給客戶端，服務(wù)器發(fā)送數(shù)據(jù)時(shí)不再需要預(yù)先告訴客戶端發(fā)送內(nèi)容的總大小，只需在響應(yīng)頭里添加Transfer-Encoding:chunk就可以不用告訴客戶端發(fā)送內(nèi)容的長(zhǎng)度了

HTTP2.0

http2.0的主要目的是改進(jìn)傳輸性能，實(shí)現(xiàn)低延遲和高吞吐量。

為什么會(huì)需要http2.0?

在http1.1中出現(xiàn)了很多優(yōu)化措施，但是，當(dāng)我們想要進(jìn)行這些措施時(shí)，就會(huì)發(fā)現(xiàn)，其實(shí)其中包含了很多限制。HTTP1.x只能串行地返回響應(yīng)，他不允許一個(gè)連接上的多個(gè)響應(yīng)數(shù)據(jù)交錯(cuò)到達(dá)（多路復(fù)用），因而一個(gè)響應(yīng)必須完全響應(yīng)返回之后，下一個(gè)響應(yīng)才回開(kāi)始傳輸。
而http2.0就是通過(guò)支持請(qǐng)求與響應(yīng)的多路復(fù)用來(lái)減少延遲，通過(guò)壓縮HTTP首部字段來(lái)將協(xié)議開(kāi)銷(xiāo)降至最低，同時(shí)增加對(duì)請(qǐng)求優(yōu)先級(jí)和服務(wù)器推送的支持

http2.0的實(shí)現(xiàn)

二進(jìn)制分幀層

HTTP 2.0 性能增強(qiáng)的核心，全在于新增的二進(jìn)制分幀層(圖 12-1)，它定義了如何
封裝 HTTP 消息并在客戶端與服務(wù)器之間傳輸。

image.png

首部壓縮

http的每次通信會(huì)攜帶一組首部，用于描述傳輸額資源及其屬性。在http1.x中，這些元數(shù)據(jù)以文本的形式發(fā)送，通常會(huì)給每個(gè)請(qǐng)求增加500-800字節(jié)的負(fù)荷。如果算上cookie，可能就會(huì)出現(xiàn)上千字節(jié)的負(fù)荷。為減少開(kāi)銷(xiāo)并提升性能，http2.0會(huì)壓縮首部元數(shù)據(jù)

• http2.0在客戶端和服務(wù)端通過(guò)“首部表”跟蹤和存儲(chǔ)之前發(fā)送的鍵值對(duì)，對(duì)于相同的鍵值對(duì)，不再每次請(qǐng)求和響應(yīng)發(fā)送
• 首部表在http2.0的連續(xù)存儲(chǔ)期內(nèi)始終存在，由客戶端和服務(wù)器共同漸進(jìn)地更新
• 每個(gè)新的首部鍵值對(duì)要么被追加到當(dāng)前表的末尾，要么替換表中的值