『壹』 如何理解會話的含義
jsP的會話跟蹤技術
Cookie：伺服器在一個應答首部傳遞給瀏覽器的名稱/值對。瀏覽器保存的時間由cookie的過期時間屬性來指定。當瀏覽器向某個伺服器發送一個請求時，它會檢查其保存的cookie，並在請求首部中包含從同一台伺服器上接收到的所有cookie。
Session tracking:在瀏覽器和伺服器之間不直接傳送所有的狀態信息，而只是傳遞表示符（session ID）。瀏覽器發送sessionID,伺服器跟蹤與該會話相關聯的所有信息。傳遞sessionID可以通過cookie和URL復寫技術，大部分容器都支持這兩種技術。伺服器無法分辨用戶是否關閉了瀏覽器，因此關閉瀏覽器意味著與先前的會話關聯的所有會話數據都保留在伺服器上，直到會話超時，伺服器銷毀會話對像。
跟蹤同一會話中的請求的會話ID可以有多種方法，主要有cookie和url復寫。
URL復寫：把會話ID編碼在URL中。
例：counter.jjsp;jsessionnid=
這樣，即使瀏覽器不支持cookie，也能夠實現會話跟蹤。
對於URL復寫，伺服器從請求的URI中提取出會話ID，並把該請求與相應的會話關聯起來，然後在訪問會話數據的時候，JSP頁面所進行的處理方式就和使用cookie跟蹤會話id時所使用的方式完全相同。所以sesssion的實現要依靠cookie或URL復寫技術。
如果想為不支持cookie的瀏覽器提供會話跟蹤，就必須使用<c:url>行為對應用程序中的所有URL進行復寫。這意味著應用程序中的所有頁面（至少是那些帶有對其他頁面引用的頁面）都必須是JSP頁面，這樣頁面引用才能以動態方式進行編碼，如果遺漏了一個ur，那麼服務就會失去對會話的跟蹤。
隱藏表單域：隱藏表單域是將會話ID添加到HTML的隱藏表單中(類型為hidden的input)。
重定向和轉發
可以使用兩種方法來調用另一個頁面，重定向和轉發。
i) 轉發：<jsp:forward page=」userInfo.jsp」/>
轉發,JSP容器將使用一個內部方法來調用目標頁面，新的頁面繼續處理同一個請求，而瀏覽器不會知道這個過程涉及到了多個頁面。瀏覽器URL會保持不變。
ii) 重定向:<c:redirect url=」userInfo.jsp」/>
重定向與轉發不同，重定向時，第一個頁面會通知瀏覽器發送一個新的目標頁面的請求。瀏覽器所顯示的URL會變成新頁面的URL。
重定向的速度比轉發要慢，因為瀏覽器得發出一個新的請求。
同時，由於重定向產生了一個新的請求，所以經過一次重定向之後請求作用域內的對象將無法再使用了。
『貳』 如何在html中獲取jsp中的session的值
伺服器跟蹤用戶狀態有好幾種方法，其中一種就是，伺服器保持session，給客戶端一個sessionid，客戶端每次發送請求時，會把這個sessionid提交給伺服器(這是瀏覽器乾的事)，伺服器根據這個sessionid找到相應的session，如果你用的jsp，jsp引擎(比如tomcat)會吧這個session作為一個實例變數放到jsp頁面里，你可以直接使用。如果是html文件，jsp引擎會直接發送給客戶端html文件的內容。
客戶端的js訪問cookie的方法只能訪問存儲在客戶端的cookie(使用js或session的cookie存儲的)。
一般來說，只有伺服器端的CGI程序（ASP、PHP、JSP）具有session會話功能，用來保存用戶在網站期間（會話）的活動數據信息，而對於數量眾多的靜態頁面（HTML）來說，只能使用客戶端的cookies來保存臨時活動數據，但對於cookies的操作是個很煩瑣的過程，遠沒有對於session操作那樣簡便。
為此，本文向讀者推薦一種在DHTML中的解決方案「Persistence技術」，使得在靜態頁面中也能使用session會話功能。
使用保持（Persistence）技術讓我們能夠在當前會話過程中保存一些數據對象到客戶端，它減少了對伺服器的訪問請求，充分發揮了客戶端計算機的數據處理能力，從而也整體提升了頁面顯示效率。
Microsoft Internet Explorer 5瀏覽器和以後的版本都支持使用狀態保持（Persistence）技術，它有以下幾種行為可供調用：
saveFavorite—當頁面被添加到收藏夾時保存頁面狀態和信息
saveHistory—在當前會話中保存頁面狀態和信息
saveSnapshot—當頁面被保存到硬碟時，保存頁面狀態和信息persists
page state and information directly in the page when users save the Web page to
their hard disk.
userData—在當前會話中用XML格式保存頁面狀態和信息 網頁製作
Persistence技術打破了以前使用使用cookies和session的傳統，它繼承了以前cookies的一些安全策略，同時也增加了存儲和管理數據的能力。我們的每個頁面有64KB的用戶數據存儲容量，對於每個站點總計有640KB的存儲上限。
Persistence技術存儲的數據格式符合XML標准，所以可以使用DOM技術中的getAttribute和setAttribute方法來存取數據。
下面是一個Persistence技術的典型應用，通過對Persistence存儲數據的分析，使得靜態頁面具有驗證功能。
實際判斷過程是這樣的：
有三個對象：遊客V、導航頁面A、內容頁面C
遊客V只能通過導航頁面A的鏈接才能看到內容頁面C；
如果遊客V是通過其它途徑來訪問內容頁面C（比如通過其它網站的超鏈接、直接在IE地址欄中輸入網址訪問等），內容頁面C將自動提示版權信息，顯示空白頁。
具體實現步驟：
一、在「導航頁面」中加入一個STYLE用來定義persistent類，同時加入存儲函數fnSave用來授權。
<STYLE>
.userData {behavior:url(#default#userdata);}
</STYLE>
<SCRIPT language=javascript>
網頁編程
function fnSave(){
oPersistDiv.setAttribute("bIsValid","true");
oPersistDiv.save("oXMLStore");
}
</SCRIPT>
二、在「導航頁面」的<body>和</body>區域中定義一個層用來標識Persistence對象
<DIV CLASS=userData ID="oPersistDiv"></DIV>
三、在「導航頁面」的超鏈接屬性中加入一條語句用來調用函數fnSave：
<a href='redhat2.htm' onmousedown="fnSave()">
接下來，為「內容頁面」加入驗證功能：
四、在「內容頁面」中加入一個STYLE用來定義persistent類，同時加入存儲函數fnLoad用來判斷合法性。
<STYLE>
.userData {behavior:url(#default#userdata);}
</STYLE>
<SCRIPT>
var bPageValid=false;
function fnLoad(){
oPersistDiv.load("oXMLStore");
if((oPersistDiv.getAttribute("bIsValid"))&&(oPersistDiv.getAttribute("bIsValid")=="true")){
bPass=true;
網頁模板
}
else{
bPass=false;
}
oPersistDiv.setAttribute("bIsValid","false");
oPersistDiv.save("oXMLStore");
if(bPass==false){
var sError="來源不明，請您通過授權網站訪問我們.";
alert(sError);
location.href="about:blank";
}
}
</SCRIPT>
五、修改「內容頁面」的<body>區域如下：
<BODY onload="fnLoad()">
<DIV CLASS=userData ID="oPersistDiv"></DIV>
從以上範例可看出，通過persistence的使用，使得普通的靜態內容頁面具有了session功能，一般的不敏感信息完全可以通過session保存在客戶端。
另外，如果不明白persistence的使用，也可以這樣，你的首頁上有個form，用來提交用戶名和密碼。如果你把首頁換成html頁面，完全可以，不過要在其他地方接收用戶名和密碼(比如logon.jsp)。form的action設為logon.jsp。很簡單。使用form的action來轉移接受session的地方，首頁就可以用靜態了
『叄』 會話跟蹤有哪些技術
會話跟蹤來技術 是保存用戶和伺服器源之間會話狀態及信息的一種那啥。
是2。
至於1，是四個作用域不同的內置存儲對象。
page 當前頁面有效
request 瀏覽器對伺服器的一次請求有效，伺服器返回請求後失效
session 在伺服器規定會話最長時間范圍內有效，對瀏覽器串口和其子窗口。
application 就是對整個正在運行的項目有效了。
聽我的沒錯，答案是2 回答1的根本沒理解啥是會話跟蹤技術，他們以為是內置存儲對象。
『肆』 誰能詳講JSP四種會話跟蹤技術
找了點資料，你看看吧
一， Cookie：伺服器在一個應答首部傳遞給瀏覽器的名稱/值對。瀏覽器保存的時間由cookie的過期時間屬性來指定。當瀏覽器向某個伺服器發送一個請求時，它會檢查其保存的cookie，並在請求首部中包含從同一台伺服器上接收到的所有cookie。
二 Session tracking:在瀏覽器和伺服器之間不直接傳送所有的狀態信息，而只是傳遞表示符（session ID）。瀏覽器發送sessionID,伺服器跟蹤與該會話相關聯的所有信息。傳遞sessionID可以通過cookie和URL復寫技術，大部分容器都支持這兩種技術。伺服器無法分辨用戶是否關閉了瀏覽器，因此關閉瀏覽器意味著與先前的會話關聯的所有會話數據都保留在伺服器上，直到會話超時，伺服器銷毀會話對像。
®跟蹤同一會話中的請求的會話ID可以有多種方法，主要有cookie和url復寫。
三 URL復寫：把會話ID編碼在URL中。
例：counter.jjsp;jsessionnid=
這樣，即使瀏覽器不支持cookie，也能夠實現會話跟蹤。
對於URL復寫，伺服器從請求的URI中提取出會話ID，並把該請求與相應的會話關聯起來，然後在訪問會話數據的時候，JSP頁面所進行的處理方式就和使用cookie跟蹤會話id時所使用的方式完全相同。所以sesssion的實現要依靠cookie或URL復寫技術。
如果想為不支持cookie的瀏覽器提供會話跟蹤，就必須使用<c:url>行為對應用程序中的所有URL進行復寫。這意味著應用程序中的所有頁面（至少是那些帶有對其他頁面引用的頁面）都必須是JSP頁面，這樣頁面引用才能以動態方式進行編碼，如果遺漏了一個ur，那麼服務就會失去對會話的跟蹤。
四 隱藏表單域：隱藏表單域是將會話ID添加到HTML的隱藏表單中(類型為hidden的input)。
重定向和轉發
可以使用兩種方法來調用另一個頁面，重定向和轉發。
i) 轉發：<jsp:forward page=」userInfo.jsp」/>
轉發,JSP容器將使用一個內部方法來調用目標頁面，新的頁面繼續處理同一個請求，而瀏覽器不會知道這個過程涉及到了多個頁面。瀏覽器URL會保持不變。
ii) 重定向:<c:redirect url=」userInfo.jsp」/>
重定向與轉發不同，重定向時，第一個頁面會通知瀏覽器發送一個新的目標頁面的請求。瀏覽器所顯示的URL會變成新頁面的URL。
重定向的速度比轉發要慢，因為瀏覽器得發出一個新的請求。
同時，由於重定向產生了一個新的請求，所以經過一次重定向之後請求作用域內的對象將無法再使用了。
『伍』 servlet使用的會話跟蹤除session外還有哪些方式
HTTP是一種無連接的協議，如果一個客戶端只是單純地請求一個文件（HTML或GIF），伺服器端可以響應給客戶端，並不需要知道一連串的請求是否來自於相同的客戶端，而且也不需要擔心客戶端是否處在連接狀態。但是這樣的通信協議使得伺服器端難以判斷所連接的客戶端是否是同一個人。當進行Web程序開發時，我們必須想辦法將相關的請求結合一起，並且努力維持用戶的狀態在伺服器上，這就引出了會話追蹤（session tracking）。
1:會話與會話追蹤
session中文經常翻譯為「會話」，其本來的含義是指有始有終的一系列動作或消息，比如打電話時從拿起電話撥號到掛斷電話這中間的一系列過程可以稱之為一個session。有時候可以看到這樣的話「在一個瀏覽器會話期間……」，這里的會話一詞用的就是其本義，是指從一個瀏覽器窗口打開到關閉這個期間；如果說「用戶在一次會話期間……」這樣一句話，它指用戶的一系列動作，比如從登錄到選購商品到結賬登出這樣一個網上購物的過程；然而有時候也可能僅僅是指一次連接。session的含義很多，其中的差別只能靠上下文來推斷。session tracking（會話追蹤）是指一類用來在客戶端與伺服器之間保持狀態的解決方案，簡單地說，當一個客戶在多個頁面間切換時，伺服器會保存該用戶的信息。
2:實現會話追蹤的4種方式會話追蹤的實現方式有下列4種方式：
（1）使用持續Cookies（Persistent Cookies）。
（2）重寫包含額外參數的URL（URL Rewriting）。
（3）建立含有數據的隱藏表單欄位（Hidden Form Field）。
（4）使用內建session對象。
前三種會話追蹤方式是傳統的做法，每種做法都有缺點。最後一種方法是目前最常用，也是最有效的解決方案，因此在這里將把討論重心放在第4種會話追蹤方式上，然而為求徹底了解會話追蹤的機制，還是先將傳統的會話追蹤方式先做一番介紹。(這里和我的理解不太一樣，記錄下我的理解，Session的機制是 Java Servlet 規范規定的，而tomcat container實現了這個規定，tomcat 是通過cookie 和 url rewriting的方式來實現的，也就是通過cookie 或url rewriting 保存一個seesionID, 這樣在內部tomcat 把這個sesionID和一個Map聯系起來，達到將變數和session聯系起來的目的。所以第一和第二中方法是tomcat或其他servlet container實現session機制的手段，當然我們也可以自己實現。而第三種方法只是在兩個頁面跳轉時傳遞變數的一種方式，要想用這種方式實現sesion機制還是不太現實，要每個頁面都寫下hidden數據，而且要寫下所有要傳的變數。)
2.1:使用Cookie
Cookie是一個小小的文本文件，它是將會話信息記錄在這個文本文件內，每個頁面都去Cookie中提取以前的會話信息。例如：
String sessionID = makeUniqueString();
HashMap sessionInfo = new HashMap();
HashMap globalTable = findTableStoringSessions();
globalTable.put(sessionID, sessionInfo);
Cookie sessionCookie =new Cookie("JSESSIONID", sessionID);
sessionCookie.setPath("/");
response.addCookie(sessionCookie);
上面這段代碼先將會話信息記錄在HashMap中，保存在伺服器端，並用sessionID標識，然後把sessionID保存在名為「JSESSIONID」的Cookie中。
Cookie[] cookies = request.getCookies();
String sessionid = null;
HashMap sessionInfo = null;
HashMap globalTable = findTableStoringSessions();
if(cookies!=null){
for(int i=0;i<cookies.length;i++){
if(cookies[i].getName().equals("JSESSIONID")){
sessionid = cookies[i].getValue();
break;
}
}
if(sessionid!=null){
sessionInfo = globalTable.get(sessionid);
//We can use the sessionInfo to get value that we want
}
}
用戶請求到達伺服器後，先從Cookie中取出sessionID，然後從HashMap中取出會話信息。這樣就實現了會話追蹤。
雖然Cookie強大且持續性高，但是由於有些用戶因為擔心Cookie對個人隱私的威脅，會關閉Cookie，一旦如此，便無法利用Cookie來達到會話追蹤的功能。
2.2:URL重寫
URL重寫是利用GET的方法，在URL的尾部添加一些額外的參數來達到會話追蹤（session tracking）的目的，伺服器將這個標識符與它所存儲的有關會話的數據關聯起來。URL看起來如下：
http://host/path/file.html;jsessionid=1234,
使用URL重寫的優點是Cookie被禁用或者根本不支持的情況下依舊能夠工作。但也有很多缺點：
1. 必須對所有指向您的網站的URL進行編碼。
2. 所有頁面必須動態生成。
3. 不能使用預先記錄下來的URL進行訪問，或者從其他網站鏈接進行訪問。
2.3:隱藏表單欄位
隱藏表單欄位的方法，是利用HTML內hidden的屬性，把客戶端的信息，在用戶不察覺的情形下，偷偷地隨著請求一起傳送給到伺服器處理，這樣一來，就可以進行會話跟蹤的任務了。可以下列的方法來做隱藏表單欄位的會話追蹤。
<input type="hidden" name="userID" value="15">
然後將重要的用戶信息，如ID之類獨一無二的數據，以隱藏欄位的方式傳送給伺服器。隱藏欄位的優點在於session數據傳送到伺服器端時，並不象GET的方法，會將session數據保露在URL之上。不過這種做法還是有它的缺點：一旦session數據儲存在隱藏欄位中，就仍然有暴露數據的危機，因為只要用戶直接觀看HTML的源文件，session數據將會暴露無疑。這將造成安全上的漏洞，特別當用戶數據是依賴於用戶ID、密碼來取得的時候，將會有被盜用的危險。另外這種方法只適用特定的一個流程，不適用於通常意義的會話跟蹤。2.4:使用內建session對象
傳統的會話追蹤方式使用比較麻煩，Servlet的會話機制基於Cookie或URL重寫技術，融合了這兩種技術的優點。當客戶端允許使用Cookie時，內建session對象使用Cookie進行會話追蹤；如果客戶端禁用Cookie，則選擇使用URL重寫。
（1）獲取session對象例如把購物車作為屬性存儲在session中，在其他JSP頁面中可以通過session再獲得購物車。
// 在JSP頁面中可以直接使用session
ShoppingCart cart = (ShoppingCart)session.getAttribute("cart");
內建的session對象是javax.servlet.http.HttpSession類的實例，如果在JavaBean或者Servlet中使用session就需要先從當前的request對象中取得，例如：
// 得到用戶session和購物籃
HttpSession session = request.getSession();
ShoppingCart cart = (ShoppingCart)session.getAttribute("cart");
（2）讀寫session中的數據向session中存入對象使用setAttribute方法，通過getAttribute方法讀取對象。從session返回的值注意要轉換成合適的類型，要注意檢查結 果是否為null。例如下面一段代碼：
HttpSession session = request.getSession();
SomeClass value = (SomeClass)session.getAttribute("someID");
if (value == null) {
value = new SomeClass(...);
session.setAttribute("someID", value);
}
doSomethingWith(value);
（3）廢棄session數據調用removeAttribute廢棄session中的值，即移除與名稱關聯的值。
調用invalidate廢棄整個session，即廢棄當前的session。
如果用戶注銷離開站點，注意廢棄與用戶相關聯的所有session。
（4）session的生命周期由於沒有辦法知道HTTP客戶端是否不再需要session，因此每個session都關聯一個時間期限使它的資源可以被回收。setMaxInactiveInterval(int secondsToLive)
（5）伺服器使用session時,默認使用Cookie技術進行會話追蹤，通常，會話管理是通過伺服器將 Session ID 作為一個 cookie 存儲在用戶的 Web 瀏覽器中，並用它來唯一標識每個用戶會話。如果客戶端不接受Cookie的時候，伺服器可以利用URL重寫的方式將sessionID作為參數附在URL後面，來實現會話管理。當我們在進行forward,redirect時，一定要調用下邊兩個方法，以保持session一直有效（如果不調用的話，那麼你到了新的頁面時session就失效了，因為session ID沒有傳過來）
Servlet中Interface HttpServletResponse 規定了兩個方法，response.encodeURL()或response.encodeRedirectURL()方法，這兩個方法首先判斷Cookies是否被瀏覽器支持；如果支持，則參數URL被原樣返回，session ID將通過Cookies來維持；否則返回帶有sessionID的URL。Tomcat伺服器實現了這兩個方法。
下面是使用encodeURL方法的示例，兩個文件hello1.jsp和hello2.jsp。
a: hello1.jsp的完整程序代碼如下：
<%@ page contentType="text/html;charset=gb2312"%>
<%String url =response.encodeURL("hello2.jsp");%>
<a href='<%=url%>'>進入到hello2.jsp</a>
b: 解釋:
hello1.jsp利用了response對象內的encodeURL方法，將URL做了一個編碼動作。編碼不是這里關心的重點，重點是如果瀏覽器的cookie被禁用的話那麼象;jsessionid= 這樣字元串就會被添加到 hello2.jsp 的後面，也就是告訴了下一個頁面session的信息。b: 若要使用重定向，例如:
response.sendRedirect("hello2.jsp");也應該改為:response.sendRedirect(response.encodeRedirectURL("hello2.jsp"));同時需要注意的是，將session的ID以URL的編碼方式進行時，需將每一頁都編碼，才能保留住session的ID。如果遇到沒有編碼的URL，則無法進行會話跟蹤。
c: hello2.jsp的完整程序代碼如下：
<%@ page contentType="text/html;charset=gb2312"%>
<% out.println("sessionID is "+session.getId());%>
d: 可以看到如果伺服器使用URL重寫，它將會話信息附加到URL上，如下所示：
http://localhost:8080/ch09/hello2.jsp;jsessionid=
e: 實質上 URL 重寫是通過向 URL 連接添加參數，並把 session ID 作為值包含在連接中,以便應用伺服器可以根據sessionID從cache中的取回session.
TOMCAT伺服器
SESSION實現會話跟蹤通常是cookie和url重寫，如果瀏覽器不禁止cookie的話，tomcat優先使用cookie實現，否則它將使用URL重寫來支持SESSION.
URL重寫的額外數據是伺服器自動添加的，那麼伺服器是怎麼添加的呢？Tomcat在返回Response的時候，檢查JSP頁面中所有的URL，包括所有的鏈接，和 Form的Action屬性，在這些URL後面加上「;jsessionid=xxxxxx」。添加url後綴的代碼片段如下：
org.apache.coyote.tomcat5.CoyoteResponse類的toEncoded()方法支持URL重寫。
1 StringBuffer sb = new StringBuffer(path);
2 if( sb.length() > 0 ) { // jsessionid can't be first.
3 sb.append(";jsessionid=");
4 sb.append(sessionId);
5 }
6 sb.append(anchor);
7 sb.append(query);
8 return (sb.toString());