session與cookies的區別與聯繫

1、Session的概念

Session 是存放在服務器端的，相似於Session結構來存放用戶數據，當瀏覽器 第一次發送請求時，服務器自動生成了一個Session和一個Session ID用來惟一標識這個Session，並將其經過響應發送到瀏覽器。當瀏覽器第二次發送請求，會將前一次服務器響應中的Session ID放在請求中一併發送到服務器上，服務器從請求中提取出Session ID，並和保存的全部Session ID進行對比，找到這個用戶對應的Session。

通常狀況下，服務器會在必定時間內（默認30分鐘）保存這個 Session，過了時間限制，就會銷燬這個Session。在銷燬以前，程序員能夠將用戶的一些數據以Key和Value的形式暫時存放在這個 Session中。固然，也有使用數據庫將這個Session序列化後保存起來的，這樣的好處是沒了時間的限制，壞處是隨着時間的增長，這個數據 庫會急速膨脹，特別是訪問量增長的時候。通常仍是採起前一種方式，以減輕服務器壓力。

2、Session的客戶端實現形式（即Session ID的保存方法）

通常瀏覽器提供了兩種方式來保存，還有一種是程序員使用html隱藏域的方式自定義實現：

[1] 使用Cookie來保存，這是最多見的方法，本文「記住個人登陸狀態」功能的實現正式基於這種方式的。服務器經過設置Cookie的方式將Session ID發送到瀏覽器。若是咱們不設置這個過時時間，那麼這個Cookie將不存放在硬盤上，當瀏覽器關閉的時候，Cookie就消失了，這個Session ID就丟失了。若是咱們設置這個時間爲若干天以後，那麼這個Cookie會保存在客戶端硬盤中，即便瀏覽器關閉，這個值仍然存在，下次訪問相應網站時，同 樣會發送到服務器上。

[2] 使用URL附加信息的方式，也就是像咱們常常看到JSP網站會有aaa.jsp?JSESSIONID=*同樣的。這種方式和第一種方式裏面不設置Cookie過時時間是同樣的。

[3] 第三種方式是在頁面表單裏面增長隱藏域，這種方式實際上和第二種方式同樣，只不過前者經過GET方式發送數據，後者使用POST方式發送數據。可是明顯後者比較麻煩。

cookie與session的區別：

cookie數據保存在客戶端，session數據保存在服務器端。

簡 單的說，當你登陸一個網站的時候，若是web服務器端使用的是session,那麼全部的數據都保存在服務器上面，客戶端每次請求服務器的時候會發送 當前會話的sessionid，服務器根據當前sessionid判斷相應的用戶數據標誌，以肯定用戶是否登陸，或具備某種權限。因爲數據是存儲在服務器 上面，因此你不能僞造，可是若是你可以獲取某個登陸用戶的sessionid，用特殊的瀏覽器僞造該用戶的請求也是可以成功的。sessionid是服務 器和客戶端連接時候隨機分配的，通常來講是不會有重複，但若是有大量的併發請求，也不是沒有重複的可能性，我曾經就遇到過一次。登陸某個網站，開始顯示的 是本身的信息，等一段時間超時了，一刷新，竟然顯示了別人的信息。

若是瀏覽器使用的是 cookie，那麼全部的數據都保存在瀏覽器端，好比你登陸之後，服務器設置了 cookie用戶名(username),那麼，當你再次請求服務器的時候，瀏覽器會將username一塊發送給服務器，這些變量有必定的特殊標記。服 務器會解釋爲 cookie變量。因此只要不關閉瀏覽器，那麼 cookie變量便一直是有效的，因此可以保證長時間不掉線。若是你可以截獲某個用戶的 cookie變量，而後僞造一個數據包發送過去，那麼服務器仍是認爲你是合法的。因此，使用 cookie被攻擊的可能性比較大。若是設置了的有效時間，那麼它會將 cookie保存在客戶端的硬盤上，下次再訪問該網站的時候，瀏覽器先檢查有沒有 cookie，若是有的話，就讀取該 cookie，而後發送給服務器。若是你在機器上面保存了某個論壇 cookie，有效期是一年，若是有人入侵你的機器，將你的 cookie拷走，而後放在他的瀏覽器的目錄下面，那麼他登陸該網站的時候就是用你的的身份登陸的。因此 cookie是能夠僞造的。固然，僞造的時候須要主意，直接copy cookie文件到 cookie目錄，瀏覽器是不認的，他有一個index.dat文件，存儲了 cookie文件的創建時間，以及是否有修改，因此你必須先要有該網站的 cookie文件，而且要從保證時間上騙過瀏覽器，曾經在學校的vbb論壇上面作過試驗，copy別人的 cookie登陸，冒用了別人的名義發帖子，徹底沒有問題。

