1 可擴(kuò)展性

a) HTTP/1.1 在消息中增加版本號(hào)，用于兼容性判斷。 b) HTTP/1.1增加了OPTIONS方法，它允許客戶(hù)端獲取一個(gè)服務(wù)器支持的方法列表。 c) 為了與未來(lái)的協(xié)議規(guī)范兼容，HTTP/1.1在請(qǐng)求消息中包含了Upgrade頭域，通過(guò)該頭域，客戶(hù)端可以讓服務(wù)器知道它能夠支持的其它備用通信協(xié)議，服務(wù)器可以據(jù)此進(jìn)行協(xié)議切換，使用備用協(xié)議與客戶(hù)端進(jìn)行通信。

2 緩存

在 HTTP/1.0 中，使用 Expire 頭域來(lái)判斷資源的 fresh 或 stale，并使用條件請(qǐng)求（conditional request）來(lái)判斷資源是否仍有效。HTTP/1.1 在 1.0 的基礎(chǔ)上加入了一些 cache 的新特性，當(dāng)緩存對(duì)象的 Age 超過(guò) Expire 時(shí)變?yōu)閟tale對(duì)象，cache不需要直接拋棄stale對(duì)象，而是與源服務(wù)器進(jìn)行重新激活（revalidation）。

3 帶寬優(yōu)化

HTTP/1.0中，存在一些浪費(fèi)帶寬的現(xiàn)象，例如客戶(hù)端只是需要某個(gè)對(duì)象的一部分，而服務(wù)器卻將整個(gè)對(duì)象送過(guò)來(lái)了。例如，客戶(hù)端只需要顯示一個(gè)文檔的部分內(nèi)容，又比如下載大文件時(shí)需要支持?jǐn)帱c(diǎn)續(xù)傳功能，而不是在發(fā)生斷連后不得不重新下載完整的包。 HTTP/1.1中在請(qǐng)求消息中引入了range頭域，它允許只請(qǐng)求資源的某個(gè)部分。在響應(yīng)消息中Content-Range頭 域聲明了返回的這部分對(duì)象的偏移值和長(zhǎng)度。如果服務(wù)器相應(yīng)地返回了對(duì)象所請(qǐng)求范圍的內(nèi)容，則響應(yīng)碼為 206（Partial Content），它可以防止Cache將響應(yīng)誤以為是完整的一個(gè)對(duì)象。 另外一種情況是請(qǐng)求消息中如果包含比較大的實(shí)體內(nèi)容，但不確定服務(wù)器是否能夠接收該請(qǐng)求（如是否有權(quán)限），此時(shí)若貿(mào)然發(fā)出帶實(shí)體的請(qǐng)求，如果被拒絕也會(huì)浪費(fèi)帶寬。 HTTP/1.1 加入了一個(gè)新的狀態(tài)碼 100（Continue）?？蛻?hù)端事先發(fā)送一個(gè)只帶頭域的請(qǐng)求，如果服務(wù)器因?yàn)闄?quán)限拒絕了請(qǐng)求，就回送響應(yīng)碼401（Unauthorized）；如果服務(wù)器接收此請(qǐng)求就回送響應(yīng)碼100，客戶(hù)端就可以繼續(xù)發(fā)送帶實(shí)體的完整請(qǐng)求了。注意，HTTP/1.0的客戶(hù)端不支持100響應(yīng)碼。但可以讓客戶(hù)端在請(qǐng)求消息中加入Expect頭域，并將它的值設(shè)置為100-continue。 節(jié)省帶寬資源的一個(gè)非常有效的做法就是壓縮要傳送的數(shù)據(jù)。Content-Encoding是對(duì)消息進(jìn)行端到端（end-to-end）的編碼，它可能是資源在服務(wù)器上保存的固有格式（如jpeg圖片格式）；在請(qǐng)求消息中加入Accept-Encoding頭域，它可以告訴服務(wù)器客戶(hù)端能夠解碼的編碼方式。

4 長(zhǎng)連接

