http協(xié)議學習系列

1. 基礎(chǔ)概念篇

1.1 介紹

  HTTP是Hyper Text Transfer Protocol（超文本傳輸協(xié)議）的縮寫。它的發(fā)展是萬維網(wǎng)協(xié)會（World Wide Web Consortium）和Internet工作小組IETF（Internet Engineering Task Force）合作的結(jié)果，（他們）最終發(fā)布了一系列的RFC，RFC 1945定義了HTTP/1.0版本。其中最著名的就是RFC 2616。RFC 2616定義了今天普遍使用的一個版本——HTTP 1.1。 HTTP協(xié)議（HyperText Transfer Protocol，超文本傳輸協(xié)議）是用于從WWW服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。它可以使瀏覽器更加高效，使網(wǎng)絡(luò)傳輸減少。它不僅保證計算機正確快速地傳輸超文本文檔，還確定傳輸文檔中的哪一部分，以及哪部分內(nèi)容首先顯示(如文本先于圖形)等。 HTTP是一個應(yīng)用層協(xié)議，由請求和響應(yīng)構(gòu)成，是一個標準的客戶端服務(wù)器模型。HTTP是一個無狀態(tài)的協(xié)議。

1.2 在TCP/IP協(xié)議棧中的位置

HTTP協(xié)議通常承載于TCP協(xié)議之上，有時也承載于TLS或SSL協(xié)議層之上，這個時候，就成了我們常說的HTTPS。如下圖所示：
   
默認HTTP的端口號為80，HTTPS的端口號為443。

1.3 HTTP的請求響應(yīng)模型

HTTP協(xié)議永遠都是客戶端發(fā)起請求，服務(wù)器回送響應(yīng)。見下圖：
   
這樣就限制了使用HTTP協(xié)議，無法實現(xiàn)在客戶端沒有發(fā)起請求的時候，服務(wù)器將消息推送給客戶端。 HTTP協(xié)議是一個無狀態(tài)的協(xié)議，同一個客戶端的這次請求和上次請求是沒有對應(yīng)關(guān)系。

1.4 工作流程

一次HTTP操作稱為一個事務(wù)，其工作過程可分為四步： 1）首先客戶機與服務(wù)器需要建立連接。只要單擊某個超級鏈接，HTTP的工作開始。 2）建立連接后，客戶機發(fā)送一個請求給服務(wù)器，請求方式的格式為：統(tǒng)一資源標識符（URL）、協(xié)議版本號，后邊是MIME信息包括請求修飾符、客戶機信息和可能的內(nèi)容。 3）服務(wù)器接到請求后，給予相應(yīng)的響應(yīng)信息，其格式為一個狀態(tài)行，包括信息的協(xié)議版本號、一個成功或錯誤的代碼，后邊是MIME信息包括服務(wù)器信息、實體信息和可能的內(nèi)容。 4）客戶端接收服務(wù)器所返回的信息通過瀏覽器顯示在用戶的顯示屏上，然后客戶機與服務(wù)器斷開連接。 如果在以上過程中的某一步出現(xiàn)錯誤，那么產(chǎn)生錯誤的信息將返回到客戶端，有顯示屏輸出。對于用戶來說，這些過程是由HTTP自己完成的，用戶只要用鼠標點擊，等待信息顯示就可以了。

1.5 使用Wireshark抓TCP、http包

打開Wireshark，選擇工具欄上的“Capture”->“Options”，界面選擇如圖1所示：
                            
圖1 設(shè)置Capture選項 一般讀者只需要選擇最上邊的下拉框，選擇合適的Device，而后點擊“Capture Filter”，此處選擇的是“HTTP TCP port（80）”，選擇后點擊上圖的“Start”開始抓包。
                                 
圖2 選擇Capture Filter 例如在瀏覽器中打開http://image.baidu.com/，抓包如圖3所示：
    http://image15.360doc.com/DownloadImg/2010/09/3017/5657919_5.jpg

圖3   抓包 在上圖中，可清晰的看到客戶端瀏覽器（ip為192.168.2.33）與服務(wù)器的交互過程： 1）No1：瀏覽器（192.168.2.33）向服務(wù)器（220.181.50.118）發(fā)出連接請求。此為TCP三次握手第一步，此時從圖中可以看出，為SYN，seq:X （x=0） 2）No2：服務(wù)器（220.181.50.118）回應(yīng)了瀏覽器（192.168.2.33）的請求，并要求確認，此時為：SYN，ACK，此時seq：y（y為0），ACK：x+1（為1）。此為三次握手的第二步； 3）No3：瀏覽器（192.168.2.33）回應(yīng)了服務(wù)器（220.181.50.118）的確認，連接成功。為：ACK，此時seq：x+1（為1），ACK：y+1（為1）。此為三次握手的第三步； 4）No4：瀏覽器（192.168.2.33）發(fā)出一個頁面HTTP請求； 5）No5：服務(wù)器（220.181.50.118）確認； 6）No6：服務(wù)器（220.181.50.118）發(fā)送數(shù)據(jù)； 7）No7：客戶端瀏覽器（192.168.2.33）確認； 8）No14：客戶端（192.168.2.33）發(fā)出一個圖片HTTP請求； 9）No15：服務(wù)器（220.181.50.118）發(fā)送狀態(tài)響應(yīng)碼200 OK ……

1.6 頭域

每個頭域由一個域名，冒號（:）和域值三部分組成。域名是大小寫無關(guān)的，域值前可以添加任何數(shù)量的空格符，頭域可以被擴展為多行，在每行開始處，使用至少一個空格或制表符。 在抓包的圖中，No14點開可看到如圖4所示：
   http://image15.360doc.com/DownloadImg/2010/09/3017/5657919_6.jpg

圖4 http請求消息        回應(yīng)的消息如圖5所示：
              
圖5 http狀態(tài)響應(yīng)信息

1.6.1 host頭域

Host頭域指定請求資源的Intenet主機和端口號，必須表示請求url的原始服務(wù)器或網(wǎng)關(guān)的位置。HTTP/1.1請求必須包含主機頭域，否則系統(tǒng)會以400狀態(tài)碼返回。 圖5中host那行為：
   

1.6.2 Referer頭域

