絕大多數的手機瀏覽器都不支持Cookie,而session判斷用戶是要依賴cookie的。瀏覽器
這是由於Session須要使用Cookie做爲識別標誌。HTTP協議是無狀態的,Session不能依據HTTP鏈接來判斷是否爲同一客戶,所以服務器向客戶端瀏覽器發送一個名爲JSESSIONID的Cookie,它的值爲該Session的id(也就是HttpSession.getId()的返回值)。Session依據該Cookie來識別是否爲同一用戶。服務器
這是由於Session須要使用Cookie做爲識別標誌。HTTP協議是無狀態的,Session不能依據HTTP鏈接來判斷是否爲同一客戶,所以服務器向客戶端瀏覽器發送一個名爲JSESSIONID的Cookie,它的值爲該Session的id(也就是HttpSession.getId()的返回值)。Session依據該Cookie來識別是否爲同一用戶。cookie
新開的瀏覽器窗口會生成新的Session,但子窗口除外。子窗口會共用父窗口的Session。例如,在連接上右擊,在彈出的快捷菜單中選擇"在新窗口中打開"時,子窗口即可以訪問父窗口的Session。session
Tomcat中Session的默認失效時間爲20分鐘。若是咱們敲代碼的時候把它設置成1個月,那麼這一個月的數據會代替默認20分鐘的數據,使session的失效時間爲一個月。url
不會,每個session都會有一個sessionid並且是惟一的,不可能存在干擾的。seeion是對話變量,每一個用戶對話有本身特有的sesion。spa
客戶端訪問服務器的時候迴帶上cookie,若是cookie裏面存了sessionid,那麼服務器一會兒就能判斷用戶了。code
客戶端第一次帶的cookie是沒有sessionid的,登陸以後,那麼cookie中就有sessionid了,而後在cookie和session的有效期裏面,服務器端就能判斷用戶。服務器端是根據sessionid來判斷用戶的,每個用戶的sessionid都不一樣。blog
例如,絕大多數的手機瀏覽器都不支持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中。內存
Session存儲在服務器端,通常爲了防止在服務器的內存中(爲了高速存取),Sessinon在用戶訪問第一次訪問服務器時建立,須要注意只有訪問JSP、Servlet等程序時纔會建立Session,只訪問HTML、IMAGE等靜態資源並不會建立Session,可調用request.getSession(true)強制生成Session。
1. 服務器會把長時間沒有活動的Session從服務器內存中清除,此時Session便失效。Tomcat中Session的默認失效時間爲20分鐘。
2. 調用Session的invalidate方法。
雖然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了。
奇怪,不一樣用戶使用同名session會互相干擾嗎
session是在應用網頁的ASP中直接使用的,若是第二個用戶也用到這個網頁,會取到第一個用戶存在該session的值.
個人網頁直接使用
Session("SessionDis") = "1"
是否是須要在Global.asa中定義?
若是會干擾,那你session("username")不是沒用啦,每個session都會有一個sessionid並且是惟一的
IIS根據客戶端IP和客戶端瀏覽器cookie來區分用戶
因此不會干擾
不可能存在干擾的。seeion是對話變量,每一個用戶對話有本身特有的sesion。
客戶端訪問服務器的時候迴帶上cookie,若是cookie裏面存了sessionid,那麼服務器一會兒就能判斷用戶了。
客戶端第一次帶的cookie是沒有sessionid的,登陸以後,那麼cookie中就有sessionid了,而後在cookie和session的有效期裏面,服務器端就能判斷用戶。服務器端是根據sessionid來判斷用戶的,每個用戶的sessionid都不一樣。