HTTP詳解(3)-http1.0 和http1.1 區別

翻了下HTTP1.1的協議標準RFC2616，下面是看到的一些它跟HTTP1.0的差異。

1. Persistent Connection持久鏈接

       在HTTP1.0中，每對Request/Response都使用一個新的鏈接。

        HTTP 1.1則支持持久鏈接Persistent Connection, 而且默認使用persistent  connection. 在同一個tcp的鏈接中能夠傳送多個HTTP請求和響應. 多個請求和響應能夠重疊，多個請求和響應能夠同時進行. 更加多的請求頭和響應頭(好比HTTP1.0沒有host的字段).

        HTTP 1.1的持續鏈接，也須要增長新的請求頭來幫助實現，例如，Connection請求頭的值爲Keep-Alive時，客戶端通知服務器返回本次請求結果後保持鏈接；Connection請求頭的值爲close時，客戶端通知服務器返回本次請求結果後關閉鏈接。HTTP 1.1還提供了與身份認證、狀態管理和Cache緩存等機制相關的請求頭和響應頭。

        HTTP 1.0規定瀏覽器與服務器只保持短暫的鏈接，瀏覽器的每次請求都須要與服務器創建一個TCP鏈接，服務器完成請求處理後當即斷開TCP鏈接，服務器不跟蹤每一個客戶也不記錄過去的請求。此外，因爲大多數網頁的流量都比較小，一次TCP鏈接不多能經過slow-start區，不利於提升帶寬利用率。

        在1.0時的會話方式：
       1. 創建鏈接
       2. 發出請求信息
       3. 回送響應信息
       4. 關掉鏈接

       小結:瀏覽器和web服務器鏈接很短，每次鏈接只處理一個請求和響應。對每個頁的請求,瀏覽器與web服務器都要創建一次單獨的鏈接.瀏覽器沒有 關掉前,鏈接就斷開了.瀏覽器和服務器之間的通訊是徹底獨立分開的請求和響應對.由於這樣無法斷點瀏覽器是否斷開,無法作鏈接狀態控制。創建和關掉鏈接會很佔用鏈接時間.

      在一個網頁中,在http頭中的Connection中有多少個close的頭,就至關有多少個http的鏈接.

      HTTP 1.1支持長鏈接（PersistentConnection）和請求的流水線（Pipelining）處理，在一個TCP鏈接上能夠傳送多個HTTP請求和響應，減小了創建和關閉鏈接的消耗和延遲。例如：一個包含有許多圖像的網頁文件的多個請求和應答能夠在一個鏈接中傳輸，但每一個單獨的網頁文件的請求和應答仍然須要使用各自的鏈接。

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

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

       事實上，Connection頭域能夠攜帶三種不一樣類型的符號：

       一、一個包含若干個頭域名的列表，聲明僅限於一次hop鏈接的頭域信息；

       二、任意值，本次鏈接的非標準選項，如Keep-Alive等；

        三、close值，表示消息傳送完成以後關閉長鏈接；

 

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

        一般，HTTP/1.0的Proxy不支持Connection頭域，爲了避免讓它們轉發可能誤導接收者的頭域，協議規定全部出如今Connection頭域中的頭域名都將被忽略。

2. Host域

       在HTTP1.0中認爲每臺服務器都綁定一個惟一的IP地址，所以，請求消息中的URL並無傳遞主機名（hostname）。但隨着虛擬主機技術的發展，在一臺物理服務器上能夠存在多個虛擬主機（Multi-homed Web Servers），而且它們共享一個IP地址。

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

        HTTP1.1在Request消息頭裏頭多了一個Host域，好比：

       GET /pub/WWW/TheProject.html HTTP/1.1

       Host: www.w3.org

       HTTP1.0則沒有這個域。

       可能HTTP1.0的時候認爲，創建TCP鏈接的時候已經指定了IP地址，這個IP地址上只有一個host。

       因爲HTTP 1.0不支持Host請求頭字段，WEB瀏覽器沒法使用主機頭名來明確表示要訪問服務器上的哪一個WEB站點，這樣就沒法使用WEB服務器在同一個IP地址和端口號上配置多個虛擬WEB站點。在HTTP 1.1中增長Host請求頭字段後，WEB瀏覽器可使用主機頭名來明確表示要訪問服務器上的哪一個WEB站點，這才實現了在一臺WEB服務器上能夠在同一個IP地址和端口號上使用不一樣的主機名來建立多個虛擬WEB站點。

 