Referer頭域允許客戶端指定請求uri的源資源地址，這可以允許服務(wù)器生成回退鏈表，可用來登陸、優(yōu)化cache等。他也允許廢除的或錯誤的連接由于維護的目的被追蹤。如果請求的uri沒有自己的uri地址，Referer不能被發(fā)送。如果指定的是部分uri地址，則此地址應(yīng)該是一個相對地址。 在圖4中，Referer行的內(nèi)容為：
   

1.6.3 User-Agent頭域

User-Agent頭域的內(nèi)容包含發(fā)出請求的用戶信息。 在圖4中，User-Agent行的內(nèi)容為：
   http://www./images/blogjava_net/amigoxie/40799/o_http%e5%8d%8f%e8%ae%ae%e5%ad%a6%e4%b9%a0-%e6%a6%82%e5%bf%b5-8.jpg

1.6.4 Cache-Control頭域

Cache-Control指定請求和響應(yīng)遵循的緩存機制。在請求消息或響應(yīng)消息中設(shè)置Cache-Control并不會修改另一個消息處理過程中的緩存處理過程。請求時的緩存指令包括no-cache、no-store、max-age、max-stale、min-fresh、only-if-cached，響應(yīng)消息中的指令包括public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age。 在圖5中的該頭域為：
   

1.6.5 Date頭域

Date頭域表示消息發(fā)送的時間，時間的描述格式由rfc822定義。例如，Date:Mon,31Dec200104:25:57GMT。Date描述的時間表示世界標準時，換算成本地時間，需要知道用戶所在的時區(qū)。 圖5中，該頭域如下圖所示：
  
 

1.7 HTTP的幾個重要概念

1.7.1連接：Connection

一個傳輸層的實際環(huán)流，它是建立在兩個相互通訊的應(yīng)用程序之間。 在http1.1，request和reponse頭中都有可能出現(xiàn)一個connection的頭，此header的含義是當client和server通信時對于長鏈接如何進行處理。 在http1.1中，client和server都是默認對方支持長鏈接的， 如果client使用http1.1協(xié)議，但又不希望使用長鏈接，則需要在header中指明connection的值為close；如果server方也不想支持長鏈接，則在response中也需要明確說明connection的值為close。不論request還是response的header中包含了值為close的connection，都表明當前正在使用的tcp鏈接在當天請求處理完畢后會被斷掉。以后client再進行新的請求時就必須創(chuàng)建新的tcp鏈接了。

1.7.2消息：Message

HTTP通訊的基本單位，包括一個結(jié)構(gòu)化的八元組序列并通過連接傳輸。

1.7.3請求：Request

一個從客戶端到服務(wù)器的請求信息包括應(yīng)用于資源的方法、資源的標識符和協(xié)議的版本號。

1.7.4響應(yīng)：Response

一個從服務(wù)器返回的信息包括HTTP協(xié)議的版本號、請求的狀態(tài)(例如“成功”或“沒找到”)和文檔的MIME類型。

1.7.5資源：Resource

由URI標識的網(wǎng)絡(luò)數(shù)據(jù)對象或服務(wù)。

1.7.6實體：Entity

數(shù)據(jù)資源或來自服務(wù)資源的回映的一種特殊表示方法，它可能被包圍在一個請求或響應(yīng)信息中。一個實體包括實體頭信息和實體的本身內(nèi)容。

1.7.7客戶機：Client

一個為發(fā)送請求目的而建立連接的應(yīng)用程序。

1.7.8用戶代理：UserAgent

初始化一個請求的客戶機。它們是瀏覽器、編輯器或其它用戶工具。

1.7.9服務(wù)器：Server

一個接受連接并對請求返回信息的應(yīng)用程序。

1.7.10源服務(wù)器：Originserver

是一個給定資源可以在其上駐留或被創(chuàng)建的服務(wù)器。

1.7.11代理：Proxy

一個中間程序，它可以充當一個服務(wù)器，也可以充當一個客戶機，為其它客戶機建立請求。請求是通過可能的翻譯在內(nèi)部或經(jīng)過傳遞到其它的服務(wù)器中。一個代理在發(fā)送請求信息之前，必須解釋并且如果可能重寫它。 代理經(jīng)常作為通過防火墻的客戶機端的門戶，代理還可以作為一個幫助應(yīng)用來通過協(xié)議處理沒有被用戶代理完成的請求。

1.7.12網(wǎng)關(guān)：Gateway

一個作為其它服務(wù)器中間媒介的服務(wù)器。與代理不同的是，網(wǎng)關(guān)接受請求就好象對被請求的資源來說它就是源服務(wù)器；發(fā)出請求的客戶機并沒有意識到它在同網(wǎng)關(guān)打交道。 網(wǎng)關(guān)經(jīng)常作為通過防火墻的服務(wù)器端的門戶，網(wǎng)關(guān)還可以作為一個協(xié)議翻譯器以便存取那些存儲在非HTTP系統(tǒng)中的資源。

1.7.13通道：Tunnel

是作為兩個連接中繼的中介程序。一旦激活，通道便被認為不屬于HTTP通訊，盡管通道可能是被一個HTTP請求初始化的。當被中繼的連接兩端關(guān)閉時，通道便消失。當一個門戶(Portal)必須存在或中介(Intermediary)不能解釋中繼的通訊時通道被經(jīng)常使用。

1.7.14緩存：Cache

反應(yīng)信息的局域存儲。

    附錄：參考資料

《http_百度百科》：http://baike.baidu.com/view/9472.htm 《結(jié)果編碼和http狀態(tài)響應(yīng)碼》：http://blog./archives/377 《分析TCP的三次握手》： http://cache.baidu.com/c?m=9f65cb4a8c8507ed4fece763104c8c711923d030678197027fa3c215cc7905141130a8e5747e0d548d98297a5ae91e03f7f63772315477e3cacdd94cdbbdc42225d82c36734f844315c419d891007a9f34d507a9f916a2e1b065d2f48193864353bb15543897f1fb4d711edd1b86033093b1e94e022e67adec40728e2e605f983431c5508fe4&p=c6769a46c5820efd08e2973b42&user=baidu 《使用Wireshark來檢測一次HTTP連接過程》： http://blog.163.com/wangbo_tester/blog/static/12806792120098174162288/ 《http協(xié)議的幾個重要概念》：http://nc.mofcom.gov.cn/news/10819972.html 《http協(xié)議中connection頭的作用》：        http://blog.csdn.net/barfoo/archive/2008/06/05/2514667.aspx 

