1.1 Cookie機制程序員
在程序中，會話跟蹤是很重要的事情。理論上，一個用戶的全部請求操做都應該屬於同一個會話，而另外一個用戶的全部請求操做則應該屬於另外一個會話，兩者不能混淆。例如，用戶A在超市購買的任何商品都應該放在A的購物車內，不管是用戶A什麼時間購買的，這都是屬於同一個會話的，不能放入用戶B或用戶C的購物車內，這不屬於同一個會話。web
而Web應用程序是使用HTTP協議傳輸數據的。HTTP協議是無狀態的協議。一旦數據交換完畢，客戶端與服務器端的鏈接就會關閉，再次交換數據須要創建新的鏈接。這就意味着服務器沒法從鏈接上跟蹤會話。即用戶A購買了一件商品放入購物車內，當再次購買商品時服務器已經沒法判斷該購買行爲是屬於用戶A的會話仍是用戶B的會話了。要跟蹤該會話，必須引入一種機制。數據庫
Cookie就是這樣的一種機制。它能夠彌補HTTP協議無狀態的不足。在Session出現以前，基本上全部的網站都採用Cookie來跟蹤會話。跨域
2. 思考一下服務端如何識別特定的客戶？這個時候Cookie就登場了。每次HTTP請求的時候，客戶端都會發送相應的Cookie信息到服務端。實際上大多數的應用都是用 Cookie 來實現Session跟蹤的，第一次建立Session的時候，服務端會在HTTP協議中告訴客戶端，須要在 Cookie 裏面記錄一個Session ID，之後每次請求把這個會話ID發送到服務器，我就知道你是誰了。有人問，若是客戶端的瀏覽器禁用了 Cookie 怎麼辦？通常這種狀況下，會使用一種叫作URL重寫的技術來進行會話跟蹤，即每次HTTP交互，URL後面都會被附加上一個諸如 sid=xxxxx 這樣的參數，服務端據此來識別用戶。
3. Cookie其實還能夠用在一些方便用戶的場景下，設想你某次登錄過一個網站，下次登陸的時候不想再次輸入帳號了，怎麼辦？這個信息能夠寫到Cookie裏面，訪問網站的時候，網站頁面的腳本能夠讀取這個信息，就自動幫你把用戶名給填了，可以方便一下用戶。這也是Cookie名稱的由來，給用戶的一點甜頭。
因此，總結一下：
Session是在服務端保存的一個數據結構，用來跟蹤用戶的狀態，這個數據能夠保存在集羣、數據庫、文件中；
Cookie是客戶端保存用戶信息的一種機制，用來記錄用戶的一些信息，也是實現Session的一種方式。
1.1.3 Cookie的不可跨域名性瀏覽器
不少網站都會使用Cookie。例如，Google會向客戶端頒發Cookie，Baidu也會向客戶端頒發Cookie。那瀏覽器訪問Google會不會也攜帶上Baidu頒發的Cookie呢？或者Google能不能修改Baidu頒發的Cookie呢？緩存
答案是否認的。Cookie具備不可跨域名性。根據Cookie規範，瀏覽器訪問Google只會攜帶Google的Cookie，而不會攜帶Baidu的Cookie。Google也只能操做Google的Cookie，而不能操做Baidu的Cookie。安全
Cookie在客戶端是由瀏覽器來管理的。瀏覽器可以保證Google只會操做Google的Cookie而不會操做Baidu的Cookie，從而保證用戶的隱私安全。瀏覽器判斷一個網站是否能操做另外一個網站Cookie的依據是域名。Google與Baidu的域名不同，所以Google不能操做Baidu的Cookie。服務器
須要注意的是，雖然網站images.google.com與網站www.google.com同屬於Google，可是域名不同，兩者一樣不能互相操做彼此的Cookie。cookie
注意：用戶登陸網站www.google.com以後會發現訪問images.google.com時登陸信息仍然有效，而普通的Cookie是作不到的。這是由於Google作了特殊處理。本章後面也會對Cookie作相似的處理。session
1.2.3 Session的生命週期
Session保存在服務器端。爲了得到更高的存取速度，服務器通常把Session放在內存裏。每一個用戶都會有一個獨立的Session。若是Session內容過於複雜，當大量客戶訪問服務器時可能會致使內存溢出。所以，Session裏的信息應該儘可能精簡。
Session在用戶第一次訪問服務器的時候自動建立。須要注意只有訪問JSP、Servlet等程序時纔會建立Session，只訪問HTML、IMAGE等靜態資源並不會建立Session。若是還沒有生成Session，也可使用request.getSession(true)強制生成Session。
Session生成後，只要用戶繼續訪問，服務器就會更新Session的最後訪問時間，並維護該Session。用戶每訪問服務器一次，不管是否讀寫Session，服務器都認爲該用戶的Session「活躍（active）」了一次。
1.2.4 Session的有效期
因爲會有愈來愈多的用戶訪問服務器，所以Session也會愈來愈多。爲防止內存溢出，服務器會把長時間內沒有活躍的Session從內存刪除。這個時間就是Session的超時時間。若是超過了超時時間沒訪問過服務器，Session就自動失效了。
Session的超時時間爲maxInactiveInterval屬性，能夠經過對應的getMaxInactiveInterval()獲取，經過setMaxInactiveInterval(longinterval)修改。
Session的超時時間也能夠在web.xml中修改。另外，經過調用Session的invalidate()方法可使Session失效。
1.2.6 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地址重寫。
客戶端存儲：
一、cookie
二、ie提供了一種叫作用戶數據的行爲，能夠應用到頁面的某個元素上。
三、DOM存儲
DOM存儲定義了兩種存儲數據的對象：sessionStorage和localstorage前者嚴格用於在一個瀏覽器會話中存儲數據，由於數據在瀏覽器關閉後馬上刪除，後者用於用於跨越會話持久化數據並給予跨域名安全策略。
還有第三個對象globalStorage,firefox實現了她
在後來的版本中localstorage對象替代了globalStorage
DOM存儲目的是克服由cookie帶來的一些限制，當數據須要嚴格控制在客戶端上時，無需持續地將數據發回服務器，dom存儲的兩個主要目標是：
1）提供一種在cookie以外存儲會話數據的途徑
2）提供一種存儲大量能夠跨越會話存在的數據的機制
2. 本地存儲
兩個storage其餘屬性方法都同樣
| 特性 | Cookie | localStorage | sessionStorage |
|---|---|---|---|
| 數據的生命期 | 通常由服務器生成，可設置失效時間。若是在瀏覽器端生成Cookie，默認是關閉瀏覽器後失效 | 除非被清除，不然永久保存 | 僅在當前會話下有效，關閉頁面或瀏覽器後被清除 |
| 存放數據大小 | 4K左右 | 通常爲5MB | - |
| 與服務器端通訊 | 每次都會攜帶在HTTP頭中，若是使用cookie保存過多數據會帶來性能問題 | 僅在客戶端（即瀏覽器）中保存，不參與和服務器的通訊 | - |
| 易用性 | 須要程序員本身封裝，源生的Cookie接口不友好 | 源生接口能夠接受，亦可再次封裝來對Object和Array有更好的支持 | - |