3. date/timestamp (日期時間戳)

(接收方向)

不管是HTTP1.0仍是HTTP1.1，都要能解析下面三種date/time stamp：

      Sun, 06 Nov 1994 08:49:37GMT  ; RFC 822, updated by RFC 1123

      Sunday, 06-Nov-94 08:49:37GMT ; RFC 850, obsoleted by RFC 1036

      Sun Nov  6 08:49:371994       ; ANSI C's asctime() format

(發送方向)
   HTTP1.0要求不能生成第三種asctime格式的date/time stamp；

    HTTP1.1則要求只生成RFC 1123(第一種)格式的date/time stamp。

4. Transfer Codings

HTTP1.1支持chunked transfer，因此能夠有Transfer-Encoding頭部域:

Transfer-Encoding:chunked

 HTTP1.0則沒有。

HTTP消息中能夠包含任意長度的實體，一般它們使用Content-Length來給出消息結束標誌。可是，對於不少動態產生的響應，只能經過緩衝完整的消息來判斷消息的大小，但這樣作會加大延遲。若是不使用長鏈接，還能夠經過鏈接關閉的信號來斷定一個消息的結束。

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

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

5. Quality Values

 HTTP1.1多了個qvalue域：

      qvalue         = ( "0" ["." 0*3DIGIT ] )

                     | ( "1" [ "." 0*3("0") ] )

 

6. Entity Tags

用於Cache。

 

7. Range 和 Content-Range(節約優化)

       HTTP1.1支持傳送內容的一部分。比方說，當客戶端已經有內容的一部分，爲了節省帶寬，能夠只向服務器請求一部分。

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

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

       

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

       而Transfer-Encoding是逐段式（hop-by-hop）的編碼，如Chunked編碼。在請求消息中加入TE頭域用來告訴服務器可以接收的transfer-coding方式，

8. 100(Continue) Status(節約帶寬)

       另一種浪費帶寬的狀況是請求消息中若是包含比較大的實體內容，但不肯定服務器是否可以接收該請求（如是否有權限），此時若貿然發出帶實體的請求，若是被拒絕也會浪費帶寬。

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

      100 (Continue) 狀態代碼的使用，容許客戶端在發request消息body以前先用request header試探一下server，看server要不要接收request body，再決定要不要發request body。

客戶端在Request頭部中包含

Expect: 100-continue

Server看到以後呢若是回100 (Continue) 這個狀態代碼，客戶端就繼續發requestbody。

這個是HTTP1.1纔有的。

9. Request method

     HTTP1.1增長了OPTIONS,PUT, DELETE, TRACE, CONNECT這些Request方法.

      Method   ="OPTIONS"               ;Section 9.2

                     |"GET"                   ; Section 9.3

                     |"HEAD"                  ; Section 9.4

                     |"POST"                  ; Section 9.5

                     | "PUT"                   ;Section 9.6

                     | "DELETE"                ;Section 9.7

                     |"TRACE"                 ; Section 9.8

                     | "CONNECT"               ;Section 9.9

                     | extension-method

       extension-method =token

10. Status code

  HTTP1.1 增長的新的status code：

 

(HTTP1.0沒有定義任何具體的1xx status code, HTTP1.1有2個)

100 Continue

101 Switching Protocols

 

203 Non-Authoritative Information

205 Reset Content

206 Partial Content

 

302 Found (在HTTP1.0中有個 302 Moved Temporarily)

303 See Other

305 Use Proxy

307 Temporary Redirect

 

405 Method Not Allowed

406 Not Acceptable

407 Proxy Authentication Required

408 Request Timeout

409 Conflict

410 Gone

411 Length Required

412 Precondition Failed

413 Request Entity Too Large

414 Request-URI Too Long

415 Unsupported Media Type

