1. javaweb前後端分離開發 session怎麼處理,如何區分會話
seesion只不過是一個字元串而已，業界採用的方式一般都是redis，當然，你也可以選擇其他存儲媒介，比如mysql，或者芒果DB，甚至你用TXT文檔存儲也可以，具體的原理是：
用戶A登錄輸入賬號密碼，登錄系統，系統確認登錄成功，返回用戶A一個很長的字元串(你所說的session)
登錄成功之後，用戶A每次訪問都帶著這個字元串即可(通常都在HTTP頭部，當然你放到form表單中也可以)
不要相信那些所謂的http加密，甚至有人用時間戳這種開玩笑的東西放到URL上，這些人不懂http協議，也不懂加密技術
如果你想更深入的學習一些框架，強烈建議java事實標准，spring security框架，它做到了web安全方面你所有能想到的事情，包括oauth，單調登錄，集群會話，第三方登陸，各種驗證碼，各種許可權控制(許可權強烈不推薦shiro，浪費時間學習)
以上四點是我給初學者的建議
2. 多台web伺服器之間怎麼同步session
這就要用到session復制的庫了
集群session管理
不過我覺得大規模的web服務可以按功能來分布war包，
每個單獨的功能塊打成一個war包，部署到一台伺服器上
這樣，session的問題是減少很多
3. java開發中nginx和tomcat做集群的時候，session怎麼處理求最佳方案
通過redis或者memcache將tomcat的session進行緩存。需要在tomcat的server.xml文件進行設置，替換原有的session管理類。
4. 分布式部署session怎麼共享
session的復制與共享
在web應用中，為了應對大規模訪問,必須實現應用的集群部署.要實現集群部署主要需要實現session共享機制,使得多台應用伺服器之間會話統一, tomcat等多數主流web伺服器都採用了session復制以及實現session的共享. 但問題還是很明顯的：
在節點持續增多的情況下,session復制帶來的性能損失會快速增加.特別是當session中保存了較大的對象,而且對象變化較快時,性能下降更加顯著.這種特性使得web應用的水平擴展受到了限制.
session共享的另一種思路就是把session集中起來管理,首先想到的是採用資料庫來集中存儲session,但資料庫是文件存儲相對內存慢了一個數量級,同時這勢必加大資料庫系統的負擔.所以需要一種既速度快又能遠程集中存儲的服務：memcached
使用memcached來存儲session有兩種方案:
(1)直接通過tomcat6的擴展機制實現.
(2)通過自己編寫filter實現.
考慮到系統的擴展,我們採用這種方案.這樣可以使session共享機制和中間件脫鉤.
主要思路:
1)繼承重構HttpServletRequestWrapper,HttpSessionWrapper類,覆蓋原來和session存取相關的方法呢,都通過SessionService類來實現.
2)使用filter攔截cookie中的sessionId,通過sessionId構造新的HttpServletRequestWrapper對象,傳給後面的應用.
3)SessionService連接memcached服務,以sessionId作為key,存取的對象是一個map.map的內容即為session的內容.
使用過程注意幾個問題和改進思路：
1、memcache的內存應該足夠大，這樣不會出現用戶session從Cache中被清除的問題(可以關閉memcached的對象退出機制)。
2、如果session的讀取比寫入要多很多，可以在memcache前再加一個Oscache等本地緩存，減少對memcache的讀操作，從而減小網路開銷，提高性能。
3、如果用戶非常多，可以使用memcached組，通過set方法中帶hashCode，插入到某個memcached伺服器
5. 如果有多台伺服器做集群的話 如何解決session的問題
會話狀態（Session
State）的機制。而這樣的機制應該可以使Web伺服器從多次單獨的HTTP請求中看到「會話」，也就是知道請求是來自哪個會話的。
具體實現方式為：在會話開始時，分配一個唯一的會話標識（SessionId），通過Cookie把這個標識告訴伺服器，以後每
6. session可以存儲的方式有幾種，如果程序採取分布式，怎麼樣實現session共享
一。分布式Session的幾種實現方式
1.基於資料庫的Session共享
2.基於NFS共享文件系統
3.基於memcached 的session，如何保證 memcached 本身的高可用性？
4. 基於resin/tomcat web容器本身的session復制機制
5. 基於TT/Redis 或 jbosscache 進行 session 共享。
6. 基於cookie 進行session共享
或者是：
一、Session Replication 方式管理 (即session復制)
簡介：將一台機器上的Session數據廣播復制到集群中其餘機器上
使用場景：機器較少，網路流量較小
優點：實現簡單、配置較少、當網路中有機器Down掉時不影響用戶訪問
缺點：廣播式復制到其餘機器有一定廷時，帶來一定網路開銷
二、Session Sticky 方式管理
簡介：即粘性Session、當用戶訪問集群中某台機器後，強制指定後續所有請求均落到此機器上
使用場景：機器數適中、對穩定性要求不是非常苛刻
優點：實現簡單、配置方便、沒有額外網路開銷
缺點：網路中有機器Down掉時、用戶Session會丟失、容易造成單點故障
三、緩存集中式管理
簡介：將Session存入分布式緩存集群中的某台機器上，當用戶訪問不同節點時先從緩存中拿Session信息
使用場景：集群中機器數多、網路環境復雜
優點：可靠性好
缺點：實現復雜、穩定性依賴於緩存的穩定性、Session信息放入緩存時要有合理的策略寫入
二。Session和Cookie的區別和聯系以及Session的實現原理
1、session保存在伺服器，客戶端不知道其中的信息；cookie保存在客戶端，伺服器能夠知道其中的信息。
2、session中保存的是對象，cookie中保存的是字元串。
3、session不能區分路徑，同一個用戶在訪問一個網站期間，所有的session在任何一個地方都可以訪問到。而cookie中如果設置了路徑參數，那麼同一個網站中不同路徑下的cookie互相是訪問不到的。
4、session需要藉助cookie才能正常<nobr oncontextmenu="return false;"
onmousemove="kwM(3);" id="key3" onmouseover="kwE(event,3, this);"
style="COLOR: #6600ff; BORDER-BOTTOM: 0px dotted; BACKGROUND-COLOR:
transparent; TEXT-DECORATION: underline" onclick="return kwC();"
onmouseout="kwL(event, this);"
target="_blank">工作</nobr>。如果客戶端完全禁止cookie，session將失效。
http是無狀態的協議，客戶每次讀取web頁面時，伺服器都打開新的會話，而且伺服器也不會自動維護客戶的上下文信息，那麼要怎麼才能實現網上商店中的
購物車呢，session就是一種保存上下文信息的機制，它是針對每一個用戶的，變數的值保存在伺服器端，通過SessionID來區分不同的客
戶,session是以cookie或URL重寫為基礎的，默認使用cookie來實現，系統會創造一個名為JSESSIONID的輸出cookie，我
們叫做session cookie,以區別persistent
cookies,也就是我們通常所說的cookie,注意session
cookie是存儲於瀏覽器內存中的，並不是寫到硬碟上的，這也就是我們剛才看到的JSESSIONID，我們通常情是看不到JSESSIONID的，但
是當我們把瀏覽器的cookie禁止後，web伺服器會採用URL重寫的方式傳遞Sessionid，我們就可以在地址欄看到
sessionid=KWJHUG6JJM65HS2K6之類的字元串。
明白了原理，我們就可以很容易的分辨出persistent cookies和session
cookie的區別了，網上那些關於兩者安全性的討論也就一目瞭然了，session cookie針對某一次會話而言，會話結束session
cookie也就隨著消失了，而persistent
cookie只是存在於客戶端硬碟上的一段文本（通常是加密的），而且可能會遭到cookie欺騙以及針對cookie的跨站腳本攻擊，自然不如
session cookie安全了。
通常session
cookie是不能跨窗口使用的，當你新開了一個瀏覽器窗口進入相同頁面時，系統會賦予你一個新的sessionid，這樣我們信息共享的目的就達不到
了，此時我們可以先把sessionid保存在persistent
cookie中，然後在新窗口中讀出來，就可以得到上一個窗口SessionID了，這樣通過session cookie和persistent
cookie的結合我們就實現了跨窗口的session tracking（會話跟蹤）。
在一些web開發的書中，往往只是簡單的把Session和cookie作為兩種並列的http傳送信息的方式，session
cookies位於伺服器端，persistent
cookie位於客戶端，可是session又是以cookie為基礎的，明白的兩者之間的聯系和區別，我們就不難選擇合適的技術來開發web
service了。
總之：
一、cookie機制和session機制的區別
具體來說cookie機制採用的是在客戶端保持狀態的方案，而session機制採用的是在伺服器端保持狀態的方案。
同時我們也看到，由於在伺服器端保持狀態的方案在客戶端也需要保存一個標識，所以session機制可能需要藉助於cookie機制來達到保存標識的目的，但實際上還有其他選擇。
二、會話cookie和持久cookie的區別
如果不設置過期時間，則表示這個cookie生命周期為瀏覽器會話期間，只要關閉瀏覽器窗口，cookie就消失了。這種生命期為瀏覽會話期的cookie被稱為會話cookie。會話cookie一般不保存在硬碟上而是保存在內存里。
如果設置了過期時間，瀏覽器就會把cookie保存到硬碟上，關閉後再次打開瀏覽器，這些cookie依然有效直到超過設定的過期時間。
存儲在硬碟上的cookie可以在不同的瀏覽器進程間共享，比如兩個IE窗口。而對於保存在內存的cookie，不同的瀏覽器有不同的處理方式。
三、如何利用實現自動登錄
當用戶在某個網站注冊後，就會收到一個惟一用戶ID的cookie。客戶後來重新連接時，這個用戶ID會自動返回，伺服器對它進行檢查，確定它是否為注冊用戶且選擇了自動登錄，從而使用戶無需給出明確的用戶名和密碼，就可以訪問伺服器上的資源。
四、如何根據用戶的愛好定製站點
網站可以使用cookie記錄用戶的意願。對於簡單的設置，網站可以直接將頁面的設置存儲在cookie中完成定製。然而對於更復雜的定製，網站只需僅將一個惟一的標識符發送給用戶，由伺服器端的資料庫存儲每個標識符對應的頁面設置。
五、cookie的發送
1.創建Cookie對象
2.設置最大時效
3.將Cookie放入到HTTP響應報頭
如果你創建了一個cookie，並將他發送到瀏覽器，默認情況下它是一個會話級別的cookie:存儲在瀏覽器的內存中，用戶退出瀏覽器之後被刪除。如
果你希望瀏覽器將該cookie存儲在磁碟上，則需要使用maxAge，並給出一個以秒為單位的時間。將最大時效設為0則是命令瀏覽器刪除該
cookie。
發送cookie需要使用HttpServletResponse的addCookie方法，將cookie插入到一個 Set-Cookie
HTTP請求報頭中。由於這個方法並不修改任何之前指定的Set-Cookie報頭，而是創建新的報頭，因此我們將這個方法稱為是addCookie，而
非setCookie。同樣要記住響應報頭必須在任何文檔內容發送到客戶端之前設置。
六、cookie的讀取
1.調用request.getCookie
要獲取有瀏覽器發送來的cookie，需要調用HttpServletRequest的getCookies方法，這個調用返回Cookie對象的數組，對應由HTTP請求中Cookie報頭輸入的值。
2.對數組進行循環，調用每個cookie的getName方法，直到找到感興趣的cookie為止
cookie與你的主機(域)相關，而非你的servlet或JSP頁面。因而，盡管你的servlet可能只發送了單個cookie，你也可能會得到許多不相關的cookie。
例如：
String cookieName = 「userID」;
Cookie cookies［］ = request.getCookies();
if (cookies!=null){
for(int i=0;i
Cookie
cookie = cookies［i］;
if (cookieName.equals(cookie.getName())){
doSomethingWith(cookie.getValue());
}
}
}
七、如何使用cookie檢測初訪者
A.調用HttpServletRequest.getCookies()獲取Cookie數組
B.在循環中檢索指定名字的cookie是否存在以及對應的值是否正確
C.如果是則退出循環並設置區別標識
D.根據區別標識判斷用戶是否為初訪者從而進行不同的操作
八、使用cookie檢測初訪者的常見錯誤
不能僅僅因為cookie數組中不存在在特定的數據項就認為用戶是個初訪者。如果cookie數組為null，客戶可能是一個初訪者，也可能是由於用戶將cookie刪除或禁用造成的結果。
但是，如果數組非null,也不過是顯示客戶曾經到過你的網站或域，並不能說明他們曾經訪問過你的servlet。其它servlet、JSP頁面以及
非Java Web應用都可以設置cookie，依據路徑的設置，其中的任何cookie都有可能返回給用戶的瀏覽器。
正確的做法是判斷cookie數組是否為空且是否存在指定的Cookie對象且值正確。
九、使用cookie屬性的注意問題
屬性是從伺服器發送到瀏覽器的報頭的一部分；但它們不屬於由瀏覽器返回給伺服器的報頭。
因此除了名稱和值之外，cookie屬性只適用於從伺服器輸出到客戶端的cookie；伺服器端來自於瀏覽器的cookie並沒有設置這些屬性。
因而不要期望通過request.getCookies得到的cookie中可以使用這個屬性。這意味著，你不能僅僅通過設置cookie的最大時效，
發出它，在隨後的輸入數組中查找適當的cookie,讀取它的值，修改它並將它存回Cookie，從而實現不斷改變的cookie值。
十、如何使用cookie記錄各個用戶的訪問計數
1.獲取cookie數組中專門用於統計用戶訪問次數的cookie的值
2.將值轉換成int型
3.將值加1並用原來的名稱重新創建一個Cookie對象
4.重新設置最大時效
5.將新的cookie輸出
十一、session在不同環境下的不同含義
session，中文經常翻譯為會話，其本來的含義是指有始有終的一系列動作/消息，比如打電話是從拿起電話撥號到掛斷電話這中間的一系列過程可以稱之為一個session。
然而當session一詞與網路協議相關聯時，它又往往隱含了「面向連接」和/或「保持狀態」這樣兩個含義。
session在Web開發環境下的語義又有了新的擴展，它的含義是指一類用來在客戶端與伺服器端之間保持狀態的解決方案。有時候Session也用來指這種解決方案的存儲結構。
十二、session的機制
session機制是一種伺服器端的機制，伺服器使用一種類似於散列表的結構(也可能就是使用散列表)來保存信息。
但程序需要為某個客戶端的請求創建一個session的時候，伺服器首先檢查這個客戶端的請求里是否包含了一個session標識－稱為session
id,如果已經包含一個session id則說明以前已經為此客戶創建過session，伺服器就按照session
id把這個session檢索出來使用(如果檢索不到，可能會新建一個，這種情況可能出現在服務端已經刪除了該用戶對應的session對象，但用戶人為
地在請求的URL後面附加上一個JSESSION的參數)。
如果客戶請求不包含session id，則為此客戶創建一個session並且生成一個與此session相關聯的session id，這個session id將在本次響應中返回給客戶端保存。
十三、保存session id的幾種方式
A．保存session id的方式可以採用cookie，這樣在交互過程中瀏覽器可以自動的按照規則把這個標識發送給伺服器。
B．
由於cookie可以被人為的禁止，必須有其它的機制以便在cookie被禁止時仍然能夠把session
id傳遞回伺服器，經常採用的一種技術叫做URL重寫，就是把session
id附加在URL路徑的後面，附加的方式也有兩種，一種是作為URL路徑的附加信息，另一種是作為查詢字元串附加在URL後面。網路在整個交互過程中始終
保持狀態，就必須在每個客戶端可能請求的路徑後面都包含這個session
id。
C．另一種技術叫做表單隱藏欄位。就是伺服器會自動修改表單，添加一個隱藏欄位，以便在表單提交時能夠把session id傳遞回伺服器。
十四、session什麼時候被創建
一個常見的錯誤是以為session在有客戶端訪問時就被創建，然而事實是直到某server端程序(如Servlet)調用HttpServletRequest.getSession(true)這樣的語句時才會被創建。
十五、session何時被刪除
session在下列情況下被刪除：
A．程序調用HttpSession.invalidate()
B．距離上一次收到客戶端發送的session id時間間隔超過了session的最大有效時間
C．伺服器進程被停止
再次注意關閉瀏覽器只會使存儲在客戶端瀏覽器內存中的session cookie失效，不會使伺服器端的session對象失效。
7. Java，我做一個web項目的注銷，怎麼清除session里的值，
java web 項目清楚session的方法是：繼承SessionAware類來取得session,然後用invalidate()方法清理
{
@Override
publicStringexecute()throwsException{
HttpServletRequestrequest=ServletActionContext.getRequest();
HttpSessionsession1=request.getSession();
session1.invalidate();
returnsuper.execute();
}
publicvoidsetSession(Maparg0){
}
}
//第二種方法（用ActionContext取session,然後用clear()方法清理）
{
@Override
publicStringexecute()throwsException{
ActionContextac=ActionContext.getContext();
Mapsession=ac.getSession();
session.remove("buser");
session.remove("guser");
session.remove("fuser");
returnsuper.execute();
}
}
8. web集群怎麼共享同步sessionWindows伺服器操作系統
首先向memcached中添加「tokyo」。將「tokyo」傳給客戶端程序庫後，客戶端實現的演算法就會根據「鍵」來決定保存數據的memcached伺服器。伺服器選定後，即命令它保存「tokyo」及其值。
圖2 分布式簡介：添加時
同樣，「kanagawa」「chiba」「saitama」「gunma」都是先選擇伺服器再保存。接下來獲取保存的數據。獲取時也要將要獲取的鍵「tokyo」傳遞給函數庫。函數庫通過與數據保存時相同的演算法，根據「鍵」選擇伺服器。使用的演算法相同，就能選中與保存時相同的伺服器，然後發送get命令。只要數據沒有因為某些原因被刪除，就能獲得保存的值。
圖3 分布式簡介：獲取時
這樣，將不同的鍵保存到不同的伺服器上，就實現了memcached的分布式。 memcached伺服器增多後，鍵就會分散，即使一台memcached伺服器發生故障無法連接，也不會影響其他的緩存，系統依然能繼續運行。
Php+memcache實現分布式：
9. 分布式站點怎麼解決session
在分布式集群環境下，session的獲取就不能採用request.setSession了。那麼如何解決分布式session的問題呢，有以下幾個方案：
1.tomcat容器自動同步session。
詳見http://www.360doc.com/content/10/0309/14/495229_18116558.shtml
2.其它方案：alibaba b2b採用的cookie的方案，這裡面要關心的是信息的安全，如何防止信息的偽造並提交，這個以後可以研究。至於tair的方案，就是淘寶系現在採用的方案，是有通用代表性的方案
web集群時session同步的3種方法[轉]
在做了web集群後，你肯定會首先考慮session同步問題，因為通過負載均衡後，同一個IP訪問同一個頁面會被分配到不同的伺服器上，如果session不同步的話，一個登錄用戶，一會是登錄狀態，一會又不是登錄狀態。所以本文就根據這種情況給出三種不同的方法來解決這個問題：
一，利用資料庫同步session
1，用一個低端電腦建個資料庫專門存放web伺服器的session，或者，把這個專門的資料庫建在文件伺服器上，用戶訪問web伺服器時，會去這個專門的資料庫check一下session的情況，以達到session同步的目的。
2，這種方法是把存放session的表和其他資料庫表放在一起，如果mysql也做了集群了話，每個mysql節點都要有這張表，並且這張session表的數據表要實時同步。
說明：用資料庫來同步session，會加大資料庫的負擔，資料庫本來就是容易產生瓶頸的地方，如果把session還放到資料庫裡面，無疑是雪上加霜。上面的二種方法，第一點方法較好，把放session的表獨立開來，減輕了真正資料庫的負擔
二，利用cookie同步session
session是存放在伺服器端的，cookie是存放在客戶端的，怎麼實現同步呢？方法很簡單，就是把用戶訪問頁面產生的session放到cookie裡面，就是以cookie為中轉站。你訪問web伺服器A，產生了session把它放到cookie裡面了，你訪問被分配到web伺服器B，這個時候，web伺服器B先判斷伺服器有沒有這個session，如果沒有，在去看看客戶端的cookie裡面有沒有這個session，如果也沒有，說明session真的不存，如果cookie裡面有，就把cookie裡面的sessoin同步到web伺服器B，這樣就可以實現session的同步了。
說明：這種方法實現起來簡單，方便，也不會加大資料庫的負擔，但是如果客戶端把cookie禁掉了的話，那麼session就無從同步了，這樣會給網站帶來損失；cookie的安全性不高，雖然它已經加了密，但是還是可以偽造的。
三，利用memcache同步session
memcache可以做分布式，如果沒有這功能，他也不能用來做session同步。他可以把web伺服器中的內存組合起來，成為一個」內存池」，不管是哪個伺服器產生的sessoin都可以放到這個」內存池」中，其他的都可以使用。
優點：以這種方式來同步session，不會加大資料庫的負擔，並且安全性比用cookie大大的提高，把session放到內存裡面，比從文件中讀取要快很多。
缺點：memcache把內存分成很多種規格的存儲塊，有塊就有大小，這種方式也就決定了，memcache不能完全利用內存，會產生內存碎片，如果存儲塊不足，還會產生內存溢出。
四，總結
上面三種方法都是可行的
第一種方法，最影響系統速度的那種，不推薦使用；
第二種方法，效果不錯，不過安全隱患一樣的存在；
第三種方法，個人覺得第三種方法是最好的，推薦大家使用
10. WEB應用中的SESSION知多少
Session機制採用的是在伺服器端保持狀態的方案。
1、Session在何時被創建
Session在有客戶端訪問時就被創建，然而事實是直到某server端程序調用 HttpServletRequest.getSession(true)這樣的語句時才被創建，注意如果JSP沒有顯示的使用 <%@page Session=」false」%> 關閉Session，則JSP文件在編譯成Servlet時將會自動加上這樣一條語句HttpSession Session = HttpServletRequest.getSession(true);這也是JSP中隱含的Session對象的來歷。由於Session會消耗內存資源，因此，如果不打算使用Session，應該在所有的JSP中關閉它。
2、Session何時被刪除
綜合前面的討論，Session在下列情況下被刪除：
a.程序調用HttpSession.invalidate();
b.距離上一次收到客戶端發送的Session id時間間隔超過了Session的超時設置;
c.伺服器進程被停止（非持久Session）。
3、如何做到在瀏覽器關閉時刪除Session
嚴格的講，做不到這一點。可以做一點努力的辦法是在所有的客戶端頁面里使用javascript代碼window.oncolose來監視瀏覽器的關閉動作，然後向伺服器發送一個請求來刪除Session。但是對於瀏覽器崩潰或者強行殺死進程這些非常規手段仍然無能為力。
4、有個HttpSessionListener是怎麼回事
你可以創建這樣的listener去監控Session的創建和銷毀事件，使得在發生這樣的事件時你可以做一些相應的工作。注意是Session的創建和銷毀動作觸發listener，而不是相反。類似的與HttpSession有關的listener還有 HttpSessionBindingListener，HttpSessionActivationListener和 HttpSessionAttributeListener。
5、存放在Session中的對象必須是可序列化的嗎
不是必需的。要求對象可序列化只是為了Session能夠在集群中被復制或者能夠持久保存或者在必要時server能夠暫時把Session交換出內存。在Weblogic Server的Session中放置一個不可序列化的對象在控制台上會收到一個警告。
6、開兩個瀏覽器窗口訪問應用程序會使用同一個Session還是不同的Session
對Session來說是只認id不認人，因此不同的瀏覽器，不同的窗口打開方式以及不同的cookie存儲方式都會對這個問題的答案有影響。
7、如何防止用戶打開兩個瀏覽器窗口操作導致的Session混亂
這個問題與防止表單多次提交是類似的，可以通過設置客戶端的令牌來解決。就是在伺服器每次生成一個不同的id返回給客戶端，同時保存在Session里，客戶端提交表單時必須把這個id也返回伺服器，程序首先比較返回的id與保存在Session里的值是否一致，如果不一致則說明本次操作已經被提交過了。可以參看《J2EE核心模式》關於表示層模式的部分。需要注意的是對於使用javascript window.open打開的窗口，一般不設置這個id，或者使用單獨的id，以防主窗口無法操作，建議不要再window.open打開的窗口裡做修改操作，這樣就可以不用設置。
8、為什麼Session不見了
排除Session正常失效的因素之外，伺服器本身的可能性應該是微乎其微的；理論上防火牆或者代理伺服器在cookie處理上也有可能會出現問題。出現這一問題的大部分原因都是程序的錯誤，最常見的就是在一個應用程序中去訪問另外一個應用程序。
9、伺服器關掉後，當前Session會丟掉嗎
這個取決於你使用什麼樣的web伺服器以及web伺服器是如何配置的。tomcat在shutdown前默認會自動將Session保存到指定的目錄中，重新啟動是重新載入，因此tomcat重新啟動後，Session是可以繼續使用的。此外，你還何以將Session保存到資料庫中，這個要在 server.xml中配置。
10、Cookie的過期和Session的超時有什麼區別
會話的超時由伺服器來維護，它不同於Cookie的失效日期。首先，會話一般基於駐留內存的cookie不是持續性的cookie，因而也就沒有截至日期。即使截取到JSESSION cookie，並為它設定一個失效日期發送出去。瀏覽器會話和伺服器會話也會截然不同。