2. 協(xié)議詳解篇

2.1 HTTP/1.0和HTTP/1.1的比較

RFC 1945定義了HTTP/1.0版本，RFC 2616定義了HTTP/1.1版本。 筆者在blog上提供了這兩個RFC中文版的下載地址。 RFC1945下載地址： http://www./Files/amigoxie/RFC1945（HTTP）中文版.rar RFC2616下載地址： http://www./Files/amigoxie/RFC2616（HTTP）中文版.rar

2.1.1建立連接方面

HTTP/1.0 每次請求都需要建立新的TCP連接，連接不能復用。HTTP/1.1 新的請求可以在上次請求建立的TCP連接之上發(fā)送，連接可以復用。優(yōu)點是減少重復進行TCP三次握手的開銷，提高效率。 注意：在同一個TCP連接中，新的請求需要等上次請求收到響應(yīng)后，才能發(fā)送。

2.1.2 Host域

HTTP1.1在Request消息頭里頭多了一個Host域, HTTP1.0則沒有這個域。 Eg：     可能HTTP1.0的時候認為，建立TCP連接的時候已經(jīng)指定了IP地址，這個IP地址上只有一個host。

2.1.3日期時間戳

(接收方向) 無論是HTTP1.0還是HTTP1.1，都要能解析下面三種date/time stamp：        (發(fā)送方向) HTTP1.0要求不能生成第三種asctime格式的date/time stamp； HTTP1.1則要求只生成RFC 1123(第一種)格式的date/time stamp。

2.1.4狀態(tài)響應(yīng)碼

狀態(tài)響應(yīng)碼100 (Continue) 狀態(tài)代碼的使用，允許客戶端在發(fā)request消息body之前先用request header試探一下server，看server要不要接收request body，再決定要不要發(fā)request body。 客戶端在Request頭部中包含        Server看到之后呢如果回100 (Continue) 這個狀態(tài)代碼，客戶端就繼續(xù)發(fā)request body。這個是HTTP1.1才有的。 另外在HTTP/1.1中還增加了101、203、205等等性狀態(tài)響應(yīng)碼

2.1.5請求方式

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

2.2 HTTP請求消息

2.2.1請求消息格式

請求消息格式如下所示： 請求行 通用信息頭|請求頭|實體頭 CRLF(回車換行) 實體內(nèi)容 其中“請求行”為：請求行 = 方法 [空格] 請求URI [空格] 版本號 [回車換行] 請求行實例： Eg1：        Eg2： POST http://192.168.2.217:8080/index.jsp HTTP/1.1 HTTP請求消息實例：

2.2.2請求方法

       HTTP的請求方法包括如下幾種： q      GET q      POST q      HEAD q      PUT q      DELETE q      OPTIONS q      TRACE q      CONNECT

2.3 HTTP響應(yīng)消息

2.3.1響應(yīng)消息格式

HTTP響應(yīng)消息的格式如下所示： 狀態(tài)行 通用信息頭|響應(yīng)頭|實體頭 CRLF 實體內(nèi)容 其中：狀態(tài)行 = 版本號 [空格] 狀態(tài)碼 [空格] 原因 [回車換行] 狀態(tài)行舉例： Eg1：       Eg2：      HTTP響應(yīng)消息實例如下所示： 2.3.2 http的狀態(tài)響應(yīng)碼

2.3.2.1  1**：請求收到，繼續(xù)處理

100——客戶必須繼續(xù)發(fā)出請求 101——客戶要求服務(wù)器根據(jù)請求轉(zhuǎn)換HTTP協(xié)議版本

2.3.2.2  2**：操作成功收到，分析、接受

200——交易成功
201——提示知道新文件的URL 202——接受和處理、但處理未完成 203——返回信息不確定或不完整 204——請求收到，但返回信息為空 205——服務(wù)器完成了請求，用戶代理必須復位當前已經(jīng)瀏覽過的文件 206——服務(wù)器已經(jīng)完成了部分用戶的GET請求

2.3.2.3  3**：完成此請求必須進一步處理

300——請求的資源可在多處得到 301——刪除請求數(shù)據(jù) 302——在其他地址發(fā)現(xiàn)了請求數(shù)據(jù) 303——建議客戶訪問其他URL或訪問方式 304——客戶端已經(jīng)執(zhí)行了GET，但文件未變化 305——請求的資源必須從服務(wù)器指定的地址得到 306——前一版本HTTP中使用的代碼，現(xiàn)行版本中不再使用 307——申明請求的資源臨時性刪除

2.3.2.4  4**：請求包含一個錯誤語法或不能完成

400——錯誤請求，如語法錯誤 401——未授權(quán) HTTP 401.1 - 未授權(quán)：登錄失敗 　　HTTP 401.2 - 未授權(quán)：服務(wù)器配置問題導致登錄失敗 　　HTTP 401.3 - ACL 禁止訪問資源 　　HTTP 401.4 - 未授權(quán)：授權(quán)被篩選器拒絕 HTTP 401.5 - 未授權(quán)：ISAPI 或 CGI 授權(quán)失敗 402——保留有效ChargeTo頭響應(yīng) 403——禁止訪問 HTTP 403.1 禁止訪問：禁止可執(zhí)行訪問 　　HTTP 403.2 - 禁止訪問：禁止讀訪問 　　HTTP 403.3 - 禁止訪問：禁止寫訪問 　　HTTP 403.4 - 禁止訪問：要求 SSL 　　HTTP 403.5 - 禁止訪問：要求 SSL 128 　　HTTP 403.6 - 禁止訪問：IP 地址被拒絕 　　HTTP 403.7 - 禁止訪問：要求客戶證書 　　HTTP 403.8 - 禁止訪問：禁止站點訪問 　　HTTP 403.9 - 禁止訪問：連接的用戶過多 　　HTTP 403.10 - 禁止訪問：配置無效 　　HTTP 403.11 - 禁止訪問：密碼更改 　　HTTP 403.12 - 禁止訪問：映射器拒絕訪問 　　HTTP 403.13 - 禁止訪問：客戶證書已被吊銷 　　HTTP 403.15 - 禁止訪問：客戶訪問許可過多 　　HTTP 403.16 - 禁止訪問：客戶證書不可信或者無效 HTTP 403.17 - 禁止訪問：客戶證書已經(jīng)到期或者尚未生效 404——沒有發(fā)現(xiàn)文件、查詢或URl 405——用戶在Request-Line字段定義的方法不允許 406——根據(jù)用戶發(fā)送的Accept拖，請求資源不可訪問 407——類似401，用戶必須首先在代理服務(wù)器上得到授權(quán) 408——客戶端沒有在用戶指定的餓時間內(nèi)完成請求 409——對當前資源狀態(tài)，請求不能完成 410——服務(wù)器上不再有此資源且無進一步的參考地址 411——服務(wù)器拒絕用戶定義的Content-Length屬性請求 412——一個或多個請求頭字段在當前請求中錯誤 413——請求的資源大于服務(wù)器允許的大小 414——請求的資源URL長于服務(wù)器允許的長度 415——請求資源不支持請求項目格式 416——請求中包含Range請求頭字段，在當前請求資源范圍內(nèi)沒有range指示值，請求也不包含If-Range請求頭字段 417——服務(wù)器不滿足請求Expect頭字段指定的期望值，如果是代理服務(wù)器，可能是下一級服務(wù)器不能滿足請求長。

