HTTP/1.0與HTTP/1.1之間的差別

下面主要從幾個不同的方面介紹 HTTP/1.0與HTTP/1.1之間的差別,當然,更多的內容是放在解釋這種差異背後的機制上。

1 可擴展性

可擴展性的一個重要原則:如果HTTP的某個實現接收到了自身未定義的頭域,將自動忽略它。

Ø  在消息中增加版本號,用於兼容性判斷。注意,版本號只能用來判斷逐段(hop-by-hop)的兼容性,而無法判斷端到端(end-to-end)的兼容性。
例如,一臺HTTP/1.1的源服務器從使用HTTP/1.1的Proxy那兒接收到一條轉發的消息,實際上源服務器並不知道終端客戶使用的是HTTP/1.0還是HTTP/1.1。因此,HTTP/1.1定義Via頭域,用來記錄消息轉發的路徑,它記錄了整個路徑上所有發送方使用的版本號。

Ø  HTTP/1.1增加了OPTIONS方法,它允許客戶端獲取一個服務器支持的方法列表。

Ø  爲了與未來的協議規範兼容,HTTP/1.1在請求消息中包含了Upgrade頭域,通過該頭域,客戶端可以讓服務器知道它能夠支持的其它備用通信協議,服務器可以據此進行協議切換,使用備用協議與客戶端進行通信。

2 緩存

在HTTP/1.0中,使用Expire頭域來判斷資源的fresh或stale,並使用條件請求(conditional request)來判斷資源是否仍有效。例如,cache服務器通過If-Modified-Since頭域向服務器驗證資源的Last-Modefied頭域是否有更新,源服務器可能返回304(Not Modified),則表明該對象仍有效;也可能返回200(OK)替換請求的Cache對象。

此外,HTTP/1.0中還定義了Pragma:no-cache頭域,客戶端使用該頭域說明請求資源不能從cache中獲取,而必須回源獲取。

HTTP/1.1在1.0的基礎上加入了一些cache的新特性,當緩存對象的Age超過Expire時變爲stale對象,cache不需要直接拋棄stale對象,而是與源服務器進行重新激活(revalidation)。

HTTP/1.0中,If-Modified-Since頭域使用的是絕對時間戳,精確到秒,但使用絕對時間會帶來不同機器上的時鐘同步問題。而HTTP/1.1中引入了一個ETag頭域用於重激活機制,它的值entity tag可以用來唯一的描述一個資源。請求消息中可以使用If-None-Match頭域來匹配資源的entitytag是否有變化。

爲了使caching機制更加靈活,HTTP/1.1增加了Cache-Control頭域(請求消息和響應消息都可使用),它支持一個可擴展的指令子集:例如max-age指令支持相對時間戳;private和no-store指令禁止對象被緩存;no-transform阻止Proxy進行任何改變響應的行爲。

Cache使用關鍵字索引在磁盤中緩存的對象,在HTTP/1.0中使用資源的URL作爲關鍵字。但可能存在不同的資源基於同一個URL的情況,要區別它們還需要客戶端提供更多的信息,如Accept-Language和Accept-Charset頭域。爲了支持這種內容協商機制(content negotiation mechanism),HTTP/1.1在響應消息中引入了Vary頭域,該頭域列出了請求消息中需要包含哪些頭域用於內容協商。

3 帶寬優化

HTTP/1.0中,存在一些浪費帶寬的現象,例如客戶端只是需要某個對象的一部分,而服務器卻將整個對象送過來了。例如,客戶端只需要顯示一個文檔的部分內容,又比如下載大文件時需要支持斷點續傳功能,而不是在發生斷連後不得不重新下載完整的包。

HTTP/1.1中在請求消息中引入了range頭域,它允許只請求資源的某個部分。在響應消息中Content-Range頭域聲明瞭返回的這部分對象的偏移值和長度。如果服務器相應地返回了對象所請求範圍的內容,則響應碼爲206(Partial Content),它可以防止Cache將響應誤以爲是完整的一個對象。

另外一種情況是請求消息中如果包含比較大的實體內容,但不確定服務器是否能夠接收該請求(如是否有權限),此時若貿然發出帶實體的請求,如果被拒絕也會浪費帶寬。

HTTP/1.1加入了一個新的狀態碼100(Continue)。客戶端事先發送一個只帶頭域的請求,如果服務器因爲權限拒絕了請求,就回送響應碼401(Unauthorized);如果服務器接收此請求就回送響應碼100,客戶端就可以繼續發送帶實體的完整請求了。注意,HTTP/1.0的客戶端不支持100響應碼。但可以讓客戶端在請求消息中加入Expect頭域,並將它的值設置爲100-continue。

節省帶寬資源的一個非常有效的做法就是壓縮要傳送的數據。Content-Encoding是對消息進行端到端(end-to-end)的編碼,它可能是資源在服務器上保存的固有格式(如jpeg圖片格式);在請求消息中加入Accept-Encoding頭域,它可以告訴服務器客戶端能夠解碼的編碼方式。

而Transfer-Encoding是逐段式(hop-by-hop)的編碼,如Chunked編碼。在請求消息中加入TE頭域用來告訴服務器能夠接收的transfer-coding方式,

4 長連接

HTTP 1.0規定瀏覽器與服務器只保持短暫的連接,瀏覽器的每次請求都需要與服務器建立一個TCP連接,服務器完成請求處理後立即斷開TCP連接,服務器不跟蹤每個客戶也不記錄過去的請求。此外,由於大多數網頁的流量都比較小,一次TCP連接很少能通過slow-start區,不利於提高帶寬利用率。

