概述

要想了解會話跟蹤技術，我想我們要先了解一下會話是什么，以及會話跟蹤技術存在的意義。

首先我們要說的是:會話。

會話 ：見名知意，在現(xiàn)實中我們能想到的是兩個人之間的對話，但在web中，對話的兩個對象就應該是客戶端和服務端，也就是兩者產生了連接之后，就產生了會話，直到一端中斷此會話，會話結束。值得注意的是：一次會話期間客戶端可以發(fā)送多個請求給服務端，也就是可以訪問多次資源。

出現(xiàn)的問題 ：由上我們知道，一次會話可以發(fā)送多次請求，但是如果我們使用的是HTTP協(xié)議進行資源的傳輸，那么多次請求之間是無法進行數(shù)據(jù)共享的。因為HTTP協(xié)議是無狀態(tài)的，也就是無論我們向服務器發(fā)送多少次請求，服務器都會認定為是第一次請求。為了解決多次請求之間的數(shù)據(jù)共享問題，我們引入了會話跟蹤技術。

會話跟蹤：一種維護瀏覽器狀態(tài)的方法，它可以幫助服務器識別多次請求是否來源于同一瀏覽器，以便實現(xiàn)同一會話中的不同請求之間的數(shù)據(jù)共享。

會話跟蹤的技術實現(xiàn)：

1.客戶端會話跟蹤技術：Cookie

2.服務端會話跟蹤技術：Session

Cookie

客戶端會話跟蹤技術，將數(shù)據(jù)保存到客戶端，以后每次請求都攜帶Cookie數(shù)據(jù)進行訪問。

用處：例如當我們第一次訪問某服務器時，服務器會發(fā)送給我們一個kookie，kookie中存放著一些數(shù)據(jù)，瀏覽器將次cookie保存，當我們再次訪問次服務器時就會攜帶保存的cookie，服務器會讀取我們我們請求中的kookie，做一些事情。

我們作為后端，也就是服務器端，就要知道kookie的封裝、發(fā)送和讀取的方式。

封裝發(fā)送 Cookie

在此使用boot工程進行測試，不用boot工程也是沒問題的，使用response.addCookie()將創(chuàng)建好的cookie影響出去就行。

@GetMapping
public String cookieTest(HttpServletResponse response){
    //創(chuàng)建cookie
    Cookie cookie = new Cookie("name", "Tom");
    //發(fā)送cookie
    response.addCookie(cookie);
    return "send...ok";
}

使用postman進行接口測試：

訪問后是可以看到cookie發(fā)送成功的

獲取客戶端請求時攜帶的cookie

@PostMapping
public String cookieTest1(HttpServletRequest request){
    Cookie[] cookies = request.getCookies();
    String name = cookies[0].getName();
    String value = cookies[0].getValue();
    System.out.println("cookieName:" + name + ",value:" + value);
    return "OK";
}

結果成功打印請求攜帶的cookie：

Cookie原理

Cookie的實現(xiàn)是基于HTTP協(xié)議的，cookie存在于請求頭中，查看請求頭信息：

會看到cookie的身影。

Cookie由服務器發(fā)送給客戶端，客戶端訪問的時候會攜帶cookie。

Cookie的生命周期

默認情況下，Cookie存儲在瀏覽器內存中，當瀏覽器關閉，內存釋放，則cookie被銷毀。

我們可以設置Cookie的生命周期，設置方式：

setMaxAge(int seconds) --seconds設置存儲時間，單位為秒

參數(shù)：正數(shù)：將cookie寫入磁盤，持久化存儲，到期自動刪除。

負數(shù)：默認值，瀏覽器關閉，cookie銷毀。

零：刪除對應cookie。

Cookie存儲中文說明（URL編碼介紹）

Cookie不能直接存儲中文，會出現(xiàn)亂碼問題， 解決：URL編碼和解碼

在進行Cookie的發(fā)送的時候，將中文數(shù)據(jù)進行URL編碼后發(fā)送。

在獲取Cookie的時候，進行RUL解碼操作，獲取到中文的Cookie數(shù)據(jù)。

如下圖：以%符號包裹著十六進制就是進行了URL編碼后的字符串格式。其原理呢就是將我們的中文字符轉為二進制后再轉為十六進制加上%包裹而成。

亂碼過程：在web傳輸過程中，實際上是以URL編碼后的字符串格式進行傳輸?shù)模覀冊趧?chuàng)建cookie發(fā)送后，實際上是自動將數(shù)據(jù)以utf-8字符集進行RUL編碼，到Tomcat后以ISO8859-1字符集進行RUL解碼操作，兩者使用的字符集不一致，導致亂碼。

解決：

所以我們可以手動的將字符集進行設置就可以解決次問題。

一般使用cookie也不會使用中文，所以了解即可。

如果想了解URL編碼，Java給我們提供了相應工具類：

參考使用如下：

