本文分別對Cookie與Session做一個介紹和總結,並分別對兩個知識點進行對比分析,讓大家對Cookie和Session有一個更深入的了解,並對自己的開發工作中靈活運用帶來啟示。

cookie機制

Cookies是伺服器在本地機器上存儲的小段文本並隨每一個請求發送至同一個伺服器。IETF RFC 2965 HTTP State Management Mechanism 是通用cookie規範。網路伺服器用HTTP頭向客戶端發送cookies,在客戶終端,瀏覽器解析這些cookies並將它們保存為一個本地文件,它會自動將同一伺服器的任何請求縛上這些cookies 。

具體來說cookie機制採用的是在客戶端保持狀態的方案。它是在用戶端的會話狀態的存貯機制,他需要用戶打開客戶端的cookie支持。cookie的作用就是為了解決HTTP協議無狀態的缺陷所作的努力。

正統的cookie分發是通過擴展HTTP協議來實現的,伺服器通過在HTTP的響應頭中加上一行特殊的指示以提示瀏覽器按照指示生成相應的cookie。然而純粹的客戶端腳本如JavaScript也可以生成cookie。而cookie的使用是由瀏覽器按照一定的原則在後台自動發送給伺服器的。瀏覽器檢查所有存儲的cookie,如果某個cookie所聲明的作用範圍大於等於將要請求的資源所在的位置,則把該cookie附在請求資源的HTTP請求頭上發送給伺服器。

cookie的內容主要包括:名字,值,過期時間,路徑和域。路徑與域一起構成cookie的作用範圍。若不設置過期時間,則表示這個cookie的生命期為瀏覽器會話期間,關閉瀏覽器窗口,cookie就消失。這種生命期為瀏覽器會話期的cookie被稱為會話cookie。會話cookie一般不存儲在硬碟上而是保存在內存里,當然這種行為並不是規範規定的。若設置了過期時間,瀏覽器就會把cookie保存到硬碟上,關閉後再次打開瀏覽器,這些cookie仍然有效直到超過設定的過期時間。存儲在硬碟上的cookie可以在不同的瀏覽器進程間共享,比如兩個IE窗口。而對於保存在內存里的cookie,不同的瀏覽器有不同的處理方式。

而session機制採用的是一種在伺服器端保持狀態的解決方案。同時我們也看到,由於採用伺服器端保持狀態的方案在客戶端也需要保存一個標識,所以session機制可能需要藉助於cookie機制來達到保存標識的目的。而session提供了方便管理全局變數的方式 。

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

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

session機制

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

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

保存這個session id的方式可以採用cookie,這樣在交互過程中瀏覽器可以自動的按照規則把這個標識發揮給伺服器。一般這個cookie的名字都是類似於SEEESIONID。但cookie可以被人為的禁止,則必須有其他機制以便在cookie被禁止時仍然能夠把session id傳遞迴伺服器。

經常被使用的一種技術叫做URL重寫,就是把session id直接附加在URL路徑的後面。還有一種技術叫做表單隱藏欄位。就是伺服器會自動修改表單,添加一個隱藏欄位,以便在表單提交時能夠把session id傳遞迴伺服器。

Cookie與Session都能夠進行會話跟蹤,但是完成的原理不太一樣。普通狀況下二者均能夠滿足需求,但有時分不能夠運用Cookie,有時分不能夠運用Session。下面經過比擬闡明二者的特性以及適用的場所。

1、存取方式的不同

Cookie中只能保管ASCII字元串,假如需求存取Unicode字元或者二進位數據,需求先進行編碼。Cookie中也不能直接存取Java對象。若要存儲略微複雜的信息,運用Cookie是比擬艱難的。

而Session中能夠存取任何類型的數據,包括而不限於String、Integer、List、Map等。Session中也能夠直接保管Java Bean乃至任何Java類,對象等,運用起來十分便當。能夠把Session看做是一個Java容器類。

2、隱私策略的不同

Cookie存儲在客戶端閱讀器中,對客戶端是可見的,客戶端的一些程序可能會窺探、複製以至修正Cookie中的內容。而Session存儲在伺服器上,對客戶端是透明的,不存在敏感信息泄露的風險。

假如選用Cookie,比較好的方法是,敏感的信息如賬號密碼等盡量不要寫到Cookie中。最好是像Google、Baidu那樣將Cookie信息加密,提交到伺服器後再進行解密,保證Cookie中的信息只要本人能讀得懂。而假如選擇Session就省事多了,反正是放在伺服器上,Session里任何隱私都能夠有效的保護。

3、有效期上的不同

使用過Google的人都曉得,假如登錄過Google,則Google的登錄信息長期有效。用戶不用每次訪問都重新登錄,Google會持久地記載該用戶的登錄信息。要到達這種效果,運用Cookie會是比較好的選擇。只需要設置Cookie的過期時間屬性為一個很大很大的數字。

由於Session依賴於名為JSESSIONID的Cookie,而Cookie JSESSIONID的過期時間默許為–1,只需關閉了閱讀器該Session就會失效,因而Session不能完成信息永世有效的效果。運用URL地址重寫也不能完成。而且假如設置Session的超時時間過長,伺服器累計的Session就會越多,越容易招致內存溢出。

