翻了下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頭域可以攜帶三種不同類型的符號：
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頭域，該頭域列出了請求消息中需要包含哪些頭域用于內容協商。
依據：
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還允許客戶端不用等待上一次請求結果返回，就可以發出下一次請求，但服務器端必須按照接收到客戶端請求的先后順序依次回送響應結果，以保證客戶端能夠區分出每次請求的響應內容，這樣也顯著地減少了整個下載過程所需要的時間?；贖TTP 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緩存等機制相關的請求頭和響應頭。
轉自：http://blog.csdn.net/hguisu/article/details/8608888
原創文章，作者：s19930811，如若轉載，請注明出處：http://www.www58058.com/2647
