[Jweb] HTTP 1.1與HTTP 1.0的比較 （from bjsxt 張志宇）

HTTP 1.1與HTTP 1.0的比較

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

圖3.3

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

爲了克服HTTP 1.0的這個缺陷，HTTP 1.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還經過增長更多的請求頭和響應頭來改進和擴充HTTP 1.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緩存等機制相關的請求頭和響應頭。

《深刻體驗Java Web開發內幕——核心基礎》

 

 

HTTP 協議老的標準是HTTP/1.0，目前最通用的標準是HTTP/1.1。HTTP/1.1是在HTTP/1.0基礎上的升級，增長了一些功能，全面兼容 HTTP/1.0。HTTP/1.0不支持文件斷點續傳，目前的Web服務器絕大多數都採用了HTTP/1.1。
RANGE:bytes是HTTP/1.1新增內容，HTTP/1.0每次傳送文件都是從文件頭開始，即0字節處開始。RANGE:bytes=XXXX表示要求服務器從文件XXXX字節處開始傳送，這就是咱們平時所說的斷點續傳！

原文英文版
RFC 1945 - Hypertext Transfer Protocol -- HTTP/1.0
http://www.w3.org/Protocols/rfc1945/rfc1945
http://www.faqs.org/rfcs/rfc1945.html

RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1
http://www.w3.org/Protocols/rfc2616/rfc2616
http://www.w3.org/Protocols/rfc2616/rfc2616.html
http://www.faqs.org/rfcs/rfc2616.html

(Proposed) HTTP-NG Working Group
http://www.w3.org/Protocols/HTTP-NG/
下 一代超文本傳輸協議(HTTP-NG)，爲了克服當前HTTP協議的缺點，W3C(World Wide Web consortium)開始研究制定下一代HTTP協議?TTP-NG。它分三個層次：應用層、消息層、傳輸層。現有WEB上應用將轉換到HTTP-NG 平臺上，最後整個平臺都會更新爲HTTP-NG。

RFC 1945 - Hypertext Transfer Protocol -- HTTP/1.0 中文版
http://man.chinaunix.net/develop/rfc/RFC1945.txt
http://www.cnpaf.net/rfc/rfc1945.txt

RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1 中文版

1.0與1.1的區別，英文版
Key Differences between HTTP/1.0 and HTTP/1.1
http://www.research.att.com/%7Ebala/papers/h0vh1.html 

中文翻譯版沒有看到，有看到的告訴我：）

附上：HTTP 1.1狀態代碼及其含義
狀態代碼  狀態信息  含義  
100  Continue  初始的請求已經接受，客戶應當繼續發送請求的其他部分。（HTTP 1.1新）  
101  Switching Protocols  服務器將聽從客戶的請求轉換到另一種協議（HTTP 1.1新）  
200  OK  一切正常，對GET和POST請求的應答文檔跟在後面。 
201  Created  服務器已經建立了文檔，Location頭給出了它的URL。  
202  Accepted  已經接受請求，但處理還沒有完成。  
203  Non-Authoritative Information  文檔已經正常地返回，但一些應答頭可能不正確，由於使用的是文檔的拷貝（HTTP 1.1新）。  
204  No Content  沒有新文檔，瀏覽器應該繼續顯示原來的文檔。若是用戶按期地刷新頁面，而Servlet能夠肯定用戶文檔足夠新，這個狀態代碼是頗有用的。  
205  Reset Content  沒有新的內容，但瀏覽器應該重置它所顯示的內容。用來強制瀏覽器清除表單輸入內容（HTTP 1.1新）。  
206  Partial Content  客戶發送了一個帶有Range頭的GET請求，服務器完成了它（HTTP 1.1新）。  
300  Multiple Choices  客戶請求的文檔能夠在多個位置找到，這些位置已經在返回的文檔內列出。若是服務器要提出優先選擇，則應該在Location應答頭指明。  
301  Moved Permanently  客戶請求的文檔在其餘地方，新的URL在Location頭中給出，瀏覽器應該自動地訪問新的URL。  
302  Found  相似於301，但新的URL應該被視爲臨時性的替代，而不是永久性的。注意，在HTTP1.0中對應的狀態信息是「Moved Temporatily」。 
出現該狀態代碼時，瀏覽器可以自動訪問新的URL，所以它是一個頗有用的狀態代碼。 

注意這個狀態代碼有時候能夠和301替換使用。例如，若是瀏覽器錯誤地請求http://host/~user（缺乏了後面的斜槓），有的服務器返回301，有的則返回302。 

嚴格地說，咱們只能假定只有當原來的請求是GET時瀏覽器纔會自動重定向。請參見307。 
 
