Session和Cookie

      Session存儲在服務器端，通常爲了防止在服務器的內存中（爲了高速存取），Sessinon在用戶訪問第一次訪問服務器時建立，須要注意只有訪問JSP、Servlet等程序時纔會建立Session，只訪問HTML、IMAGE等靜態資源並不會建立Session，可調用request.getSession(true)強制生成Session。

　　Session何時失效？

　　1. 服務器會把長時間沒有活動的Session從服務器內存中清除，此時Session便失效。Tomcat中Session的默認失效時間爲20分鐘。

　　2. 調用Session的invalidate方法。

　　Session對瀏覽器的要求：

　　雖然Session保存在服務器，對客戶端是透明的，它的正常運行仍然須要客戶端瀏覽器的支持。這是由於Session須要使用Cookie做爲識別標誌。HTTP協議是無狀態的，Session不能依據HTTP鏈接來判斷是否爲同一客戶，所以服務器向客戶端瀏覽器發送一個名爲JSESSIONID的Cookie，它的值爲該Session的id（也就是HttpSession.getId()的返回值）。Session依據該Cookie來識別是否爲同一用戶。

該Cookie爲服務器自動生成的，它的maxAge屬性通常爲-1，表示僅當前瀏覽器內有效，而且各瀏覽器窗口間不共享，關閉瀏覽器就會失效。所以同一機器的兩個瀏覽器窗口訪問服務器時，會生成兩個不一樣的Session。可是由瀏覽器窗口內的連接、腳本等打開的新窗口（也就是說不是雙擊桌面瀏覽器圖標等打開的窗口）除外。這類子窗口會共享父窗口的Cookie，所以會共享一個Session。

 注意：新開的瀏覽器窗口會生成新的Session，但子窗口除外。子窗口會共用父窗口的Session。例如，在連接上右擊，在彈出的快捷菜單中選擇"在新窗口中打開"時，子窗口即可以訪問父窗口的Session。

 若是客戶端瀏覽器將Cookie功能禁用，或者不支持Cookie怎麼辦？例如，絕大多數的手機瀏覽器都不支持Cookie。Java Web提供了另外一種解決方案：URL地址重寫。

　　URL地址重寫是對客戶端不支持Cookie的解決方案。URL地址重寫的原理是將該用戶Session的id信息重寫到URL地址中。服務器可以解析重寫後的URL獲取Session的id。這樣即便客戶端不支持Cookie，也可使用Session來記錄用戶狀態。HttpServletResponse類提供了encodeURL(String url)實現URL地址重寫，該方法會自動判斷客戶端是否支持Cookie。若是客戶端支持Cookie，會將URL原封不動地輸出來。若是客戶端不支持Cookie，則會將用戶Session的id重寫到URL中。

　　注意：TOMCAT判斷客戶端瀏覽器是否支持Cookie的依據是請求中是否含有Cookie。儘管客戶端可能會支持Cookie，可是因爲第一次請求時不會攜帶任何Cookie（由於並沒有任何Cookie能夠攜帶），URL地址重寫後的地址中仍然會帶有jsessionid。當第二次訪問時服務器已經在瀏覽器中寫入Cookie了，所以URL地址重寫後的地址中就不會帶有jsessionid了。

 

Cookie老是保存在客戶端中，按在客戶端中的存儲位置，可分爲內存Cookie和硬盤Cookie。

內存Cookie由瀏覽器維護，保存在內存中，瀏覽器關閉後就消失了，其存在時間是短暫的。硬盤Cookie保存在硬盤裏，有一個過時時間，除非用戶手工清理或到了過時時間，硬盤Cookie不會被刪除，其存在時間是長期的。因此，按存在時間，可分爲非持久Cookie和持久Cookie。

用途

由於HTTP協議是無狀態的，即服務器不知道用戶上一次作了什麼，這嚴重阻礙了交互式Web應用程序的實現。在典型的網上購物場景中，用戶瀏覽了幾個頁面，買了一盒餅乾和兩瓶飲料。最後結賬時，因爲HTTP的無狀態性，不經過額外的手段，服務器並不知道用戶到底買了什麼。 因此Cookie就是用來繞開HTTP的無狀態性的「額外手段」之一。服務器能夠設置或讀取Cookies中包含信息，藉此維護用戶跟服務器會話中的狀態。

