会话跟踪技术：Cookie、Session和Token

逃离我推掉我的手 2024-03-30 17:49 18阅读 0赞

#### 会话跟踪技术 ####

*  背景：
 *  1. Cookie （客户端的会话跟踪技术）
 *   *  1.1 原理
     *  1.2 基本使用
     *   *  1.2.1 服务器发送Cookie
         *  1.2.2 服务器获取Cookie
     *  1.3 使用细节
     *   *  1.3.1 存活时间
         *  1.3.2 存储中文
 *  2. Session（服务端的会话跟踪技术）
 *   *  2.1 原理
     *  2.2 基本使用
     *   *  2.2.1 获取Session对象
         *  2.2.1 Session对象的功能
     *  2.3 使用细节
     *   *  2.3.1 Session钝化、活化
         *  2.3.2 Session销毁
     *  2.4 Session的共享问题
 *  Cookie与Session的区别：
 *  3. Token

## 背景： ##

**HTTP**是**无状态**的协议，即服务器对客户端没有记忆能力，它的每个请求都是完全独立的，并不会保存通信状态。

**无状态的后果：** 意味着后续发出的请求需要先处理前面请求的响应，则必须重传前面的请求，这导致需要额外传递一些前面的重复请求，才能获取后续响应，会大大浪费资源；

\-------------所以需要 **会话跟踪技术** 来解决无状态的问题 ！**实现一次会话的多次请求内数据共享！**

## 1. Cookie （客户端的会话跟踪技术） ##

Cookie的实现是基于**HTTP**协议的；  
Cookie是客户端**保存用户信息**的一种机制 ，本质是存储在浏览器的**一小段文本数据**，不超过4kb；

**过程**：  
客户端【第一次发送HTTP请求时】，**服务器产生Cookie** 并返回给浏览器存储，  
【以后浏览器每次发送HTTP请求时】，HTTP的请求报文的 **`请求头`** 中都会带着**Cookie**（请求头的格式为键值对），这样就能通过coockie实现同一次会话中 多次请求之间的数据共享；

**缺点：** 安全性

1.  Cookie是放在【HTTP请求报文】的**头部行**中，是以明文形式在网络中传输，若没有加密，一旦被截获，可以直接**获取隐私信息**；
2.  由于HTTP协议不会验证双方的身份，即使是Cookie被MD5加密，一旦Cookie被截获，把别人的Cookie向服务器提交，并且能够通过验证，就可以**冒充**受害人的身份登陆网站--------**Cookie欺骗**。

### 1.1 原理 ###

*  浏览器访问服务器后，在servletA创建了Cookie对象并封装在***respond对象***中，
 *  Tomcat解析respond对象，会将Coockie键值对放到HTTP响应报文的 **响应头** `set-cookie`：username=zs
 *  浏览器拿到并解析响应报文，拿到数据username=zs并存储；
 *  当下一次浏览器要访问servletB，会在HTTP请求报文的 **请求头** 中带上：`cookie`：username=zs
 *  Tomcat解析浏览器发送的HTTP请求报文，将数据存入 ***request对象***，通过request对象来获取Cookie数组；  
    ![在这里插入图片描述][6003856522114f8ca4bdf9845392072e.png]

### 1.2 基本使用 ###

作为服务端，需要关注的：  
①发送Cookie，  
②接收到Cookie后获取其中的信息

#### 1.2.1 服务器发送Cookie ####

1.  在Servlet中，创建Cookie对象，设置键值对数据；  
    ![在这里插入图片描述][4b97511278184386bb03b1fce64b7af7.png]
2.  将Cookie对象添加到**Response对象**，而后由Tomcat读取respond中数据并拼接成HTTP响应报文格式发给客户端；  
    ![在这里插入图片描述][262e5ba0df6c48479599c81ba8a8062e.png]

**例：服务器发送Cookie**  
![在这里插入图片描述][e5e072b8908b4a1f894b8ec12b842786.png]  
启动Tomcat，访问aServlet就会执行cookie相关代码；

查看响应报文（响应头）：  
![在这里插入图片描述][0ff46b96ebd34950a1394b9df48c3736.png]

此时打开浏览器设置，能找到刚才发送的Cookie：  
![在这里插入图片描述][e5a47cf8a68145ad91627a5c37ad5cf6.png]

#### 1.2.2 服务器获取Cookie ####

注：浏览器访问服务器时会在HTTP请求报文的【请求头】中**携带着所有Cookie**，每对用分号隔开；  
![在这里插入图片描述][2ec29f28b895440794a6f47cb4870a7e.png]

