本系列下載地址：http://www.tkk7.com/Files/amigoxie/http協議學習系列-阿蜜果.rar
  下一篇：協議詳解篇
蜜果私塾：http協議學習和總結系列
--深入了解篇

文：阿蜜果

日期：2009-12-3

      這篇開篇的時候，要感謝一下我的老大，他看到我在寫這個系列，給我提供了一個他以前做內部培訓時，寫得很贊的兩個ppt，被我拿來為我所用，(*^__^*) 嘻嘻……。另外感謝下網上提供各種資料的IT同仁們。
3. 深入了解篇

3.1 Cookie和Session

Cookie和Session都為了用來保存狀態信息，都是保存客戶端狀態的機制，它們都是為了解決HTTP無狀態的問題而所做的努力。

Session可以用Cookie來實現，也可以用URL回寫的機制來實現。用Cookie來實現的Session可以認為是對Cookie更高級的應用。

3.1.1兩者比較

Cookie和Session有以下明顯的不同點：

1）Cookie將狀態保存在客戶端，Session將狀態保存在服務器端；

2）Cookies是服務器在本地機器上存儲的小段文本并隨每一個請求發送至同一個服務器。Cookie最早在RFC2109中實現，后續RFC2965做了增強。網絡服務器用HTTP頭向客戶端發送cookies，在客戶終端，瀏覽器解析這些cookies并將它們保存為一個本地文件，它會自動將同一服務器的任何請求縛上這些cookies。Session并沒有在HTTP的協議中定義；

3）Session是針對每一個用戶的，變量的值保存在服務器上，用一個sessionID來區分是哪個用戶session變量,這個值是通過用戶的瀏覽器在訪問的時候返回給服務器，當客戶禁用cookie時，這個值也可能設置為由get來返回給服務器；

4）就安全性來說：當你訪問一個使用session 的站點，同時在自己機子上建立一個cookie，建議在服務器端的SESSION機制更安全些.因為它不會任意讀取客戶存儲的信息。

3.1.2 Session機制

Session機制是一種服務器端的機制，服務器使用一種類似于散列表的結構（也可能就是使用散列表）來保存信息。

當程序需要為某個客戶端的請求創建一個session的時候，服務器首先檢查這個客戶端的請求里是否已包含了一個session標識 - 稱為 session id，如果已包含一個session id則說明以前已經為此客戶端創建過session，服務器就按照session id把這個 session檢索出來使用（如果檢索不到，可能會新建一個），如果客戶端請求不包含session id，則為此客戶端創建一個session并且生成一個與此session相關聯的session id，session id的值應該是一個既不會重復，又不容易被找到規律以仿造的字符串，這個 session id將被在本次響應中返回給客戶端保存。

3.1.6 Session的實現方式

3.1.6.1  使用Cookie來實現

服務器給每個Session分配一個唯一的JSESSIONID，并通過Cookie發送給客戶端。

當客戶端發起新的請求的時候，將在Cookie頭中攜帶這個JSESSIONID。這樣服務器能夠找到這個客戶端對應的Session。

流程如下圖所示：
   

3.1.6.2  使用URL回顯來實現

URL回寫是指服務器在發送給瀏覽器頁面的所有鏈接中都攜帶JSESSIONID的參數，這樣客戶端點擊任何一個鏈接都會把JSESSIONID帶會服務器。

如果直接在瀏覽器輸入服務端資源的url來請求該資源，那么Session是匹配不到的。

Tomcat對Session的實現，是一開始同時使用Cookie和URL回寫機制，如果發現客戶端支持Cookie，就繼續使用Cookie，停止使用URL回寫。如果發現Cookie被禁用，就一直使用URL回寫。jsp開發處理到Session的時候，對頁面中的鏈接記得使用response.encodeURL() 。

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

1）Session超時：Session在指定時間內失效，例如30分鐘，若在30分鐘內沒有操作，則Session會失效，例如在web.xml中進行了如下設置：

<session-config>
        <session-timeout>30</session-timeout> //單位：分鐘
    </session-config>

2）使用session.invalidate()明確的去掉Session。

3.1.4與Cookie相關的HTTP擴展頭

1）Cookie：客戶端將服務器設置的Cookie返回到服務器；

2）Set-Cookie：服務器向客戶端設置Cookie；