2.3.2.5  5**：服務(wù)器執(zhí)行一個完全有效請求失敗

　　HTTP 500 - 內(nèi)部服務(wù)器錯誤 　　HTTP 500.100 - 內(nèi)部服務(wù)器錯誤 - ASP 錯誤 　　HTTP 500-11 服務(wù)器關(guān)閉 　　HTTP 500-12 應(yīng)用程序重新啟動 　　HTTP 500-13 - 服務(wù)器太忙 　　HTTP 500-14 - 應(yīng)用程序無效 　　HTTP 500-15 - 不允許請求 global.asa 　　Error 501 - 未實現(xiàn) HTTP 502 - 網(wǎng)關(guān)錯誤

2.4 使用telnet進行http測試

       在Windows下，可使用命令窗口進行http簡單測試。        輸入cmd進入命令窗口，在命令行鍵入如下命令后按回車：        而后在窗口中按下“Ctrl+]”后按回車可讓返回結(jié)果回顯。 接著開始發(fā)請求消息，例如發(fā)送如下請求消息請求baidu的首頁消息，使用的HTTP協(xié)議為HTTP/1.1：    注意：copy如上的消息到命令窗口后需要按兩個回車換行才能得到響應(yīng)的消息，第一個回車換行是在命令后鍵入回車換行，是HTTP協(xié)議要求的。第二個是確認輸入，發(fā)送請求。 可看到返回了200 OK的消息，如下圖所示：

       可看到，當采用HTTP/1.1時，連接不是在請求結(jié)束后就斷開的。若采用HTTP1.0，在命令窗口鍵入：       此時可以看到請求結(jié)束之后馬上斷開。        讀者還可以嘗試在使用GET或POST等時，帶上頭域信息，例如鍵入如下信息： 2.5 常用的請求方式        常用的請求方式是GET和POST. l         GET方式：是以實體的方式得到由請求URI所指定資源的信息，如果請求URI只是一個數(shù)據(jù)產(chǎn)生過程，那么最終要在響應(yīng)實體中返回的是處理過程的結(jié)果所指向的資源，而不是處理過程的描述。 l         POST方式：用來向目的服務(wù)器發(fā)出請求，要求它接受被附在請求后的實體，并把它當作請求隊列中請求URI所指定資源的附加新子項，Post被設(shè)計成用統(tǒng)一的方法實現(xiàn)下列功能： 1：對現(xiàn)有資源的解釋； 2：向電子公告欄、新聞組、郵件列表或類似討論組發(fā)信息； 3：提交數(shù)據(jù)塊； 4：通過附加操作來擴展數(shù)據(jù)庫 。 從上面描述可以看出，Get是向服務(wù)器發(fā)索取數(shù)據(jù)的一種請求；而Post是向服務(wù)器提交數(shù)據(jù)的一種請求，要提交的數(shù)據(jù)位于信息頭后面的實體中。 GET與POST方法有以下區(qū)別： （1）   在客戶端，Get方式在通過URL提交數(shù)據(jù)，數(shù)據(jù)在URL中可以看到；POST方式，數(shù)據(jù)放置在HTML HEADER內(nèi)提交。 （2）   GET方式提交的數(shù)據(jù)最多只能有1024字節(jié)，而POST則沒有此限制。 （3）   安全性問題。正如在（1）中提到，使用 Get 的時候，參數(shù)會顯示在地址欄上，而 Post 不會。所以，如果這些數(shù)據(jù)是中文數(shù)據(jù)而且是非敏感數(shù)據(jù)，那么使用 get；如果用戶輸入的數(shù)據(jù)不是中文字符而且包含敏感數(shù)據(jù)，那么還是使用 post為好。 （4）   安全的和冪等的。所謂安全的意味著該操作用于獲取信息而非修改信息。冪等的意味著對同一 URL 的多個請求應(yīng)該返回同樣的結(jié)果。完整的定義并不像看起來那樣嚴格。換句話說，GET 請求一般不應(yīng)產(chǎn)生副作用。從根本上講，其目標是當用戶打開一個鏈接時，她可以確信從自身的角度來看沒有改變資源。比如，新聞?wù)军c的頭版不斷更新。雖然第二次請求會返回不同的一批新聞，該操作仍然被認為是安全的和冪等的，因為它總是返回當前的新聞。反之亦然。POST 請求就不那么輕松了。POST 表示可能改變服務(wù)器上的資源的請求。仍然以新聞?wù)军c為例，讀者對文章的注解應(yīng)該通過 POST 請求實現(xiàn)，因為在注解提交之后站點已經(jīng)不同了（比方說文章下面出現(xiàn)一條注解）。
 

2.6 請求頭