1.  使用**request对象**来获取Cookie数组  
    ![在这里插入图片描述][f1f164fc847e4d9e9828dad5715a4143.png]
2.  遍历Cookie数组，获取每一个Cookie
3.  使用Cookie对象方法获取数据；  
    ![在这里插入图片描述][a2b215eeece94da593cbf51c50e907e5.png]

**例：获取Cookie数组，只取出name=”username“的那个Cookie，打印出name和value：**  
![在这里插入图片描述][35cc28502c0c464c9edf6e80962e755f.png]  
此时访问bServlet，浏览器携带了Cookie，由servlet获取，在控制台打印：  
![在这里插入图片描述][f583912b9043401abb08fb86919650f8.png]

### 1.3 使用细节 ###

#### 1.3.1 存活时间 ####

**【默认情况下】**，Cookie存储在浏览器内存中，当浏览器关闭，内存释放，Cookie会被销毁；

**Cookie持久化**： `setMaxAge(int seconds)` 设置Cookie存活时间；

1.  正数：将Cookie写入浏览器所在**磁盘**，持久化存储！到时间自动删除
2.  负数，默认值，Cookie存在浏览器**内存**中，浏览器关闭，则Cookie被销毁
3.  零：删除对应Cookie

#### 1.3.2 存储中文 ####

默认情况下不能存储中文！  
**解决**：

1.  将value用URL**编码**；  
    ![在这里插入图片描述][1b4f7b1331164f1e8272a6cb6c9e794e.png]
2.  中文被编码为：  
    ![在这里插入图片描述][5b7f1dc770c04e87bfbb757415f7b96b.png]
3.  再对value进行**解码**：  
    ![在这里插入图片描述][c545215c85cf49dfbe8baa2607b9a6dd.png]  
    成功解码：  
    ![在这里插入图片描述][776c57e9231a403093041b953635f848.png]

## 2. Session（服务端的会话跟踪技术） ##

**引入**：  
1.Cookie是纯文本，且只有几kb 存的内容太少；  
2.Cookie中直接放数据，不安全，容易被截取；

**Session机制一般借助Cookie来实现**；  
**session对象**存储在服务器中，**用于记录用户的状态**，  
**sessionID**是**无规律的字符串**，存储在浏览器端的【Cookie中】；  
当浏览器【发送HTTP请求时】会带着sessionID，**服务器根据SessionID就能找出用户信息**；  
session会配置一个过期时间（默认30min），过期后需要重新登录；

当客户端第一次访问服务器时，【服务器创建session出来后】，会把sessionID以cookie的形式回写给客户机，这样，只要客户机的浏览器不关，再去访问服务器时，都会带着session的id号，服务器发现客户机浏览器带sessionID过来了，就会使用中与之对应的session为之服务。

**运行机制：**  
1.主机的浏览器进程与服务器进程建立浏览器连接  
2.当用户浏览器进程【**第一次**向服务器进程发送HTTP请求报文时】，Web服务器就会为其产生一个唯一的 `sessionID`，并以此为**索引**在Web服务器内存中创建**session对象**，用来记录该用户访问该网站的各种信息（setAttribute()），一次会话中的不同请求就可以共享这个Session对象的数据了；  
3.接着Web服务器给浏览器进程发回HTTP响应报文，在响应报文中，包含一个首部字段为`Set-Cookie`的首部行，该字段由服务器写入了sessionID，以及会话结束时间  
4.当浏览器进程收到该响应报文后，就在一个特定的Cookie文件中添加一行，记录该服务器的域名和Cookie；  
5.【当用户再次使用浏览器访问这个网站时】，每发送一个HTTP请求报文，浏览器都会从Cookie文件中取出该网站的sessionID，并放到HTTP请求报文的Cookie **头部行** 中，Web服务器根据sessionID就可以识别该用户，返回相关信息；

### 2.1 原理 ###

Session是基于Cookie实现的；  
![在这里插入图片描述][180bd84211244e5589505cfa847a22ae.png]

**为什么在一次会话的多次请求之间获取的都是同一个Session对象 ？**  
浏览器访问服务端，servlet会自动生成**Session对象**的**ID**并放入**Cookie**，发给浏览器（HTTP响应报文的响应头）；  
![在这里插入图片描述][208b3de0b1ae4e6b9155ef6771a7db18.png]