3）Cookie2 (RFC2965)）：客戶端指示服務器支持Cookie的版本；

4）Set-Cookie2 (RFC2965)：服務器向客戶端設置Cookie。

3.1.5Cookie的流程

服務器在響應消息中用Set-Cookie頭將Cookie的內容回送給客戶端，客戶端在新的請求中將相同的內容攜帶在Cookie頭中發送給服務器。從而實現會話的保持。

流程如下圖所示：

3.2 緩存的實現原理

3.2.1什么是Web緩存

WEB緩存(cache)位于Web服務器和客戶端之間。

緩存會根據請求保存輸出內容的副本，例如html頁面，圖片，文件，當下一個請求來到的時候：如果是相同的URL，緩存直接使用副本響應訪問請求，而不是向源服務器再次發送請求。

HTTP協議定義了相關的消息頭來使WEB緩存盡可能好的工作。

3.2.2緩存的優點

q      減少相應延遲：因為請求從緩存服務器（離客戶端更近）而不是源服務器被相應，這個過程耗時更少，讓web服務器看上去相應更快。

q      減少網絡帶寬消耗：當副本被重用時會減低客戶端的帶寬消耗；客戶可以節省帶寬費用，控制帶寬的需求的增長并更易于管理。

3.2.3與緩存相關的HTTP擴展消息頭

q      Expires：指示響應內容過期的時間，格林威治時間GMT

q      Cache-Control：更細致的控制緩存的內容

q      Last-Modified：響應中資源最后一次修改的時間

q      ETag：響應中資源的校驗值，在服務器上某個時段是唯一標識的。

q      Date：服務器的時間

q      If-Modified-Since：客戶端存取的該資源最后一次修改的時間，同Last-Modified。

q      If-None-Match：客戶端存取的該資源的檢驗值，同ETag。

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

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

3.2.5 Web緩存機制

HTTP/1.1中緩存的目的是為了在很多情況下減少發送請求，同時在許多情況下可以不需要發送完整響應。前者減少了網絡回路的數量；HTTP利用一個“過期（expiration）”機制來為此目的。后者減少了網絡應用的帶寬；HTTP用“驗證（validation）”機制來為此目的。

HTTP定義了3種緩存機制：

1）Freshness：允許一個回應消息可以在源服務器不被重新檢查，并且可以由服務器和客戶端來控制。例如，Expires回應頭給了一個文檔不可用的時間。Cache-Control中的max-age標識指明了緩存的最長時間；

2）Validation：用來檢查以一個緩存的回應是否仍然可用。例如，如果一個回應有一個Last-Modified回應頭，緩存能夠使用If-Modified-Since來判斷是否已改變，以便判斷根據情況發送請求；

3）Invalidation： 在另一個請求通過緩存的時候，常常有一個副作用。例如，如果一個URL關聯到一個緩存回應，但是其后跟著POST、PUT和DELETE的請求的話，緩存就會過期。

3.3 斷點續傳和多線程下載的實現原理

q      HTTP協議的GET方法，支持只請求某個資源的某一部分；

q      206 Partial Content 部分內容響應；

q      Range 請求的資源范圍；

q      Content-Range 響應的資源范圍；

q      在連接斷開重連時，客戶端只請求該資源未下載的部分，而不是重新請求整個資源，來實現斷點續傳。

分塊請求資源實例：

Eg1：Range: bytes=306302- ：請求這個資源從306302個字節到末尾的部分；

Eg2：Content-Range: bytes 306302-604047/604048：響應中指示攜帶的是該資源的第306302-604047的字節，該資源共604048個字節；

客戶端通過并發的請求相同資源的不同片段，來實現對某個資源的并發分塊下載。從而達到快速下載的目的。目前流行的FlashGet和迅雷基本都是這個原理。

多線程下載的原理：

q      下載工具開啟多個發出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的安全基礎是SSL，因此加密的詳細內容請看SSL。

見下圖：
   

https所用的端口號是443。

3.4.2 https的實現原理

有兩種基本的加解密算法類型：

1）對稱加密：密鑰只有一個，加密解密為同一個密碼，且加解密速度快，典型的對稱加密算法有DES、AES等；

