会话跟踪技术：Cookie、Session和Token
会话跟踪技术
- 背景：
- 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销毁
- Cookie与Session的区别：
- 3. Token
背景：
HTTP是无状态的协议，即服务器对客户端没有记忆能力，它的每个请求都是完全独立的，发送请求不涉及到状态变更。
无状态的后果： 意味着后续发出的请求需要先处理前面请求的响应，则必须重传前面的请求，这导致需要额外传递一些前面的重复请求，才能获取后续响应，会大大浪费资源；
-------------所以需要 会话跟踪技术 来解决无状态的问题 ！实现一次会话的多次请求内数据共享！
1. Cookie （客户端的会话跟踪技术）
Cookie的实现是基于HTTP协议的；
Cookie是客户端保存用户信息的一种机制 ，本质是存储在浏览器的一小段文本数据，不超过4kb；
过程：
【第一次发送HTTP请求时】，服务器产生Cookie并返回给浏览器存储，
【以后浏览器每次发送HTTP请求时】，HTTP的请求报文的请求头中都会带着Cookie（请求头的格式为字段名和value值）
缺点： 安全性
- Cookie是放在【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数组；
1.2 基本使用
作为服务端，需要关注的：
①发送Cookie，
②接收到Cookie后获取其中的信息
1.2.1 服务器发送Cookie
-
在Servlet中，创建Cookie对象，设置数据；
-
将Cookie对象添加到Response对象，而后由Tomcat读取respond中数据并拼接成HTTP响应报文格式发给客户端；
例：发送Cookie
启动Tomcat，访问aServlet就会执行cookie相关代码；
查看响应报文（响应头）：
此时打开浏览器设置，能找到刚才发送的Cookie：
1.2.2 服务器获取Cookie
注：浏览器访问服务器时会在HTTP请求报文的请求头中带着所有Cookie，每对用分号隔开；
- 使用request对象来获取Cookie数组
- 遍历Cookie数组，获取每一个Cookie
- 使用Cookie对象方法获取数据；
例：获取Cookie数组，只取出name=”username“的那个Cookie，打印出name和value：
此时访问bServlet，浏览器携带了Cookie，由servlet获取，在控制台打印：
1.3 使用细节
1.3.1 存活时间
【默认情况下】，Cookie存储在浏览器内存中，当浏览器关闭，内存释放，Cookie会被销毁；
Cookie持久化： setMaxAge(int seconds) 设置Cookie存活时间；
- 正数：将Cookie写入浏览器所在磁盘，持久化存储！到时间自动删除
- 负数，默认值，Cookie存在浏览器内存中，浏览器关闭，则Cookie被销毁
- 零：删除对应Cookie
1.3.2 存储中文
默认情况下不能存储中文！
解决：
- 将value用URL编码；
- 中文被编码为：
- 再对value进行解码：
成功解码：
2. Session（服务端的会话跟踪技术）
Session机制一般借助Cookie来实现；
session对象存储在服务器中，用于记录用户的状态，
sessionID是无规律的字符串，存储在浏览器端的【Cookie中】；
当浏览器【发送HTTP请求时】会带着sessionID，服务器根据SessionID就能找出用户信息；
session会配置一个过期时间（默认30min），过期后需要重新登录；
当客户端第一次访问服务器时，【服务器创建session出来后】，会把sessionID以cookie的形式回写给客户机，这样，只要客户机的浏览器不关，再去访问服务器时，都会带着session的id号，服务器发现客户机浏览器带sessionID过来了，就会使用中与之对应的session为之服务。
运行机制：
1.主机的浏览器进程与服务器进程建立浏览器连接
2.当用户浏览器进程【第一次向服务器进程发送HTTP请求报文时】，服务器进程就会为其产生一个唯一的sessionID，并以此为索引在服务器的后端数据库创建session对象，用来记录该用户访问该网站的各种信息
3.接着服务器给浏览器进程发回HTTP响应报文，在响应报文中，包含一个首部字段为Set-Cookie的首部行，该字段由服务器写入了sessionID，以及会话结束时间
4.当浏览器进程收到该响应报文后，就在一个特定的Cookie文件中添加一行，记录该服务器的域名和Cookie；
5.【当用户再次使用浏览器访问这个网站时】，每发送一个HTTP请求报文，浏览器都会从Cookie文件中取出该网站的sessionID，并放到HTTP请求报文的Cookie 头部行 中，服务器根据sessionID就可以识别该用户，返回相关信息；
2.1 原理
Session是基于Cookie实现的；
为什么在一次会话的多次请求之间获取的都是同一个Session对象 ？
浏览器访问服务端，servlet会自动生成Session对象的ID并放入Cookie，发给浏览器（HTTP响应报文的响应头）；
浏览器收到后将SessionID存入内存/磁盘；
下次浏览器携带着Cookie：SessionID=10 访问Servlet，Servlet收到SessionID后寻找这个SessionID的对象，如果有就直接使用，没有则创建新的Session对象；
而当另一个浏览器的请求3访问Servlet时没有携带sessionID或者不一样，servlet就无法获取刚才sessionID=10的SessionID对象，这就保证了同一个会话的session是同一个；
2.2 基本使用
2.2.1 获取Session对象
2.2.1 Session对象的功能
注：setAttribute的值可以存任意类型！
例：
ServletDemo1：通过request对象获取Session对象并存数据
ServletDemo2：读取Session并获取数据
输出zs；
即session对象被两次请求所访问，即在一次会话的两次请求之间共享数据！
2.3 使用细节
2.3.1 Session钝化、活化
钝化（序列号）：【服务器正常关闭后】，Tomcat会自动将Session数据写入硬盘的文件中；
活化（反序列化）：再次启动服务器后，从文件加载数据；
Session是对象，钝化即序列号，活化即反序列化；
2.3.2 Session销毁
-
默认情况下，误操作，Session会在
30分钟内销毁（提示：登陆时间太长没有操作，已经自动退出请重新登陆）
也可以在xml文件中设置时间：
-
调用Session对象的
invalidate()方法，如前端用户选择“登出”时，就需要销毁Session ！
注意：
浏览器中途关闭，再次访问时，不是同一个Session对象，因为已经不是同一次会话了！
Cookie与Session的区别：
Cookie和Session都是完成一次会话多次请求间的数据共享；
- 储存：cookie储存在浏览器内存/磁盘，
session对象储存在服务器中，而sessionID存于Cookie中， - 安全性：session比cookie更加安全
①Cookie存在客户端，每次都在网络中传输，容易被盗取、截获；
②seesionID是随机字符串而不是明文，避免了直接存用户名密码，提高安全性；
③有会话时间限制，且可以选择使用签名，而cookie容易造成cookie欺骗 - 数据类型不同：cookie只支持字符串数据，session对象可以储存任意类型数据（Object）！
- 有效期不同：cookie存活时间可设置较长时间，而session存活时间相对较短（默认30min）；
- 存储大小不同：单个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 的有效性