HTTP最常見的請求頭如下： l         Accept：瀏覽器可接受的MIME類型； l         Accept-Charset：瀏覽器可接受的字符集； l         Accept-Encoding：瀏覽器能夠進行解碼的數(shù)據(jù)編碼方式，比如gzip。Servlet能夠向支持gzip的瀏覽器返回經(jīng)gzip編碼的HTML頁面。許多情形下這可以減少5到10倍的下載時間； l         Accept-Language：瀏覽器所希望的語言種類，當服務(wù)器能夠提供一種以上的語言版本時要用到； l         Authorization：授權(quán)信息，通常出現(xiàn)在對服務(wù)器發(fā)送的WWW-Authenticate頭的應(yīng)答中； l         Connection：表示是否需要持久連接。如果Servlet看到這里的值為“Keep-Alive”，或者看到請求使用的是HTTP 1.1（HTTP 1.1默認進行持久連接），它就可以利用持久連接的優(yōu)點，當頁面包含多個元素時（例如Applet，圖片），顯著地減少下載所需要的時間。要實現(xiàn)這一點，Servlet需要在應(yīng)答中發(fā)送一個Content-Length頭，最簡單的實現(xiàn)方法是：先把內(nèi)容寫入ByteArrayOutputStream，然后在正式寫出內(nèi)容之前計算它的大?。?l         Content-Length：表示請求消息正文的長度； l         Cookie：這是最重要的請求頭信息之一； l         From：請求發(fā)送者的email地址，由一些特殊的Web客戶程序使用，瀏覽器不會用到它； l         Host：初始URL中的主機和端口； l         If-Modified-Since：只有當所請求的內(nèi)容在指定的日期之后又經(jīng)過修改才返回它，否則返回304“Not Modified”應(yīng)答； l         Pragma：指定“no-cache”值表示服務(wù)器必須返回一個刷新后的文檔，即使它是代理服務(wù)器而且已經(jīng)有了頁面的本地拷貝； l         Referer：包含一個URL，用戶從該URL代表的頁面出發(fā)訪問當前請求的頁面。 l         User-Agent：瀏覽器類型，如果Servlet返回的內(nèi)容與瀏覽器類型有關(guān)則該值非常有用； l         UA-Pixels，UA-Color，UA-OS，UA-CPU：由某些版本的IE瀏覽器所發(fā)送的非標準的請求頭，表示屏幕大小、顏色深度、操作系統(tǒng)和CPU類型。

2.7 響應(yīng)頭

HTTP最常見的響應(yīng)頭如下所示： l         Allow：服務(wù)器支持哪些請求方法（如GET、POST等）； l         Content-Encoding：文檔的編碼（Encode）方法。只有在解碼之后才可以得到Content-Type頭指定的內(nèi)容類型。利用gzip壓縮文檔能夠顯著地減少HTML文檔的下載時間。Java的GZIPOutputStream可以很方便地進行g(shù)zip壓縮，但只有Unix上的Netscape和Windows上的IE 4、IE 5才支持它。因此，Servlet應(yīng)該通過查看Accept-Encoding頭（即request.getHeader("Accept-Encoding")）檢查瀏覽器是否支持gzip，為支持gzip的瀏覽器返回經(jīng)gzip壓縮的HTML頁面，為其他瀏覽器返回普通頁面； l         Content-Length：表示內(nèi)容長度。只有當瀏覽器使用持久HTTP連接時才需要這個數(shù)據(jù)。如果你想要利用持久連接的優(yōu)勢，可以把輸出文檔寫入ByteArrayOutputStram，完成后查看其大小，然后把該值放入Content-Length頭，最后通過byteArrayStream.writeTo(response.getOutputStream()發(fā)送內(nèi)容； l         Content-Type： 表示后面的文檔屬于什么MIME類型。Servlet默認為text/plain，但通常需要顯式地指定為text/html。由于經(jīng)常要設(shè)置Content-Type，因此HttpServletResponse提供了一個專用的方法setContentTyep。 可在web.xml文件中配置擴展名和MIME類型的對應(yīng)關(guān)系； l         Date：當前的GMT時間。你可以用setDateHeader來設(shè)置這個頭以避免轉(zhuǎn)換時間格式的麻煩； l         Expires：指明應(yīng)該在什么時候認為文檔已經(jīng)過期，從而不再緩存它。 l         Last-Modified：文檔的最后改動時間?？蛻艨梢酝ㄟ^If-Modified-Since請求頭提供一個日期，該請求將被視為一個條件GET，只有改動時間遲于指定時間的文檔才會返回，否則返回一個304（Not Modified）狀態(tài)。Last-Modified也可用setDateHeader方法來設(shè)置； l         Location：表示客戶應(yīng)當?shù)侥睦锶ヌ崛∥臋n。Location通常不是直接設(shè)置的，而是通過HttpServletResponse的sendRedirect方法，該方法同時設(shè)置狀態(tài)代碼為302； l         Refresh：表示瀏覽器應(yīng)該在多少時間之后刷新文檔，以秒計。除了刷新當前文檔之外，你還可以通過setHeader("Refresh", "5; URL=http://host/path")讓瀏覽器讀取指定的頁面。注意這種功能通常是通過設(shè)置HTML頁面HEAD區(qū)的<META HTTP-EQUIV="Refresh" CONTENT="5;URL=http://host/path">實現(xiàn)，這是因為，自動刷新或重定向?qū)τ谀切┎荒苁褂肅GI或Servlet的HTML編寫者十分重要。但是，對于Servlet來說，直接設(shè)置Refresh頭更加方便。注意Refresh的意義是“N秒之后刷新本頁面或訪問指定頁面”，而不是“每隔N秒刷新本頁面或訪問指定頁面”。因此，連續(xù)刷新要求每次都發(fā)送一個Refresh頭，而發(fā)送204狀態(tài)代碼則可以阻止瀏覽器繼續(xù)刷新，不管是使用Refresh頭還是<META HTTP-EQUIV="Refresh" ...>。注意Refresh頭不屬于HTTP 1.1正式規(guī)范的一部分，而是一個擴展，但Netscape和IE都支持它。

2.8實體頭