String info =“你好，URL編碼!";
string encode = URLEncoder.encode(info,enc: "utf-8");
System.out.println(encode);
string decode = URLDecoder.decode(encode,enc: "IS0-8859-1"");
system.out.println(decode);
//使用iso-8859-1解碼后的亂碼，字節(jié)數(shù)依然不變。
//所以，可以將亂碼，轉為utf-8編碼格式的字節(jié)。
byte[] bytes = decode.getBytes( charsetName: "IS0-8859-1"");
//再將字節(jié)轉為字符串即可解決doGet()亂碼問題。
string s = new String(bytes,charsetName: "utf-8");
system.out.println(s);

Session

服務器端會話跟蹤技術，數(shù)據(jù)存儲在服務端。Session的實現(xiàn)是基于Cookie的。

作用

可以使用session作登錄的"記住賬號密碼"功能，session的數(shù)據(jù)存儲在服務器，更安全，當用戶訪問登錄頁面，獲取用戶session中數(shù)據(jù)，自動填寫登錄。

關于Session的方法：

1.setAttribute(String name,Object obj):存儲數(shù)據(jù)到session域中。

2.getAttribute(String name):根據(jù)name獲取對應值。

3.removeAttribute(String name):根據(jù)name刪除該session。

存儲和讀取數(shù)據(jù)

下面進行測試，不必在意測試寫法，只需關注如何創(chuàng)建session，存儲數(shù)據(jù)和獲取數(shù)據(jù)即可。（在表現(xiàn)層使用HttpServletRequest對象調用方法就可以）

@PutMapping
public String sessionTest(HttpServletRequest request){
    //創(chuàng)建session并存儲數(shù)據(jù)
    HttpSession session = request.getSession();
    session.setAttribute("name","Tom");
    return "OK";
}
@DeleteMapping
public String sessionTest1(HttpServletRequest request){
    //獲取session
    HttpSession session = request.getSession();
    Object name = session.getAttribute("name");
    System.out.println(name);
    return "OK";
}

測試結果

結果說明：看紅框內數(shù)據(jù)就好，上面的是cookie測試的結果。

session過程：我們看到name和value是不可看到的，因為使用session，數(shù)據(jù)是存儲在服務器的，返回來的相當于一個"鑰匙"，當我們使用這把"鑰匙"去訪問服務器，就會進行匹配，匹配成功就可以獲取數(shù)據(jù)。由此可推出一個結論：session的數(shù)據(jù)存儲是更安全的。

Session的鈍化和活化

我們知道，session的數(shù)據(jù)是存儲在服務器內存中的，但是有個問題，如果服務器重啟，session存儲的數(shù)據(jù)是否還存在？

要說明這個問題，就要提到兩個概念：鈍化和活化

鈍化：服務器正常關閉時，Tomcat會自動將session存儲的數(shù)據(jù)寫到磁盤中。

活化：服務器再次啟動時，會讀取磁盤中的數(shù)據(jù)到session中。

鈍化過程：正常關閉時，Tomcat會自動將Session數(shù)據(jù)序列化后保存到Session.ser文件中，再次啟動服務器時，會重新讀取數(shù)據(jù)。將Session.ser文件刪除。

Session的銷毀（生命周期）

自動銷毀（到期時間）

我相信大家一定有過這樣的經歷：在某頁面操作時，如果在頁面待久了未操作，然后點擊某按鈕或刷新，就會出現(xiàn)類似"登錄超時,請重新登錄"的提示。這是為什么呢？就是因為Session到期了。你發(fā)送的請求被服務器認為是新請求，所以需要重新登錄獲取操作權限。

在Tomcat中，Session默認到期時間是30分鐘。

設置session到期時間的方式有許多種：

1.如果使用的是springboot，可以到application.propertis文件中設置：

server.servlet.session.timeout = 1800 （單位為秒）

2.也可以到web.xml中設置：

<session-config>

<session-timeout>30</session-timeout> （單位為分鐘）

</session-config>

3.在編碼中通過方法調用的方式：

session.setMaxInactiveInterval(60*30); （單位為秒）

以上情況都是到期后自動銷毀。

手動銷毀session

調用方法：

session.invalidate();

Cookie 和 Session的對比

兩者都是為了解決HTTP協(xié)議的無狀態(tài)的特性，也就是處理一次會話多次請求之間的數(shù)據(jù)共享的。

兩者區(qū)別：

1.存儲位置：Cookie存儲在客戶端，Session存儲在服務器端。

2.安全性：Cookie不安全，Session安全。

說明:到瀏覽器可以查看瀏覽器存儲的所有Cookie，數(shù)據(jù)并不安全。

3.存儲容量：Cookie最大3KB，Session對存儲大小沒有限制。

說明：由于Session數(shù)據(jù)存儲在服務器，數(shù)據(jù)存在太大對于服務器也會是個負擔。

4.到期時間：Cookie可以長期存儲，Session默認為30分鐘。

對于兩者的使用，主要需要考慮安全性和到期時間后選擇。

到此這篇關于Java Cookie與Session實現(xiàn)會話跟蹤詳解的文章就介紹到這了,更多相關Java Cookie與Session內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論