HTTP/1.0 規(guī)定瀏覽器與服務(wù)器只保持短暫的連接，瀏覽器的每次請(qǐng)求都需要與服務(wù)器建立一個(gè) TCP 連接，服務(wù)器完成請(qǐng)求處理后立即斷開(kāi)TCP連接，服務(wù)器不跟蹤每個(gè)客戶(hù)也不記錄過(guò)去的請(qǐng)求。此外，由于大多數(shù)網(wǎng)頁(yè)的流量都比較小，一次TCP連接很少能通過(guò)slow-start區(qū)，不利于提高帶寬利用率。 HTTP 1.1支持長(zhǎng)連接（PersistentConnection）和請(qǐng)求的流水線（Pipelining）處理，在一個(gè)TCP連接上可以傳送多個(gè) HTTP 請(qǐng)求和響應(yīng)，減少了建立和關(guān)閉連接的消耗和延遲。例如：一個(gè)包含有許多圖像的網(wǎng)頁(yè)文件的多個(gè)請(qǐng)求和應(yīng)答可以在一個(gè)連接中傳輸，但每個(gè)單獨(dú)的網(wǎng)頁(yè)文件的請(qǐng)求和應(yīng)答仍然需要使用各自的連接。 HTTP 1.1還允許客戶(hù)端不用等待上一次請(qǐng)求結(jié)果返回，就可以發(fā)出下一次請(qǐng)求，但服務(wù)器端必須按照接收到客戶(hù)端請(qǐng)求的先后順序依次回送響應(yīng)結(jié)果，以保證客戶(hù)端能夠區(qū)分出每次請(qǐng)求的響應(yīng)內(nèi)容，這樣也顯著地減少了整個(gè)下載過(guò)程所需要的時(shí)間。

5 消息傳遞

HTTP消息中可以包含任意長(zhǎng)度的實(shí)體，通常它們使用Content-Length來(lái)給出消息結(jié)束標(biāo)志。但是，對(duì)于很多動(dòng)態(tài)產(chǎn)生的響應(yīng)，只能通過(guò)緩沖完整的消息來(lái)判斷消息的大小，但這樣做會(huì)加大延遲。如果不使用長(zhǎng)連接，還可以通過(guò)連接關(guān)閉的信號(hào)來(lái)判定一個(gè)消息的結(jié)束。 HTTP/1.1 中引入了 Chunkedtransfer-coding 來(lái)解決上面這個(gè)問(wèn)題，發(fā)送方將消息分割成若干個(gè)任意大小的數(shù)據(jù)塊，每個(gè)數(shù)據(jù)塊在發(fā)送時(shí)都會(huì)附上塊的長(zhǎng)度，最后用一個(gè)零長(zhǎng)度的塊作為消息結(jié)束的標(biāo)志。這種方法允許發(fā)送方只緩沖消息的一個(gè)片段，避免緩沖整個(gè)消息帶來(lái)的過(guò)載。 在 HTTP/1.0 中，有一個(gè) Content-MD5 的頭域，要計(jì)算這個(gè)頭域需要發(fā)送方緩沖完整個(gè)消息后才能進(jìn)行。而 HTTP/1.1 中，采用 chunked 分塊傳遞的消息在最后一個(gè)塊（零長(zhǎng)度）結(jié)束之后會(huì)再傳遞一個(gè)拖尾trailer），它包含一個(gè)或多個(gè)頭域，這些頭域是發(fā)送方在傳遞完所有塊之后再計(jì)算出值的。發(fā)送方會(huì)在消息中包含一個(gè)Trailer頭域告訴接收方這個(gè)拖尾的存在。

6 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）。此外，服務(wù)器應(yīng)該接受以絕對(duì)路徑標(biāo)記的資源請(qǐng)求。

7 錯(cuò)誤提示

HTTP/1.0 中只定義了 16 個(gè)狀態(tài)響應(yīng)碼，對(duì)錯(cuò)誤或警告的提示不夠具體。HTTP/1.1 引入了一個(gè) Warning 頭域，增加對(duì)錯(cuò)誤或警告信息的描述。 此外，在HTTP/1.1中新增了24個(gè)狀態(tài)響應(yīng)碼，如409（Conflict）表示請(qǐng)求的資源與資源的當(dāng)前狀態(tài)發(fā)生沖突； 410（Gone）表示服務(wù)器上的某個(gè)資源被永久性的刪除。

總結(jié)

以上是生活随笔為你收集整理的HTTP1.1与HTTP1.0的区别的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。