實體頭用坐實體內(nèi)容的元信息，描述了實體內(nèi)容的屬性，包括實體信息類型，長度，壓縮方法，最后一次修改時間，數(shù)據(jù)有效性等。 l         Allow：GET,POST l         Content-Encoding：文檔的編碼（Encode）方法，例如：gzip，見“2.5 響應(yīng)頭”； l         Content-Language：內(nèi)容的語言類型，例如：zh-cn； l         Content-Length：表示內(nèi)容長度，eg：80，可參考“2.5響應(yīng)頭”； l         Content-Location：表示客戶應(yīng)當?shù)侥睦锶ヌ崛∥臋n，例如：http://www./dfdf.html，可參考“2.5響應(yīng)頭”； l         Content-MD5：MD5 實體的一種MD5摘要，用作校驗和。發(fā)送方和接受方都計算MD5摘要，接受方將其計算的值與此頭標中傳遞的值進行比較。Eg1：Content-MD5: <base64 of 128 MD5 digest>。Eg2：dfdfdfdfdfdfdff==； l         Content-Range：隨部分實體一同發(fā)送；標明被插入字節(jié)的低位與高位字節(jié)偏移，也標明此實體的總長度。Eg1：Content-Range: 1001-2000/5000，eg2：bytes 2543-4532/7898 l         Content-Type：標明發(fā)送或者接收的實體的MIME類型。Eg：text/html; charset=GB2312       主類型/子類型； l         Expires：為0證明不緩存； l         Last-Modified：WEB 服務(wù)器認為對象的最后修改時間，比如文件的最后修改時間，動態(tài)頁面的最后產(chǎn)生時間等等。例如：Last-Modified：Tue, 06 May 2008 02:42:43 GMT.

2.8擴展頭

在HTTP消息中，也可以使用一些再HTTP1.1正式規(guī)范里沒有定義的頭字段，這些頭字段統(tǒng)稱為自定義的HTTP頭或者擴展頭，他們通常被當作是一種實體頭處理。 現(xiàn)在流行的瀏覽器實際上都支持Cookie,Set-Cookie,Refresh和Content-Disposition等幾個常用的擴展頭字段。 l         Refresh：1;url=http://www.  //過1秒跳轉(zhuǎn)到指定位置； l         Content-Disposition：頭字段,可參考“2.5響應(yīng)頭”； l         Content-Type：WEB 服務(wù)器告訴瀏覽器自己響應(yīng)的對象的類型。 eg1：Content-Type：application/xml ； eg2：applicaiton/octet-stream； Content-Disposition：attachment; filename=aaa.zip。
  附錄：參考資料 《HTTP1.1和HTTP1.0的區(qū)別》： http://blog.csdn.net/yanghehong/archive/2009/05/28/4222594.aspx 《HTTP請求（GET和POST區(qū)別）和響應(yīng)》： http://www./honeybee/articles/164008.html
  《HTTP請求頭概述_百度知道》： http://zhidao.baidu.com/question/32517427.html 《實體頭和擴展頭》： http://www.cnblogs.com/tongzhiyong/archive/2008/03/16/1108776.html 3. 深入了解篇

3.1 Cookie和Session

Cookie和Session都為了用來保存狀態(tài)信息，都是保存客戶端狀態(tài)的機制，它們都是為了解決HTTP無狀態(tài)的問題而所做的努力。 Session可以用Cookie來實現(xiàn)，也可以用URL回寫的機制來實現(xiàn)。用Cookie來實現(xiàn)的Session可以認為是對Cookie更高級的應(yīng)用。

3.1.1兩者比較

Cookie和Session有以下明顯的不同點： 1）Cookie將狀態(tài)保存在客戶端，Session將狀態(tài)保存在服務(wù)器端； 2）Cookies是服務(wù)器在本地機器上存儲的小段文本并隨每一個請求發(fā)送至同一個服務(wù)器。Cookie最早在RFC2109中實現(xiàn)，后續(xù)RFC2965做了增強。網(wǎng)絡(luò)服務(wù)器用HTTP頭向客戶端發(fā)送cookies，在客戶終端，瀏覽器解析這些cookies并將它們保存為一個本地文件，它會自動將同一服務(wù)器的任何請求縛上這些cookies。Session并沒有在HTTP的協(xié)議中定義； 3）Session是針對每一個用戶的，變量的值保存在服務(wù)器上，用一個sessionID來區(qū)分是哪個用戶session變量,這個值是通過用戶的瀏覽器在訪問的時候返回給服務(wù)器，當客戶禁用cookie時，這個值也可能設(shè)置為由get來返回給服務(wù)器； 4）就安全性來說：當你訪問一個使用session 的站點，同時在自己機子上建立一個cookie，建議在服務(wù)器端的SESSION機制更安全些.因為它不會任意讀取客戶存儲的信息。

3.1.2 Session機制

Session機制是一種服務(wù)器端的機制，服務(wù)器使用一種類似于散列表的結(jié)構(gòu)（也可能就是使用散列表）來保存信息。 當程序需要為某個客戶端的請求創(chuàng)建一個session的時候，服務(wù)器首先檢查這個客戶端的請求里是否已包含了一個session標識 - 稱為 session id，如果已包含一個session id則說明以前已經(jīng)為此客戶端創(chuàng)建過session，服務(wù)器就按照session id把這個 session檢索出來使用（如果檢索不到，可能會新建一個），如果客戶端請求不包含session id，則為此客戶端創(chuàng)建一個session并且生成一個與此session相關(guān)聯(lián)的session id，session id的值應(yīng)該是一個既不會重復，又不容易被找到規(guī)律以仿造的字符串，這個 session id將被在本次響應(yīng)中返回給客戶端保存。

3.1.6 Session的實現(xiàn)方式

3.1.6.1  使用Cookie來實現(xiàn)

服務(wù)器給每個Session分配一個唯一的JSESSIONID，并通過Cookie發(fā)送給客戶端。 當客戶端發(fā)起新的請求的時候，將在Cookie頭中攜帶這個JSESSIONID。這樣服務(wù)器能夠找到這個客戶端對應(yīng)的Session。 流程如下圖所示：
   

3.1.6.2  使用URL回顯來實現(xiàn)

URL回寫是指服務(wù)器在發(fā)送給瀏覽器頁面的所有鏈接中都攜帶JSESSIONID的參數(shù)，這樣客戶端點擊任何一個鏈接都會把JSESSIONID帶會服務(wù)器。 如果直接在瀏覽器輸入服務(wù)端資源的url來請求該資源，那么Session是匹配不到的。 Tomcat對Session的實現(xiàn)，是一開始同時使用Cookie和URL回寫機制，如果發(fā)現(xiàn)客戶端支持Cookie，就繼續(xù)使用Cookie，停止使用URL回寫。如果發(fā)現(xiàn)Cookie被禁用，就一直使用URL回寫。jsp開發(fā)處理到Session的時候，對頁面中的鏈接記得使用response.encodeURL() 。

