前言：
- session 和cookie都是爲了保持服務器和客戶端之間交互狀態。若是一天的PV有幾億，而一個cookie佔200個字節可是也會佔用不少帶寬？因此大訪問量就引用session，可是幾百臺服務器集羣之間 有沒法實現共享session。
理解Cookie
- 簡單來講就是用戶經過HTTP去訪問服務器，而後服務器會返回一些key/value的數據給用戶端，同時給這些數據加上一些限制條件，當用戶再次訪問服務器時，只要條件知足時就會被從新返回給服務器。W3C設計cookie最初是爲了應對HTTP這種無狀態協議去區分不一樣用戶的，如今cookie也能夠被用做服務器數據緩存判斷的依據。
- cookie屬性項 ，目前分爲了version0 和version1兩個版本，經常使用的有max-age ,domain,expires,path等等，在Javaweb的servlet規範中，咱們經常使用的set-cookie：user-name='hakulamatata';max-Age="1000"。
- 客戶端和服務端交互時，不須要每次都傳遞這麼屢次cookie ，這麼作無疑是增長數據傳輸量。因此當客戶端第一次鏈接到服務端，服務器會生成一個每一個客戶端惟一的ID,這個ID就是客戶端保存着的 NAME =JSESIONID 的cookie，每次交互就把這個cookie id發過去 便於服務器識別。
- 使用cookie的限制，雖然HTTP協議對於cookie的數量和佔用空間大小是沒有限制的，可是現代基本瀏覽器（主要指支持html5的瀏覽器） 對於數量限制基本都是每一個域名不超過50個 ，佔用空間而言 基本除了谷歌是 80000個字節，其餘都是4095個字節。
- cookie安全問題：容易想到既然cookie保存在客戶端，就不免被他人利用篡改或者進行其餘咱們預料以外的操做，相比而言存放在服務端的 session就安全些，因此一些敏感信息 更適於存放在session裏。
- cookie壓縮問題。若是大型網站PV上億的那種，帶寬和流量而言，壓縮cookie頗有必要，而根據cookie的規範 ，cookie只能是ASCII碼爲34-126的可見字符，因此咱們必須使用Base64進行編解碼，而後再利用gzip和deflate等壓縮算法進行壓縮，節省流量帶寬成本。
理解session
- 前面講過，web交互過程當中不可能每次都把cookie都傳回服務端，而是用一個 jesesionid的id 的cookie,這是session 的一種方式，還有基於 url 這兩個都是默認支持的，最後還有一個是SSL的，這個不是默認支持的。當web.xml 配置了 session就會 以配置的 爲sessionid，沒配置就是以默認的jesesionid 爲準，而url 則是以url傳回的K-V鍵值對爲依據構建 sessionid，而最後一種特殊狀況就是 javax.servlet.request.ssl_session屬性值設置 sessionid。
Session 如何工做
- 有了sessionid對象就能夠去建立httpsesion對象了，第一次經過 request.getsession()方法，若是沒有就建立新的，而後放到sessionmanager裏面去管理，過時的就關閉，服務器關閉時就持久化到磁盤，只要有這個HTTPsession對象客戶就能夠獲取這個對象，也就實現HTTP協議自己無狀態，到技術實現其有狀態的過程。
擴展問題
-
表單重複提交：就是在用戶請求前，在表單隱藏域中添加一個根據某個種子生成的隨機數，也就是 token ，而後存放在session中，當用戶提交表單時，在和這個存放在session中的對比，若是不一樣就是重複提交，如圖
html -
多端session統一：主要涉及多端共享session，其次就是如圖過程。
html5