HTTP 1.1支持長連接(PersistentConnection)和請求的流水線(Pipelining)處理,在一個TCP連接上可以傳送多個HTTP請求和響應,減少了建立和關閉連接的消耗和延遲。例如:一個包含有許多圖像的網頁文件的多個請求和應答可以在一個連接中傳輸,但每個單獨的網頁文件的請求和應答仍然需要使用各自的連接。

HTTP 1.1還允許客戶端不用等待上一次請求結果返回,就可以發出下一次請求,但服務器端必須按照接收到客戶端請求的先後順序依次回送響應結果,以保證客戶端能夠區分出每次請求的響應內容,這樣也顯著地減少了整個下載過程所需要的時間。

在HTTP/1.0中,要建立長連接,可以在請求消息中包含Connection: Keep-Alive頭域,如果服務器願意維持這條連接,在響應消息中也會包含一個Connection: Keep-Alive的頭域。同時,可以加入一些指令描述該長連接的屬性,如max,timeout等。

事實上,Connection頭域可以攜帶三種不同類型的符號:

1、一個包含若干個頭域名的列表,聲明僅限於一次hop連接的頭域信息;

2、任意值,本次連接的非標準選項,如Keep-Alive等;

3、close值,表示消息傳送完成之後關閉長連接;

 

客戶端和源服務器之間的消息傳遞可能要經過很多中間節點的轉發,這是一種逐跳傳遞(hop-by-hop)。HTTP/1.1相應地引入了hop-by-hop頭域,這種頭域僅作用於一次hop,而非整個傳遞路徑。每一箇中間節點(如Proxy,Gateway)接收到的消息中如果包含Connection頭域,會查找Connection頭域中的一個頭域名列表,並在將消息轉發給下一個節點之前先刪除消息中這些頭域。

通常,HTTP/1.0的Proxy不支持Connection頭域,爲了不讓它們轉發可能誤導接收者的頭域,協議規定所有出現在Connection頭域中的頭域名都將被忽略。

5 消息傳遞

HTTP消息中可以包含任意長度的實體,通常它們使用Content-Length來給出消息結束標誌。但是,對於很多動態產生的響應,只能通過緩衝完整的消息來判斷消息的大小,但這樣做會加大延遲。如果不使用長連接,還可以通過連接關閉的信號來判定一個消息的結束。

HTTP/1.1中引入了Chunkedtransfer-coding來解決上面這個問題,發送方將消息分割成若干個任意大小的數據塊,每個數據塊在發送時都會附上塊的長度,最後用一個零長度的塊作爲消息結束的標誌。這種方法允許發送方只緩衝消息的一個片段,避免緩衝整個消息帶來的過載。

在HTTP/1.0中,有一個Content-MD5的頭域,要計算這個頭域需要發送方緩衝完整個消息後才能進行。而HTTP/1.1中,採用chunked分塊傳遞的消息在最後一個塊(零長度)結束之後會再傳遞一個拖尾(trailer),它包含一個或多個頭域,這些頭域是發送方在傳遞完所有塊之後再計算出值的。發送方會在消息中包含一個Trailer頭域告訴接收方這個拖尾的存在。

6 Host頭域

在HTTP1.0中認爲每臺服務器都綁定一個唯一的IP地址,因此,請求消息中的URL並沒有傳遞主機名(hostname)。但隨着虛擬主機技術的發展,在一臺物理服務器上可以存在多個虛擬主機(Multi-homed Web Servers),並且它們共享一個IP地址。

HTTP1.1的請求消息和響應消息都應支持Host頭域,且請求消息中如果沒有Host頭域會報告一個錯誤(400 Bad Request)。此外,服務器應該接受以絕對路徑標記的資源請求。

7 錯誤提示

HTTP/1.0中只定義了16個狀態響應碼,對錯誤或警告的提示不夠具體。HTTP/1.1引入了一個Warning頭域,增加對錯誤或警告信息的描述。

此外,在HTTP/1.1中新增了24個狀態響應碼,如409(Conflict)表示請求的資源與資源的當前狀態發生衝突;410(Gone)表示服務器上的某個資源被永久性的刪除。

8 內容協商

爲了滿足互聯網使用不同母語和字符集的用戶,一些網絡資源有不同的語言版本(如中文版、英文版)。HTTP/1.0定義了內容協商(contentnegotiation)的概念,也就是說客戶端可以告訴服務器自己可以接收以何種語言(或字符集)表示的資源。例如如果服務器不能明確客戶端需要何種類型的資源,會返回300(Multiple Choices),幷包含一個列表,用來聲明該資源的不同可用版本,然後客戶端在請求消息中包含Accept-Language和Accept-Charset頭域指定需要的版本。

就像有些人會說幾門外語,但每種外語的流利程度並不相同。類似地,網絡資源也可以有不同的表達形式,比如有母語版和各種翻譯版本。HTTP引入了一個品質因子(quality values)的概念來表示不同版本的可用性,它的取值從0.0到1.0。例如一個母語是英語的人也能講法語、甚至還學了點丹麥語,那麼他的瀏覽器可用作如下配置:Accept-Language: en, fr;q=0.5, da;q=0.1。這時,服務器會優先選取品質因子高的值對應的資源版本作爲響應。

 

參考資料

[1] Brian Totty, "HTTP: The DefinitiveGuide", O'REILLY & ASSOC INC, 27, Sep., 2002.

[2] B. Krishnamurthy, J. C. Mogul, and D.M. Kristol, "Key Differences between HTTP/1.0 and HTTP/1.1",http://www2.research.att.com/~bala/papers/h0vh1.html.


原文地址:http://blog.csdn.net/forgotaboutgirl/article/details/6936982

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章