4、伺服器壓力的不同

Session是保管在伺服器端的,每個用戶都會產生一個Session。假如並發訪問的用戶十分多,會產生十分多的Session,耗費大量的內存。因而像Google、Baidu、Sina這樣並發訪問量極高的網站,是不太可能運用Session來追蹤客戶會話的。

而Cookie保管在客戶端,不佔用伺服器資源。假如並發閱讀的用戶十分多,Cookie是很好的選擇。關於Google、Baidu、Sina來說,Cookie或許是唯一的選擇。

5、瀏覽器支持的不同

Cookie是需要客戶端瀏覽器支持的。假如客戶端禁用了Cookie,或者不支持Cookie,則會話跟蹤會失效。關於WAP上的應用,常規的Cookie就派不上用場了。

假如客戶端瀏覽器不支持Cookie,需要運用Session以及URL地址重寫。需要注意的是一切的用到Session程序的URL都要進行URL地址重寫,否則Session會話跟蹤還會失效。關於WAP應用來說,Session+URL地址重寫或許是它唯一的選擇。

假如客戶端支持Cookie,則Cookie既能夠設為本瀏覽器窗口以及子窗口內有效(把過期時間設為–1),也能夠設為一切閱讀器窗口內有效(把過期時間設為某個大於0的整數)。但Session只能在本閱讀器窗口以及其子窗口內有效。假如兩個瀏覽器窗口互不相干,它們將運用兩個不同的Session。(IE8下不同窗口Session相干)

6、跨域支持上的不同

Cookie支持跨域名訪問,例如將domain屬性設置為「.biaodianfu.com」,則以「.biaodianfu.com」為後綴的一切域名均能夠訪問該Cookie。跨域名Cookie如今被普遍用在網路中,例如Google、Baidu、Sina等。而Session則不會支持跨域名訪問。Session僅在他所在的域名內有效。

7.Session框架

介紹Session框架之前,有必要先了解一下Session。Session在 網路應用中稱為「會話」,藉助它可提供客戶端與服務系統之 間必要的交互。因為HTTP協議本身是無狀態的,所以經常需要 通過Session來解決服務端和瀏覽器的保持狀態的解決方案。用戶 向伺服器發送第一個請求時,伺服器為其建立一個Session,並為 此Session創建一個標識,用戶隨後的所有請求都應包括這個標識 號。伺服器會校對這個標識號以判斷請求屬於哪個Session。會話 保持有效,默認狀況下,直到瀏覽器關閉,會話才結束。 Session中存儲的內容包括用戶信息:昵稱、用戶ID、登錄狀 態等。

當網站伺服器只有一台的時候,用Session來解決用戶識別是 很簡單的,但是當網站是一個集群的時候,同一用戶的兩次請求 可能被分配到兩台不同的伺服器上處理。怎樣保證兩次請求中存 取的Session值一致呢?

還有一個問題:網站規模擴大時,對於一 個具有上億個訪問用戶的系統來說,當大部分用戶的Session信息 都存儲在服務端時,要在服務端檢索出用戶的信息效率就非常低 了,Session管理器不管用什麼數據結構和演算法都要耗費大量內存 和CPU時間。

如何解決服務端Session信息的管理? 解決集群Session共享的問題,通常有以下兩種辦法。

1 硬體負載,將用戶請求分發到特定的伺服器。

2 Session複製,就是將用戶的Session複製到集群內所有的服 務器。

這兩種方法的弊端也很明顯: 1 成本較高。2 性能差。當訪問量增大的時候,帶寬增大,而且隨著機器 數量的增加,網路負擔成指數級上升,不具備高度可擴展 性,性能隨著伺服器數量的增加急劇下降,而且容易引起 廣播風暴。

用Cookie來識別用戶,Cookie是放在客戶端的,每一次HTTP請求都要提交到服務 端,在訪問量比較小的時候,採用Cookie避免了Session複製、硬 件負載等高成本的情況。但隨著用戶訪問規模的提高,我們可以 折算一下,一個Cookie大概是2KB的數據,也就是說,一次請求 要提交到伺服器的數據是網頁請求數據,再加上2KB的Cookie, 當有上億個請求的時候,Cookie所帶來的流量已經非常可觀了, 而且網路流量的成本也越來越高,

所以採用了 集中式的緩存區的Session方式。

Tbsession框架

Session的客戶端存儲,將Session信息存儲到客戶端瀏覽器 Cookie中。

1 實現服務端存儲,減少Cookie使用,增強用戶信息的安全 性,避免瀏覽器對Cookie數量和大小的限制。

2 Session配置統一管理起來,集中管理服務端Session和客戶端 Cookie的使用情況,對Cookie的使用做有效的監管。

3 支持動態更新,Session的配置動態更新。 簡單地說,就是要麼用客戶端Cookie來解決問題,要不用服 務端的集中緩存區(Tair)的Session來解決登錄問題。


推薦閱讀:
相关文章