416 Requested Range Not Satisfiable

417 Expectation Failed

 

504 Gateway Timeout

505 HTTP Version Not Supported

11. Cache (緩存)

       在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頭域，該頭域列出了請求消息中須要包含哪些頭域用於內容協商。

依據：

rfc2616Hypertext Transfer Protocol -- HTTP-1.1.txt

rfc1945Hypertext Transfer Protocol -- HTTP 1.0.txt

求消息中須要包含哪些頭域用於內容協商。

HTTP 1.1持久鏈接的好處

        一個WEB站點天天可能要接收到上百萬的用戶請求，爲了提升系統的效率，HTTP 1.0規定瀏覽器與服務器只保持短暫的鏈接，瀏覽器的每次請求都須要與服務器創建一個TCP鏈接，服務器完成請求處理後當即斷開TCP鏈接，服務器不跟蹤每一個客戶也不記錄過去的請求。可是，這也形成了一些性能上的缺陷，例如，一個包含有許多圖像的網頁文件中並無包含真正的圖像數據內容，而只是指明瞭這些圖像的URL地址，當WEB瀏覽器訪問這個網頁文件時，瀏覽器首先要發出針對該網頁文件的請求，當瀏覽器解析WEB服務器返回的該網頁文檔中的HTML內容時，發現其中的<img>圖像標籤後，瀏覽器將根據<img>標籤中的src屬性所指定的URL地址再次向服務器發出下載圖像數據的請求，如圖3.3所示。

                  

 

圖3.3

      顯然，訪問一個包含有許多圖像的網頁文件的整個過程包含了屢次請求和響應，每次請求和響應都須要創建一個單獨的鏈接，每次鏈接只是傳輸一個文檔和圖像，上一 次和下一次請求徹底分離。即便圖像文件都很小，可是客戶端和服務器端每次創建和關閉鏈接倒是一個相對比較費時的過程，而且會嚴重影響客戶機和服務器的性 能。當一個網頁文件中包含Applet，JavaScript文件，CSS文件等內容時，也會出現相似上述的狀況。

        爲了克服HTTP 1.0的這個缺陷，HTTP1.1支持持久鏈接，在一個TCP鏈接上能夠傳送多個HTTP請求和響應，減小了創建和關閉鏈接的消耗和延遲。一個包含有許多圖像的網頁文件的多個請求和應答能夠在一個鏈接中傳輸，但每一個單獨的網頁文件的請求和應答仍然須要使用各自的鏈接。HTTP 1.1還容許客戶端不用等待上一次請求結果返回，就能夠發出下一次請求，但服務器端必須按照接收到客戶端請求的前後順序依次回送響應結果，以保證客戶端可以區分出每次請求的響應內容，這樣也顯著地減小了整個下載過程所須要的時間。基於HTTP 1.1協議的客戶機與服務器的信息交換過程，如圖3.4所示。

          

圖3.4

        可見，HTTP 1.1在繼承了HTTP 1.0優勢的基礎上，也克服了HTTP 1.0的性能問題。不只如此，HTTP 1.1還經過增長更多的請求頭和響應頭來改進和擴充HTTP1.0的功能。例如，因爲HTTP 1.0不支持Host請求頭字段，WEB瀏覽器沒法使用主機頭名來明確表示要訪問服務器上的哪一個WEB站點，這樣就沒法使用WEB服務器在同一個IP地址和端口號上配置多個虛擬WEB站點。在HTTP 1.1中增長Host請求頭字段後，WEB瀏覽器可使用主機頭名來明確表示要訪問服務器上的哪一個WEB站點，這才實現了在一臺WEB服務器上能夠在同一個IP地址和端口號上使用不一樣的主機名來建立多個虛擬WEB站點。HTTP 1.1的持續鏈接，也須要增長新的請求頭來幫助實現，例如，Connection請求頭的值爲Keep-Alive時，客戶端通知服務器返回本次請求結果後保持鏈接；Connection請求頭的值爲close時，客戶端通知服務器返回本次請求結果後關閉鏈接。HTTP 1.1還提供了與身份認證、狀態管理和Cache緩存等機制相關的請求頭和響應頭。