3.1.3在J2EE項目中Session失效的幾種情況

1）Session超時：Session在指定時間內(nèi)失效，例如30分鐘，若在30分鐘內(nèi)沒有操作，則Session會失效，例如在web.xml中進行了如下設(shè)置： <session-config>
        <session-timeout>30</session-timeout> //單位：分鐘
    </session-config> 2）使用session.invalidate()明確的去掉Session。

3.1.4與Cookie相關(guān)的HTTP擴展頭

1）Cookie：客戶端將服務(wù)器設(shè)置的Cookie返回到服務(wù)器； 2）Set-Cookie：服務(wù)器向客戶端設(shè)置Cookie； 3）Cookie2 (RFC2965)）：客戶端指示服務(wù)器支持Cookie的版本； 4）Set-Cookie2 (RFC2965)：服務(wù)器向客戶端設(shè)置Cookie。

3.1.5Cookie的流程

服務(wù)器在響應(yīng)消息中用Set-Cookie頭將Cookie的內(nèi)容回送給客戶端，客戶端在新的請求中將相同的內(nèi)容攜帶在Cookie頭中發(fā)送給服務(wù)器。從而實現(xiàn)會話的保持。 流程如下圖所示：

3.2 緩存的實現(xiàn)原理

3.2.1什么是Web緩存

WEB緩存(cache)位于Web服務(wù)器和客戶端之間。 緩存會根據(jù)請求保存輸出內(nèi)容的副本，例如html頁面，圖片，文件，當下一個請求來到的時候：如果是相同的URL，緩存直接使用副本響應(yīng)訪問請求，而不是向源服務(wù)器再次發(fā)送請求。 HTTP協(xié)議定義了相關(guān)的消息頭來使WEB緩存盡可能好的工作。

3.2.2緩存的優(yōu)點

q      減少相應(yīng)延遲：因為請求從緩存服務(wù)器（離客戶端更近）而不是源服務(wù)器被相應(yīng)，這個過程耗時更少，讓web服務(wù)器看上去相應(yīng)更快。 q      減少網(wǎng)絡(luò)帶寬消耗：當副本被重用時會減低客戶端的帶寬消耗；客戶可以節(jié)省帶寬費用，控制帶寬的需求的增長并更易于管理。

3.2.3與緩存相關(guān)的HTTP擴展消息頭

q      Expires：指示響應(yīng)內(nèi)容過期的時間，格林威治時間GMT q      Cache-Control：更細致的控制緩存的內(nèi)容 q      Last-Modified：響應(yīng)中資源最后一次修改的時間 q      ETag：響應(yīng)中資源的校驗值，在服務(wù)器上某個時段是唯一標識的。 q      Date：服務(wù)器的時間 q      If-Modified-Since：客戶端存取的該資源最后一次修改的時間，同Last-Modified。 q      If-None-Match：客戶端存取的該資源的檢驗值，同ETag。

3.2.4客戶端緩存生效的常見流程

服務(wù)器收到請求時，會在200OK中回送該資源的Last-Modified和ETag頭，客戶端將該資源保存在cache中，并記錄這兩個屬性。當客戶端需要發(fā)送相同的請求時，會在請求中攜帶If-Modified-Since和If-None-Match兩個頭。兩個頭的值分別是響應(yīng)中Last-Modified和ETag頭的值。服務(wù)器通過這兩個頭判斷本地資源未發(fā)生變化，客戶端不需要重新下載，返回304響應(yīng)。常見流程如下圖所示：

3.2.5 Web緩存機制

HTTP/1.1中緩存的目的是為了在很多情況下減少發(fā)送請求，同時在許多情況下可以不需要發(fā)送完整響應(yīng)。前者減少了網(wǎng)絡(luò)回路的數(shù)量；HTTP利用一個“過期（expiration）”機制來為此目的。后者減少了網(wǎng)絡(luò)應(yīng)用的帶寬；HTTP用“驗證（validation）”機制來為此目的。 HTTP定義了3種緩存機制： 1）Freshness：允許一個回應(yīng)消息可以在源服務(wù)器不被重新檢查，并且可以由服務(wù)器和客戶端來控制。例如，Expires回應(yīng)頭給了一個文檔不可用的時間。Cache-Control中的max-age標識指明了緩存的最長時間； 2）Validation：用來檢查以一個緩存的回應(yīng)是否仍然可用。例如，如果一個回應(yīng)有一個Last-Modified回應(yīng)頭，緩存能夠使用If-Modified-Since來判斷是否已改變，以便判斷根據(jù)情況發(fā)送請求； 3）Invalidation： 在另一個請求通過緩存的時候，常常有一個副作用。例如，如果一個URL關(guān)聯(lián)到一個緩存回應(yīng)，但是其后跟著POST、PUT和DELETE的請求的話，緩存就會過期。

3.3 斷點續(xù)傳和多線程下載的實現(xiàn)原理

q      HTTP協(xié)議的GET方法，支持只請求某個資源的某一部分； q      206 Partial Content 部分內(nèi)容響應(yīng)； q      Range 請求的資源范圍； q      Content-Range 響應(yīng)的資源范圍； q      在連接斷開重連時，客戶端只請求該資源未下載的部分，而不是重新請求整個資源，來實現(xiàn)斷點續(xù)傳。 分塊請求資源實例： Eg1：Range: bytes=306302- ：請求這個資源從306302個字節(jié)到末尾的部分； Eg2：Content-Range: bytes 306302-604047/604048：響應(yīng)中指示攜帶的是該資源的第306302-604047的字節(jié)，該資源共604048個字節(jié)； 客戶端通過并發(fā)的請求相同資源的不同片段，來實現(xiàn)對某個資源的并發(fā)分塊下載。從而達到快速下載的目的。目前流行的FlashGet和迅雷基本都是這個原理。 多線程下載的原理： q      下載工具開啟多個發(fā)出HTTP請求的線程； q      每個http請求只請求資源文件的一部分：Content-Range: bytes 20000-40000/47000； q      合并每個線程下載的文件。

3.4 https通信過程

3.4.1什么是https

HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全為目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎(chǔ)是SSL，因此加密的詳細內(nèi)容請看SSL。 見下圖：
   
https所用的端口號是443。

3.4.2 https的實現(xiàn)原理

有兩種基本的加解密算法類型： 1）對稱加密：密鑰只有一個，加密解密為同一個密碼，且加解密速度快，典型的對稱加密算法有DES、AES等； 2）非對稱加密：密鑰成對出現(xiàn)（且根據(jù)公鑰無法推知私鑰，根據(jù)私鑰也無法推知公鑰），加密解密使用不同密鑰（公鑰加密需要私鑰解密，私鑰加密需要公鑰解密），相對對稱加密速度較慢，典型的非對稱加密算法有RSA、DSA等。 下面看一下https的通信過程：
  
https通信的優(yōu)點： 1）客戶端產(chǎn)生的密鑰只有客戶端和服務(wù)器端能得到； 2）加密的數(shù)據(jù)只有客戶端和服務(wù)器端才能得到明文； 3）客戶端到服務(wù)端的通信是安全的。

3.5 http代理

3.5.1 http代理服務(wù)器

代理服務(wù)器英文全稱是Proxy Server，其功能就是代理網(wǎng)絡(luò)用戶去取得網(wǎng)絡(luò)信息。形象的說：它是網(wǎng)絡(luò)信息的中轉(zhuǎn)站。 代理服務(wù)器是介于瀏覽器和Web服務(wù)器之間的一臺服務(wù)器，有了它之后，瀏覽器不是直接到Web服務(wù)器去取回網(wǎng)頁而是向代理服務(wù)器發(fā)出請求，Request信號會先送到代理服務(wù)器，由代理服務(wù)器來取回瀏覽器所需要的信息并傳送給你的瀏覽器。 而且，大部分代理服務(wù)器都具有緩沖的功能，就好象一個大的Cache，它有很大的存儲空間，它不斷將新取得數(shù)據(jù)儲存到它本機的存儲器上，如果瀏覽器所請求的數(shù)據(jù)在它本機的存儲器上已經(jīng)存在而且是最新的，那么它就不重新從Web服務(wù)器取數(shù)據(jù)，而直接將存儲器上的數(shù)據(jù)傳送給用戶的瀏覽器，這樣就能顯著提高瀏覽速度和效率。 更重要的是：Proxy Server(代理服務(wù)器)是Internet鏈路級網(wǎng)關(guān)所提供的一種重要的安全功能，它的工作主要在開放系統(tǒng)互聯(lián)(OSI)模型的對話層。

3.5.2 http代理服務(wù)器的主要功能

主要功能如下： 1）突破自身IP訪問限制，訪問國外站點。如：教育網(wǎng)、169網(wǎng)等網(wǎng)絡(luò)用戶可以通過代理訪問國外網(wǎng)站； 2）訪問一些單位或團體內(nèi)部資源，如某大學FTP(前提是該代理地址在該資源的允許訪問范圍之內(nèi))，使用教育網(wǎng)內(nèi)陸址段免費代理服務(wù)器，就可以用于對教育 網(wǎng)開放的各類FTP下載上傳，以及各類資料查詢共享等服務(wù)； 3）突破中國電信的IP封鎖：中國電信用戶有很多網(wǎng)站是被限制訪問的，這種限制是人為的，不同Serve對地址的封鎖是不同的。所以不能訪問時可以換一個國 外的代理服務(wù)器試試； 4）提高訪問速度：通常代理服務(wù)器都設(shè)置一個較大的硬盤緩沖區(qū)，當有外界的信息通過時，同時也將其保存到緩沖區(qū)中，當其他用戶再訪問相同的信息時， 則直接由緩沖區(qū)中取出信息，傳給用戶，以提高訪問速度； 5）隱藏真實IP：上網(wǎng)者也可以通過這種方法隱藏自己的IP，免受攻擊。

3.5.3 http代理圖示

http代理的圖示見下圖：
  
對于客戶端瀏覽器而言，http代理服務(wù)器相當于服務(wù)器。 而對于Web服務(wù)器而言，http代理服務(wù)器又擔當了客戶端的角色。

3.6 虛擬主機的實現(xiàn)

3.6.1什么是虛擬主機

虛擬主機：是在網(wǎng)絡(luò)服務(wù)器上劃分出一定的磁盤空間供用戶放置站點、應(yīng)用組件等，提供必要的站點功能與數(shù)據(jù)存放、傳輸功能。   所謂虛擬主機，也叫“網(wǎng)站空間”就是把一臺運行在互聯(lián)網(wǎng)上的服務(wù)器劃分成多個“虛擬”的服務(wù)器，每一個虛擬主機都具有獨立的域名和完整的Internet服務(wù)器（支持WWW、FTP、E-mail等）功能。一臺服務(wù)器上的不同虛擬主機是各自獨立的，并由用戶自行管理。但一臺服務(wù)器主機只能夠支持一定數(shù)量的虛擬主機，當超過這個數(shù)量時，用戶將會感到性能急劇下降。

3.6.2虛擬主機的實現(xiàn)原理

虛擬主機是用同一個WEB服務(wù)器，為不同域名網(wǎng)站提供服務(wù)的技術(shù)。Apache、Tomcat等均可通過配置實現(xiàn)這個功能。 相關(guān)的HTTP消息頭：Host。 例如：Host: www.baidu.com 客戶端發(fā)送HTTP請求的時候，會攜帶Host頭，Host頭記錄的是客戶端輸入的域名。這樣服務(wù)器可以根據(jù)Host頭確認客戶要訪問的是哪一個域名。

附錄：參考資料

《理解Cookie和Session機制》： http://sumongh./blog/82498 《淺析HTTP協(xié)議》： http://203.208.39.132/search?q=cache:CdXly_88gjIJ:www.cnblogs.com/gpcuster/archive/2009/05/25/1488749.html+http%E5%8D%8F%E8%AE%AE+web%E7%BC%93%E5%AD%98&cd=27&hl=zh-CN&ct=clnk&gl=cn&st_usg=ALhdy2-vzOcP8XTG1h7lcRr2GJrkTbH2Cg 《http代理_百度百科》： http://baike.baidu.com/view/1159398.htm 《虛擬主機_百度百科》： http://baike.baidu.com/view/7383.htm 《https_百度百科》：