HTTP協議詳解(四)

接着第三篇繼續學習....html

 

9 Cookie和Session的比較

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

Session能夠用Cookie來實現,也能夠用URL回寫的機制來實現。用Cookie來實現的Session能夠認爲是對Cookie更高級的應用。web

9.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機制更安全些.由於它不會任意讀取客戶存儲的信息。服務器

9.2 Session機制

Session機制是一種服務器端的機制,服務器使用一種相似於散列表的結構(也可能就是使用散列表)來保存信息。cookie

當程序須要爲某個客戶端的請求建立一個session的時候,服務器首先檢查這個客戶端的請求裏是否已包含了一個session標識 - 稱爲 session id,若是已包含一個session id則說明之前已經爲此客戶端建立過session,服務器就按照session id把這個 session檢索出來使用(若是檢索不到,可能會新建一個),若是客戶端請求不包含session id,則爲此客戶端建立一個session而且生成一個與此session相關聯的session id,session id的值應該是一個既不會重複,又不容易被找到規律以仿造的字符串,這個 session id將被在本次響應中返回給客戶端保存。網絡

9.3 Session的實現方式

9.3.1  使用Cookie來實現

服務器給每一個Session分配一個惟一的JSESSIONID,並經過Cookie發送給客戶端。

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

流程以下圖所示:
  

 

  

9.3.2  使用URL回顯來實現

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

若是直接在瀏覽器輸入服務端資源的url來請求該資源,那麼Session是匹配不到的。

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

9.4在J2EE項目中Session失效的幾種狀況

1)Session超時:Session在指定時間內失效,例如30分鐘,若在30分鐘內沒有操做,則Session會失效,例如在web.xml中進行了以下設置:

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

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

9.5與Cookie相關的HTTP擴展頭

1)Cookie:客戶端將服務器設置的Cookie返回到服務器;

2)Set-Cookie:服務器向客戶端設置Cookie;

3)Cookie2 (RFC2965)):客戶端指示服務器支持Cookie的版本;

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

9.6 Cookie的流程

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

流程以下圖所示:

 

10 緩存的實現原理

10.1什麼是Web緩存

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

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

HTTP協議定義了相關的消息頭來使WEB緩存儘量好的工做。

10.2緩存的優勢

1減小相應延遲:由於請求從緩存服務器(離客戶端更近)而不是源服務器被相應,這個過程耗時更少,讓web服務器看上去相應更快。

2減小網絡帶寬消耗:當副本被重用時會減低客戶端的帶寬消耗;客戶能夠節省帶寬費用,控制帶寬的需求的增加並更易於管理。

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

Expires:指示響應內容過時的時間,格林威治時間GMT

Cache-Control:更細緻的控制緩存的內容

Last-Modified:響應中資源最後一次修改的時間

ETag:響應中資源的校驗值,在服務器上某個時段是惟一標識的。

Date:服務器的時間

If-Modified-Since:客戶端存取的該資源最後一次修改的時間,同Last-Modified。

If-None-Match:客戶端存取的該資源的檢驗值,同ETag。

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

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

 

10.5 Web緩存機制

HTTP/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的請求的話,緩存就會過時。

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

HTTP協議的GET方法,支持只請求某個資源的某一部分;

206 Partial Content 部份內容響應;

Range 請求的資源範圍;

Content-Range 響應的資源範圍;

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

分塊請求資源實例:

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

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

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

多線程下載的原理:

下載工具開啓多個發出HTTP請求的線程;

每一個http請求只請求資源文件的一部分:Content-Range: bytes 20000-40000/47000;

合併每一個線程下載的文件。

12 https通訊過程

12.1什麼是https

HTTPS(全稱:Hypertext Transfer Protocol over Secure Socket Layer),是以安全爲目標的HTTP通道,簡單講是HTTP的安全版。即HTTP下加入SSL層,HTTPS的安全基礎是SSL,所以加密的詳細內容請看SSL。

見下圖:
 

 

  

https所用的端口號是443。

12.2 https的實現原理

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

1)對稱加密:密鑰只有一個,加密解密爲同一個密碼,且加解密速度快,典型的對稱加密算法有DES、AES等;

2)非對稱加密:密鑰成對出現(且根據公鑰沒法推知私鑰,根據私鑰也沒法推知公鑰),加密解密使用不一樣密鑰(公鑰加密須要私鑰解密,私鑰加密須要公鑰解密),相對對稱加密速度較慢,典型的非對稱加密算法有RSA、DSA等。

下面看一下https的通訊過程:
   

 

https通訊的優勢:

1)客戶端產生的密鑰只有客戶端和服務器端能獲得;

2)加密的數據只有客戶端和服務器端才能獲得明文;

3)客戶端到服務端的通訊是安全的。

13 http代理

13.1 http代理服務器

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

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

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

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

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

主要功能以下:

1)突破自身IP訪問限制,訪問國外站點。如:教育網、169網等網絡用戶能夠經過代理訪問國外網站;

2)訪問一些單位或團體內部資源,如某大學FTP(前提是該代理地址在該資源的容許訪問範圍以內),使用教育網內地址段免費代理服務器,就能夠用於對教育 網開放的各種FTP下載上傳,以及各種資料查詢共享等服務;

3)突破中國電信的IP封鎖:中國電信用戶有不少網站是被限制訪問的,這種限制是人爲的,不一樣Serve對地址的封鎖是不一樣的。因此不能訪問時能夠換一個國 外的代理服務器試試;

4)提升訪問速度:一般代理服務器都設置一個較大的硬盤緩衝區,當有外界的信息經過時,同時也將其保存到緩衝區中,當其餘用戶再訪問相同的信息時, 則直接由緩衝區中取出信息,傳給用戶,以提升訪問速度;

5)隱藏真實IP:上網者也能夠經過這種方法隱藏本身的IP,免受攻擊。

13.3 http代理圖示

http代理的圖示見下圖:
  

 

對於客戶端瀏覽器而言,http代理服務器至關於服務器。

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

14 虛擬主機的實現

14.1什麼是虛擬主機

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

所謂虛擬主機,也叫「網站空間」就是把一臺運行在互聯網上的服務器劃分紅多個「虛擬」的服務器,每個虛擬主機都具備獨立的域名和完整的Internet服務器(支持WWWFTPE-mail等)功能。一臺服務器上的不一樣虛擬主機是各自獨立的,並由用戶自行管理。但一臺服務器主機只可以支持必定數量的虛擬主機,當超過這個數量時,用戶將會感到性能急劇降低。

14.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

《HTTP1和HTTP1.0的區別》:

http://blog.csdn.net/yanghehong/archive/2009/05/28/4222594.aspx

《HTTP請求(GET和POST區別)和響應》:

http://www.blogjava.net/honeybee/articles/164008.html
 

《HTTP請求頭概述_百度知道》:

http://zhidao.baidu.com/question/32517427.html

《實體頭和擴展頭》:

http://www.cnblogs.com/tongzhiyong/archive/2008/03/16/1108776.html

 

簡化版: 

https://www.cnblogs.com/ranyonsue/p/5984001.html

備註:此文章借用了其餘博客文章的相關內容,有問題的話請聯繫我,謝謝!

相關文章
相關標籤/搜索