浏览器收到后将SessionID存入内存/磁盘；  
下次浏览器携带着Cookie：SessionID=10 访问Servlet，Servlet收到SessionID后寻找这个SessionID的对象，如果有就直接使用，没有则创建新的Session对象；  
![在这里插入图片描述][87d6c3e273664e7480c8d8cc11dfa375.png]

而当另一个浏览器的请求3访问Servlet时没有携带sessionID、或者SessionID不一样，servlet就无法获取刚才sessionID=10的SessionID对象，这就保证了同一个会话的session是同一个；

### 2.2 基本使用 ###

#### 2.2.1 获取Session对象 ####

![在这里插入图片描述][e0c8ccbcc06948e698c3a783c1e86d68.png]

#### 2.2.1 Session对象的功能 ####

![在这里插入图片描述][8b1fc6290513411d952f3a1dcd2e033b.png]  
**注：`setAttribute`的值可以存任意类型！**

**例：**  
**ServletDemo1请求1**：通过**request对象**获取Session对象并存数据（ `setAttribute()` ）  
![在这里插入图片描述][1a5c63e40b0247878189cceadf03a8cf.png]  
**ServletDemo2请求2**：直接获取Session并读取数据，就是请求1存的数据，即访问同一个Session对象！( `getAttribute()` )  
![在这里插入图片描述][f72580d43c344e9198dd6411829cf70e.png]  
![在这里插入图片描述][3e6336c147a84c309382fd6cb200ab59.png]

输出zs；  
即session对象被两次请求所访问，即在一次会话的两次请求之间共享数据！

### 2.3 使用细节 ###

#### 2.3.1 Session钝化、活化 ####

**钝化**（序列号）：【服务器正常关闭后】，Tomcat会自动将Session对象的数据写入磁盘；  
**活化**（反序列化）：再次启动服务器后，从文件加载数据并转化为Session对象；  
Session是对象，钝化即序列号，活化即反序列化；

#### 2.3.2 Session销毁 ####

1.  默认情况下，误操作，Session会在`30`分钟内销毁（提示：登陆时间太长没有操作，已经自动退出请重新登陆）  
    也可以在xml文件中设置时间：  
    ![在这里插入图片描述][d068750e5b1d45c980e3d01e601c6dba.png]
2.  调用Session对象的`invalidate()`方法，如前端用户选择“**登出**”时，就需要销毁Session ！

**注意：**  
浏览器中途关闭，再次访问时，不是同一个Session对象，因为已经不是同一次会话了！

### 2.4 Session的共享问题 ###

当使用Session来存储用户数据时，多台Tomcat并不共享session存储进空间 ！当切换到不同的Tomcat服务器时导致数据丢失的问题！（每个Tomcat都有自己的session空间）；

**解决**：让session可以在服务器之间共享；

**早期**：  
Tomcat使用session互相拷贝； 但是①多台服务器拷贝浪费空间 ②拷贝需要时间，有延迟（服务器是进程，进程通信效率低）

**现在：**  
使用 **`Redis`** 充当缓存服务器！让每个服务器都能访问Redis中的用户信息；  
![在这里插入图片描述][da502a2bc83849d2806ee9aeeeaca86c.png]

## Cookie与Session的区别： ##

Cookie和Session都是完成一次会话多次请求间的数据共享；

1.  **储存**：cookie储存在浏览器内存/磁盘（可以自己设置），  
    session对象储存在服务器中（钝化、活化），而sessionID存于Cookie中，
2.  **安全性**：session比cookie更加安全  
    ①Cookie直接存数据，每次都在网络中传输，容易被盗取、截获；  
    ②seesionID是随机字符串而不是明文且不记录数据，数据是在Session对象中在服务器，**避免了直接存用户名密码，提高安全性**；  
    ③**有会话时间限制**，且可以选择使用签名，而cookie容易造成cookie欺骗
3.  **数据类型不同**：cookie只支持字符串数据，session对象可以储存任意类型数据（`Object`）！
4.  **有效期**不同：cookie存活时间可设置较长时间，**而session存活时间相对较短**（默认30min）；
5.  **存储大小不同**：单个cookie的数据不能超过4KB，session储存的数据内容可以更大，即在一次会话中多次请求共享的数据也就更多；

## 3. Token ##

**引入**：Token是在客户端频繁向服务端请求数据，服务端频繁的去数据库查询用户名和密码并进行对比，判断用户名和密码正确与否，并作出相应提示，在这样的背景下，Token便应运而生

token的意思是“**令牌**”，是服务端生成的一串字符串，作为客户端进行请求的一个令牌，当用户第一次登录后，服务器生成一个Token便将此Token返回给客户端，以后客户端只需带上这个Token前来请求数据即可，无需再次带上用户名和密码,减轻服务器的压力。