Session是由應用服務器維持的一個服務器端的存儲空間，用戶在鏈接服務器時，會由服務器生成一個惟一的SessionID,用該SessionID 爲標識符來存取服務器端的Session存儲空間。而SessionID這一數據則是保存到客戶端，用Cookie保存的，用戶提交頁面時，會將這一 SessionID提交到服務器端，來存取Session數據。這一過程，是不用開發人員干預的。因此一旦客戶端禁用Cookie，那麼Session也會失效。

服務器也能夠經過URL重寫的方式來傳遞SessionID的值，所以不是徹底依賴Cookie。若是客戶端Cookie禁用，則服務器能夠自動經過重寫URL的方式來保存Session的值，而且這個過程對程序員透明。

能夠試一下，即便不寫Cookie，在使用request.getCookies();取出的Cookie數組的長度也是1，而這個Cookie的名字就是JSESSIONID，還有一個很長的二進制的字符串，是SessionID的值。

三：Session與Cookie區別和聯繫：

Cookies是屬於Session對象的一種。但有不一樣，Cookies不會佔服務器資源，是存在客服端內存或者一個cookie的文本文件中；而「Session」則會佔用服務器資源。因此，儘可能不要使用Session，而使用Cookies。可是咱們通常認爲cookie是不可靠的，session是可靠地，可是目前不少著名的站點也都以來cookie。有時候爲了解決禁用cookie後的頁面處理，一般採用url重寫技術，調用session中大量有用的方法從session中獲取數據後置入頁面。

Cookies與Session的應用場景： 
Cookies的安全性能一直是倍受爭議的。雖然Cookies是保存在本機上的，可是其信息的徹底可見性且易於本地編輯性，每每能夠引發不少的安全問題。因此Cookies到底該不應用，到底該怎樣用，就有了一個須要給定的底線。

先來看看，網站的敏感數據有哪些。

登錄驗證信息。通常採用Session(「Logon」)＝true or false的形式。 
用戶的各類私人信息，好比姓名等，某種狀況下，須要保存在Session裏 
須要在頁面間傳遞的內容信息，好比調查工做須要分好幾步。每一步的信息都保存在Session裏，最後在統一更新到數據庫。

固然還會有不少，這裏列舉一些比較典型的 
假如，一我的孤僻到不想碰Session，由於他認爲，若是用戶萬一不當心關閉了瀏覽器，那麼以前保存的數據就所有丟失了。因此，他出於好意，決定把這些用Session的地方，都改爲用Cookies來存儲，這徹底是可行的，且基本操做和用Session如出一轍。那麼，下面就針對以上的3個典型例子，作一個分析 
很顯然，只要某個有意非法入侵者，知道該網站驗證登錄信息的Session變量是什麼，那麼他就能夠事先編輯好該Cookies，放入到Cookies目錄中，這樣就能夠順利經過驗證了。這是否是很可怕？ 
Cookies徹底是可見的，即便程序員設定了Cookies的生存週期（好比只在用戶會話有效期內有效），它也是不安全的。假設，用戶忘了關瀏覽器 或者一個惡意者硬性把用戶給打暈，那用戶的損失將是巨大的。 
這點如上點同樣，很容易被它人竊取重要的私人信息。但，其還有一個問題所在是，可能這些數據信息量太大，而使得Cookies的文件大小劇增。這可不是用戶但願所看到的。

顯然，Cookies並非那麼一塊好啃的小甜餅。但，Cookies的存在，固然有其緣由。它給予程序員更多發揮編程才能的空間。因此，使用Cookies改有個底線。這個底線通常來講，遵循如下原則。 
不要保存私人信息。 
任何重要數據，最好經過加密形式來保存數據（最簡單的能夠用URLEncode，固然也能夠用完善的可逆加密方式，遺憾的是，最好不要用md5來加密）。 
是否保存登錄信息，需有用戶自行選擇。 
長於10K的數據，不要用到Cookies。 
也不要用Cookies來玩點讓客戶驚喜的小遊戲。

4、cookie最典型的應用是：

（一）：判斷用戶是否登錄過網站，以便下次登陸時可以直接登陸。若是咱們刪除cookie，則每次登陸必須重新填寫登陸的相關信息。

（二）：另外一個重要的應用是「購物車」中類的處理和設計。用戶可能在一段時間內在同一家網站的不一樣頁面選擇不一樣的商品，能夠將這些信息都寫入cookie，在最後付款時從cookie中提取這些信息，固然這裏面有了安全和性能問題須要咱們考慮了