翻了下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的持續連線，也需要增加新的請求頭來幫助實現，例如，

        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頭域可以攜帶三種不同型別的符號：

       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頭域中的頭域名都將被忽略。

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

依據：

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

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快取等機制相關的請求頭和響應頭。