2）非對稱加密：密鑰成對出現（且根據公鑰無法推知私鑰，根據私鑰也無法推知公鑰），加密解密使用不同密鑰（公鑰加密需要私鑰解密，私鑰加密需要公鑰解密），相對對稱加密速度較慢，典型的非對稱加密算法有RSA、DSA等。

下面看一下https的通信過程：
  

https通信的優點：

1）客戶端產生的密鑰只有客戶端和服務器端能得到；

2）加密的數據只有客戶端和服務器端才能得到明文；

3）客戶端到服務端的通信是安全的。

3.5 http代理

3.5.1 http代理服務器

代理服務器英文全稱是Proxy Server，其功能就是代理網絡用戶去取得網絡信息。形象的說：它是網絡信息的中轉站。

代理服務器是介于瀏覽器和Web服務器之間的一臺服務器，有了它之后，瀏覽器不是直接到Web服務器去取回網頁而是向代理服務器發出請求，Request信號會先送到代理服務器，由代理服務器來取回瀏覽器所需要的信息并傳送給你的瀏覽器。

而且，大部分代理服務器都具有緩沖的功能，就好象一個大的Cache，它有很大的存儲空間，它不斷將新取得數據儲存到它本機的存儲器上，如果瀏覽器所請求的數據在它本機的存儲器上已經存在而且是最新的，那么它就不重新從Web服務器取數據，而直接將存儲器上的數據傳送給用戶的瀏覽器，這樣就能顯著提高瀏覽速度和效率。

更重要的是：Proxy Server(代理服務器)是Internet鏈路級網關所提供的一種重要的安全功能，它的工作主要在開放系統互聯(OSI)模型的對話層。

3.5.2 http代理服務器的主要功能

主要功能如下：

1）突破自身IP訪問限制，訪問國外站點。如：教育網、169網等網絡用戶可以通過代理訪問國外網站；

2）訪問一些單位或團體內部資源，如某大學FTP(前提是該代理地址在該資源的允許訪問范圍之內)，使用教育網內地址段免費代理服務器，就可以用于對教育 網開放的各類FTP下載上傳，以及各類資料查詢共享等服務；

3）突破中國電信的IP封鎖：中國電信用戶有很多網站是被限制訪問的，這種限制是人為的，不同Serve對地址的封鎖是不同的。所以不能訪問時可以換一個國 外的代理服務器試試；

4）提高訪問速度：通常代理服務器都設置一個較大的硬盤緩沖區，當有外界的信息通過時，同時也將其保存到緩沖區中，當其他用戶再訪問相同的信息時， 則直接由緩沖區中取出信息，傳給用戶，以提高訪問速度；

5）隱藏真實IP：上網者也可以通過這種方法隱藏自己的IP，免受攻擊。

3.5.3 http代理圖示

http代理的圖示見下圖：
  

對于客戶端瀏覽器而言，http代理服務器相當于服務器。

而對于Web服務器而言，http代理服務器又擔當了客戶端的角色。

3.6 虛擬主機的實現

3.6.1什么是虛擬主機

虛擬主機：是在網絡服務器上劃分出一定的磁盤空間供用戶放置站點、應用組件等，提供必要的站點功能與數據存放、傳輸功能。  

所謂虛擬主機，也叫“網站空間”就是把一臺運行在互聯網上的服務器劃分成多個“虛擬”的服務器，每一個虛擬主機都具有獨立的域名和完整的Internet服務器（支持WWW、FTP、E-mail等）功能。一臺服務器上的不同虛擬主機是各自獨立的，并由用戶自行管理。但一臺服務器主機只能夠支持一定數量的虛擬主機，當超過這個數量時，用戶將會感到性能急劇下降。

3.6.2虛擬主機的實現原理

虛擬主機是用同一個WEB服務器，為不同域名網站提供服務的技術。Apache、Tomcat等均可通過配置實現這個功能。

相關的HTTP消息頭：Host。

例如：Host: www.baidu.com

客戶端發送HTTP請求的時候，會攜帶Host頭，Host頭記錄的是客戶端輸入的域名。這樣服務器可以根據Host頭確認客戶要訪問的是哪一個域名。

附錄：參考資料

《理解Cookie和Session機制》：

http://sumongh.javaeye.com/blog/82498

《淺析HTTP協議》：

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_百度百科》：

http://baike.baidu.com/view/14121.htm