**运行机制：**

1.客户端使用用户名跟密码请求登录；  
2.服务端收到请求，去验证用户名与密码；  
3.验证成功后，服务端会签发一个 **Token**，再把这个 Token 发送给客户端；  
4.客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage 里；  
5.客户端每次向服务端请求资源的时候需要带着服务端签发的 Token；  
6.服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据。

服务器并不保存token，而是通过数据签名的方法，对数据用算法（如SHA-256）与私钥进行签名后作为Token，当Token发送给服务器时，服务会通过相同的算法与密钥进行签名，如果和Token中的签名相同，服务器就知道用户已经登录过了，并且可以直接得到用户的userID。（**服务器用cpu的计算时间来换取了储存空间**）

**token和session的区别？**  
token和session其实都是为了**身份验证**  
服务端session存用户数据，客户端访问服务端的时候，根据sessionid找用户数据；而使用token时服务端只有一段加密代码；  
同样，session和token都是有过期时间一说，都需要去管理过期时间；  
其实token与session的问题是一种时间与空间的博弈问题，**session是空间换时间**，而**token是时间换空间**。两者的选择要看具体情况而定。

虽然确实都是“客户端记录，每次访问携带”，**但使用token则后端不需要记录什么东西，每次解密验证即可**；  
而 sessionid ，**一般都是一段随机字符串，需要到后端去检索 id 的有效性**

[6003856522114f8ca4bdf9845392072e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/67c5641d6eb3405b98b2cb6edc7f92cc.png
[4b97511278184386bb03b1fce64b7af7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/3d39e5484e8742beb9d92b4ddf023423.png
[262e5ba0df6c48479599c81ba8a8062e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/b8c49f2ab18f4addbde9d0cc7487ffab.png
[e5e072b8908b4a1f894b8ec12b842786.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/befd47ce37cd489a80f1b2ac737290b8.png
[0ff46b96ebd34950a1394b9df48c3736.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/0a7ea6ab7d874404afc29f12cd88ad19.png
[e5a47cf8a68145ad91627a5c37ad5cf6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/4f6a75ae5ae4433b95d99b2bbc6d5487.png
[2ec29f28b895440794a6f47cb4870a7e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/bab4d7c3799a45a3aaedaea0fa334e1f.png
[f1f164fc847e4d9e9828dad5715a4143.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/0f52943a62ef4a278b8d21aec2c519a3.png
[a2b215eeece94da593cbf51c50e907e5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/f77d7c9ee13e439aa6aad0605e94da98.png
[35cc28502c0c464c9edf6e80962e755f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/329d2f2382b141c68dcb36b06eec5d55.png
[f583912b9043401abb08fb86919650f8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/58fb9b041a2e4977b71b97ceed21af27.png
[1b4f7b1331164f1e8272a6cb6c9e794e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/6b5803fe05bf45a594bb423c46b5fb9f.png
[5b7f1dc770c04e87bfbb757415f7b96b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/3518a72c7ac0489397d2fd606d8616a0.png
[c545215c85cf49dfbe8baa2607b9a6dd.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/63aa2d3f54c34bef994045523519aa94.png
[776c57e9231a403093041b953635f848.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/0ec54feb1fef4e45a613c91a6206353e.png
[180bd84211244e5589505cfa847a22ae.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/0fe035008bd246b9832d22ec860b70a5.png
[208b3de0b1ae4e6b9155ef6771a7db18.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/7e107bbc670c4b3589e94fd2746ef00e.png
[87d6c3e273664e7480c8d8cc11dfa375.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/ff20aceff2684278ae30449cf26aae40.png
[e0c8ccbcc06948e698c3a783c1e86d68.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/fc0750b374114b878a7e493e41cf3139.png
[8b1fc6290513411d952f3a1dcd2e033b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/53f1531d1da94924875adcc34e82ee78.png
[1a5c63e40b0247878189cceadf03a8cf.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/ed7789d81ba2417e9dd69109b857d06e.png
[f72580d43c344e9198dd6411829cf70e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/ea4880124b6c4494bad5f6307f44dffc.png
[3e6336c147a84c309382fd6cb200ab59.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/878afceb55d4497f8705db75bb166883.png
[d068750e5b1d45c980e3d01e601c6dba.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/633c03eadaba450ba7ffac042665d275.png
[da502a2bc83849d2806ee9aeeeaca86c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/62da2516327b4f65b405ad134652b854.png