一、Session的概念

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

一般情況下，服務器會在一定時間內（默認30分鐘）保存這個 Session，過了時間限制，就會銷毀這個Session。在銷毀之前，程序員可以將用戶的一些數據以Key和Value的形式暫時存放在這個 Session中。當然，也有使用數據庫將這個Session序列化後保存起來的，這樣的好處是沒了時間的限制，壞處是隨著時間的增加，這個數據 庫會急速膨脹，特別是訪問量增加的時候。一般還是采取前一種方式，以減輕服務器壓力。

二、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來玩點讓客戶驚喜的小遊戲。

四、cookie最典型的應用是：

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

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

淺談Session與Cookie的區別與聯系