爲什麼需要session
談及session一般是在web應用的背景之下，我們知道web應用是基於HTTP協議的，而HTTP協議恰恰是一種無狀態協議。也就是說，用戶從A頁面跳轉到B頁面會重新發送一次HTTP請求，而服務端在返回響應的時候是無法獲知該用戶在請求B頁面之前做了什麼的。
對於HTTP的無狀態性的原因，相關RFC裏並沒有解釋，但聯繫到HTTP的歷史以及應用場景，我們可以推測出一些理由：
1. 設計HTTP最初的目的是爲了提供一種發佈和接收HTML頁面的方法。那個時候沒有動態頁面技術，只有純粹的靜態HTML頁面，因此根本不需要協議能保持狀態；
2. 用戶在收到響應時，往往要花一些時間來閱讀頁面，因此如果保持客戶端和服務端之間的連接，那麼這個連接在大多數的時間裏都將是空閒的，這是一種資源的無端浪費。所以HTTP原始的設計是默認短連接，即客戶端和服務端完成一次請求和響應之後就斷開TCP連接，服務器因此無法預知客戶端的下一個動作，它甚至都不知道這個用戶會不會再次訪問，因此讓HTTP協議來維護用戶的訪問狀態也全然沒有必要；
3. 將一部分複雜性轉嫁到以HTTP協議爲基礎的技術之上可以使得HTTP在協議這個層面上顯得相對簡單，而這種簡單也賦予了HTTP更強的擴展能力。事實上，session技術從本質上來講也是對HTTP協議的一種擴展。
總而言之，HTTP的無狀態是由其歷史使命而決定的。但隨着網絡技術的蓬勃發展，人們再也不滿足於死板乏味的靜態HTML，他們希望web應用能動起來，於是客戶端出現了腳本和DOM技術，HTML裏增加了表單，而服務端出現了CGI等等動態技術。
而正是這種web動態化的需求，給HTTP協議提出了一個難題：一個無狀態的協議怎樣才能關聯兩次連續的請求呢？也就是說無狀態的協議怎樣才能滿足有狀態的需求呢？
此時有狀態是必然趨勢而協議的無狀態性也是木已成舟，因此我們需要一些方案來解決這個矛盾，來保持HTTP連接狀態，於是出現了cookie和session。
Session創建的時間是：
注意如果JSP沒有顯示的使用 <% @page session="false"%> 關閉session，則JSP文件在編譯成Servlet時將會自動加上這樣一條語句
HttpSession session = HttpServletRequest.getSession(true);這也是JSP中隱含的 session對象的來歷。
發送給客戶端的瀏覽器。以後客戶端接着請求本應用中其他資源的時候，會自動在請求頭上添加：
當一個頁面第二次請求同一頁面時，服務器會尋找之前創建的sesssion id, 並加載到請求頭
Session刪除的時間是：
session存放在哪裏：服務器端的內存中
session會因爲瀏覽器的關閉而刪除嗎？ 不會，session只會通過上面提到的方式去關閉。
同一客戶端機器多次請求同一個資源，session一樣嗎？ 一般來說，每次請求都會新創建一個session。
總結下：對於多標籤的瀏覽器（比如360瀏覽器）來說，在一個瀏覽器窗口中，多個標籤同時訪問一個頁面，session是一個。對於多個瀏覽器窗口之間，
同時或者相隔很短時間訪問一個頁面，session是多個的，和瀏覽器的進程有關。對於一個同一個瀏覽器窗口，直接錄入url訪問同一應用的不同資源，session是一樣的。
session是一個容器，可以存放會話過程中的任何對象。
session的創建和使用總在服務端，而瀏覽器從來都沒得到過session對象。但瀏覽器可以請求Servlet（jsp也是Servlet）來獲取session的信息。
客戶端瀏覽器真正緊緊拿到的是session ID，而這個對於瀏覽器操作的人來說，是不可見的，並且用戶也無需關心自己處於哪個會話過程中。
session的id是從哪裏來的，sessionID是如何使用的：當客戶端第一次請求session對象時候，服務器會爲客戶端創建一個session，並將通過特殊算法算出一個session的ID，用來標識該session對象，當瀏覽器下次（session繼續有效時）請求別的資源的時候，瀏覽器會偷偷地將sessionID放置到請求頭中，服務器接收到請求後就得到該請求的sessionID，服務器找到該id的session返還給請求者（Servlet）使用。一個會話只能有一個session對象，對session來說是隻認id不認人