在剛纔的購物場景中，當用戶選購了第一項商品，服務器在向用戶發送網頁的同時，還發送了一段Cookie，記錄着那項商品的信息。當用戶訪問另外一個頁面，瀏覽器會把Cookie發送給服務器，因而服務器知道他以前選購了什麼。用戶繼續選購飲料，服務器就在原來那段Cookie裏追加新的商品信息。結賬時，服務器讀取發送來的Cookie就好了。

Cookie另外一個典型的應用是當登陸一個網站時，網站每每會請求用戶輸入用戶名和密碼，而且用戶能夠勾選「下次自動登陸」。若是勾選了，那麼下次訪問同一網站時，用戶會發現沒輸入用戶名和密碼就已經登陸了。這正是由於前一次登陸時，服務器發送了包含登陸憑據（用戶名加密碼的某種加密形式）的Cookie到用戶的硬盤上。第二次登陸時，（若是該Cookie還沒有到期）瀏覽器會發送該Cookie，服務器驗證憑據，因而沒必要輸入用戶名和密碼就讓用戶登陸了。

Cookie的缺陷

1. cookie會被附加在每一個HTTP請求中，因此無形中增長了流量。

2. 因爲在HTTP請求中的cookie是明文傳遞的，因此安全性成問題。（除非用HTTPS）

3. Cookie的大小限制在4KB左右。對於複雜的存儲需求來講是不夠用的。^[2]

使用和禁用Cookies

用戶能夠改變瀏覽器的設置，以使用或者禁用Cookies。同時一些瀏覽器自帶或安裝開發者工具包容許用戶查看，修改或刪除特定網站的Cookies信息。

識別功能

若是在一臺計算機中安裝多個瀏覽器，每一個瀏覽器都會以獨立的空間存放cookie。由於cookie中不但能夠確認用戶，還能包含計算機和瀏覽器的信息，因此一個用戶用不一樣的瀏覽器登陸或者用不一樣的計算機登陸，都會獲得不一樣的cookie信息，另外一方面，對於在同一臺計算機上使用同一瀏覽器的多用戶羣，cookie不會區分他們的身份，除非他們使用不一樣的用戶名登陸。

反對Cookies者

隱私，安全和廣告

Cookies在某種程度上說已經嚴重危及用戶的隱私和安全。其中的一種方法是：一些公司的高層人員爲了某種目的（譬如市場調研）而訪問了從未去過的網站（經過搜索引擎查到的），而這些網站包含了一種叫作網頁臭蟲的圖片，該圖片透明，且只有一個象素大小（以便隱藏），它們的做用是將全部訪問過此頁面的計算機寫入cookie。然後，電子商務網站將讀取這些cookie信息，並尋找寫入這些cookie的網站，隨即發送包含了針對這個網站的相關產品廣告的垃圾郵件給這些高級人員。

偷竊Cookies和腳本攻擊

雖然cookies沒有中計算機病毒那麼危險，但它仍包含了一些敏感信息：用戶名，計算機名，使用的瀏覽器和曾經訪問的網站。用戶不但願這些內容泄漏出去，尤爲是當其中還包含有私人信息的時候。

這並不是危言聳聽，跨站點腳本（Cross site scripting）能夠達到此目的。在受到跨站點腳本攻擊時，cookie盜賊和cookie毒藥將竊取內容。一旦cookie落入攻擊者手中，它將會重現其價值。

• Cookie盜賊：蒐集用戶cookie併發給攻擊者的黑客。攻擊者將利用cookie信息經過合法手段進入用戶賬戶。

• Cookie投毒：通常認爲，Cookie在儲存和傳回服務器期間沒有被修改過，而攻擊者會在cookie送回服務器以前對其進行修改，達到本身的目的。例如，在一個購物網站的cookie中包含了顧客應付的款項，攻擊者將該值改小，達到少付款的目的。這就是cookie 投毒。

Cookies的替代品

鑑於cookie的侷限和反對者的聲音，有以下一些替代方法：

• Brownie方案，是一項開放源代碼工程，由SourceForge發起。Brownie曾被用以共享在不一樣域中的接入，而cookies則被構想成單一域中的接入。這項方案已經中止開發。

• P3P，用以讓用戶得到更多控制我的隱私權利的協議。在瀏覽網站時，它相似於cookie。

• 在與服務器傳輸數據時，經過在地址後面添加惟一查詢串，讓服務器識別是否合法用戶，也能夠避免使用cookie。

• 轉自：http://my.oschina.net/u/576942/blog/211863