303  See Other  相似於301/302，不一樣之處在於，若是原來的請求是POST，Location頭指定的重定向目標文檔應該經過GET提取（HTTP 1.1新）。  
304  Not Modified  客戶端有緩衝的文檔併發出了一個條件性的請求（通常是提供If-Modified-Since頭表示客戶只想比指定日期更新的文檔）。服務器告訴客戶，原來緩衝的文檔還能夠繼續使用。  
305  Use Proxy  客戶請求的文檔應該經過Location頭所指明的代理服務器提取（HTTP 1.1新）。  
307  Temporary Redirect  和302（Found）相同。許多瀏覽器會錯誤地響應302應答進行重定向，即便原來的請求是POST，即便它實際上只能在POST請求的應答是303時 才能重定向。因爲這個緣由，HTTP 1.1新增了307，以便更加清除地區分幾個狀態代碼：當出現303應答時，瀏覽器能夠跟隨重定向的GET和POST請求；若是是307應答，則瀏覽器只 能跟隨對GET請求的重定向。（HTTP 1.1新）  
400  Bad Request  請求出現語法錯誤。  
401  Unauthorized  客戶試圖未經受權訪問受密碼保護的頁面。應答中會包含一個WWW-Authenticate頭，瀏覽器據此顯示用戶名字/密碼對話框，而後在填寫合適的Authorization頭後再次發出請求。  
403  Forbidden  資源不可用。服務器理解客戶的請求，但拒絕處理它。一般因爲服務器上文件或目錄的權限設置致使。  
404  Not Found  沒法找到指定位置的資源。這也是一個經常使用的應答。  
405  Method Not Allowed  請求方法（GET、POST、HEAD、DELETE、PUT、TRACE等）對指定的資源不適用。（HTTP 1.1新）  
406  Not Acceptable  指定的資源已經找到，但它的MIME類型和客戶在Accpet頭中所指定的不兼容（HTTP 1.1新）。  
407  Proxy Authentication Required  相似於401，表示客戶必須先通過代理服務器的受權。（HTTP 1.1新）  
408  Request Timeout  在服務器許可的等待時間內，客戶一直沒有發出任何請求。客戶能夠在之後重複同一請求。（HTTP 1.1新）  
409  Conflict  一般和PUT請求有關。因爲請求和資源的當前狀態相沖突，所以請求不能成功。（HTTP 1.1新）  
410  Gone  所請求的文檔已經再也不可用，並且服務器不知道應該重定向到哪個地址。它和404的不一樣在於，返回407表示文檔永久地離開了指定的位置，而404表示因爲未知的緣由文檔不可用。（HTTP 1.1新）  
411  Length Required  服務器不能處理請求，除非客戶發送一個Content-Length頭。（HTTP 1.1新）  
412  Precondition Failed  請求頭中指定的一些前提條件失敗（HTTP 1.1新）。  
413  Request Entity Too Large  目標文檔的大小超過服務器當前願意處理的大小。若是服務器認爲本身可以稍後再處理該請求，則應該提供一個Retry-After頭（HTTP 1.1新）。  
414  Request URI Too Long  URI太長（HTTP 1.1新）。  
416  Requested Range Not Satisfiable  服務器不能知足客戶在請求中指定的Range頭。（HTTP 1.1新）  
500  Internal Server Error  服務器遇到了意料不到的狀況，不能完成客戶的請求。  
501  Not Implemented  服務器不支持實現請求所須要的功能。例如，客戶發出了一個服務器不支持的PUT請求。  
502  Bad Gateway  服務器做爲網關或者代理時，爲了完成請求訪問下一個服務器，但該服務器返回了非法的應答。  
503  Service Unavailable  服務器因爲維護或者負載太重未能應答。例如，Servlet可能在數據庫鏈接池已滿的狀況下返回503。服務器返回503時能夠提供一個Retry-After頭。  
504  Gateway Timeout  由做爲代理或網關的服務器使用，表示不能及時地從遠程服務器得到應答。（HTTP 1.1新）  
505  HTTP Version Not Supported  服務器不支持請求中所指明的HTTP版本。（HTTP 1.1新）  

===================================================================================
更多的資源......
http://www.w3.org/
中國協議分析網 http://www.cnpaf.net/

用Socket類實現HTTP協議客戶端應用
http://developer.51cto.com/art/200510/6751.htm

用Java設計下載軟件
http://www.yesky.com/239/1739739.shtml 使用多線程編程技術，同時啓動多個線程，根據線程個數，計算文件分割位置，向服務器發送幾個不一樣的下載斷點，同時接受數據並寫入文件，就能夠實現多線程下載了。