这篇文章将带你彻底理解会话跟踪方案的三种技术，分别是Cookie、Session、令牌技术，
揭示它们的原理以及对各个技术进行通俗化，让你更好的了解，它们的交互过程 ！ ！ ！
制作不易，感觉不错请点下赞哟！！！
目录
<1>.JWT是如何将原始的JSON格式数据，转变为字符串的呢？
Mybatis文章也一样精彩哟
https://blog.csdn.net/2301_77358195/article/details/137020099Servlet文章让你赏心悦目
1.Cookie技术
<1>.Cookie执行过程
①.cookie 是客户端会话跟踪技术，它是存储在客户端浏览器的，我们使用 cookie 来跟踪会话，我们
就可以在浏览器第一次发起请求来请求服务器的时候，我们在服务器端来设置一个cookie。
比如第一次请求了登录接口，登录接口执行完成之后，我们就可以设置一个cookie，在 cookie 当中
我们就可以来存储用户相关的一些数据信息。比如我可以在 cookie 当中来存储当前登录用户的用户名，用户的ID。
②.服务器端在给客户端在响应数据的时候，会自动的将 cookie 响应给浏览器，浏览器接收到响应回来
的 cookie 之后，会自动的将 cookie 的值存储在浏览器本地。接下来在后续的每一次请求当中，
都会将浏览器本地所存储的 cookie 自动地携带到服务端。
③.接下来在服务端我们就可以获取到 cookie 的值。我们可以去判断一下这个 cookie 的值是否存
在，如果不存在这个cookie，就说明客户端之前是没有访问登录接口的；如果存在 cookie 的值，就
说明客户端之前已经登录完成了。这样我们就可以基于 cookie 在同一次会话的不同请求之间来共享数据。
<2>.说人话
cookie就是当我们在这一次发送请求/login路径等，服务器会生成一个 cookie，存储和识别当前登录用户的用户
名，用户的ID。然后在这一次响应会携带该cookie的用户信息给浏览器，并保存到浏览器，后面每次请求浏览器都会
携带该cookie给服务端，服务端来识别，保存共享访问的数据，解决http协议的无状态问题.
<3>.在介绍流程的时候，用了 3 个自动
①.服务器会 自动 的将 cookie 响应给浏览器。
②.浏览器接收到响应回来的数据之后，会 自动 的将 cookie 存储在浏览器本地。
③.在后续的请求当中，浏览器会 自动 的将 cookie 携带到服务器端。
<4>.为什么这一切都是自动化进行的？
是因为 cookie 它是 HTTP 协议当中所支持的技术，而各大浏览器厂商都支持了这一标准。在 HTTP协议官方给我们提供了一个响应头和请求头：
响应头 Set-Cookie ：设置Cookie数据的
请求头 Cookie：携带Cookie数据的
<4>.优缺点
优点：HTTP协议中支持的技术（像Set-Cookie 响应头的解析以及 Cookie 请求头数据的携带，都是浏览器自动进行的，是无需我们手动操作的）
缺点：移动端APP(Android、IOS)中无法使用Cookie不安全，用户可以自己禁用Cookie，Cookie不能跨域
2.Session技术
<1>.Session执行过程
①.Session是服务器端会话跟踪技术，它是存储在服务器端的。而Session 的底层其实就是基于我们刚才所介绍的 Cookie 来实现的。
②.要基于 Session 来进行会话跟踪，浏览器在多次请求服务器的时候，我们就可以直接在服务器当中来获取到会话对象Session。
如果是第一次请求Session ，会话对象是不存在的，这个时候服务器会自动的创建一个会话对象Session 。而每一个会话对象Session ，
它都有一个ID，我们称之为 Session 的ID。
③.接下来，服务器端在给浏览器响应数据的时候，它会将 Session 的 ID 通过 Cookie 响应给浏览器。其实在响应头当中增加了一个 Set-Cookie 响应头。
这个 Set-Cookie 响应头对应的值是不是cookie？ cookie 的名字是固定的 JSESSIONID 代表的服务器端会话对象Session 的 ID。
浏览器会自动识别这个响应头，然后自动将Cookie存储在浏览器本地。
④.接下来，在后续的每一次请求当中，都会将 Cookie 的数据获取出来，并且携带到服务端。接下来服务器拿到JSESSIONID这个 Cookie 的值，
也就是 Session 的ID。拿到 ID 之后，就会从众多的 Session 当中来找到当前请求对应的会话对象Session。
Session前后端情况
Session 是一个概念，通常与HTTP协议中的无状态性相关联。由于HTTP本身是无状态的，它不会在多次请求之间记住数据或状态，这可能导致一些问题，特别是涉及到身份验证、购物车管理、用户会话管理等方面。
为了解决这个问题，服务器通常会维护一个会话（Session），以便保存客户端的状态信息。
前端的Session概念：
前端的Session通常指的是存储在浏览器中的sessionStorage或localStorage中。这些存储API允许JavaScript在客户端（浏览器）中保存数据。当用户刷新页面或导航到应用的其他页面时，这些数据会保持不变，直到用户清除它们或它们的过期时间到了为止。
后端的Session概念：
后端的Session是指服务器端的会话管理。这通常涉及到以下步骤：
-
创建Session：当用户与服务器交互时（例如，登录），服务器会创建一个Session。这个Session包含有关用户会话的信息，例如用户ID、权限设置和其他必要的数据。
-
会话标示符：服务器创建Session后，它将分配一个唯一的ID给这个Session，这个ID被称为会话ID（Session ID）。
-
发送会话ID到客户端：服务器将这个会话ID以某种形式发送到客户端，通常通过HTTP cookie。客户端会存储这个cookie，浏览器会自动地将这个cookie包含在后续的所有请求中发送回服务器。
-
验证Session：每当客户端发送一个请求时，服务器会检查是否有有效的Session ID（通常是检查cookie）。如果存在，服务器会使用这个ID来查找到对应的Session，获取状态信息，并处理请求。
-
结束Session：当用户退出或不活跃一段时间后，服务器可能会根据配置来结束Session，这通常涉及清除保存在服务器上的状态信息和清除客户端的Session ID。
<2>.说人话
当第一次发送请求时，服务端会创建一个会话Session对象，并且保存到服务端，在响应数据的时候会将识别该Session对象的ID封装到Cookie并且相应响应
给浏览器，在下次发送请求时，会将封装SessionId的cookie携带到服务端，服务端通过SessionId找到对应的Session会话对象，就可以通过 Session 会话
对象在同一次会话的多次请求之间来共享数据了
<3>.优缺点
优点：Session是存储在服务端的，安全
缺点：服务器集群环境下无法直接使用Session，移动端APP(Android、IOS)中无法使用Cookie，用户可以自己禁用Cookie，Cookie不能跨域
<4>.服务器集群环境为何无法使用Session？
①.我们现在所开发的项目，一般都不会只部署在一台服务器上，因为一台服务器会存在一个很大的问题，就是单点故障。
所谓单点故障，指的就是一旦这台服务器挂了，整个应用都没法访问了。所以在现在的企业项目开发当中，最终部署的时候都是以集群的形式来进行部署，
也就是同一个项目它会部署多份。
②.用户在访问的时候，到底访问这三台其中的哪一台？其实用户在访问的时候，他会访问一台前置的服务器，我们叫负载均衡服务器，
然后如果发送第一次请求是给第一台服务器，该服务器就会创建一个会话Session对象，并响应给浏览器，然后下一次发送请求是给第二台服务器的话，
会将Session携带过去，但是第二台服务器根本就没有这个会话Session对象，所以就会出现问题...
3.令牌技术
<1>.令牌的执行过程
①.令牌就是一个用户身份的标识，看似很高大上，很神秘，其实本质就是一个字符串.
通过令牌技术来跟踪会话，我们就可以在浏览器发起请求。在请求登录接口的时候，如果登录成功，我就可以生成一个令牌，
令牌就是用户的合法身份凭证。接下来我在响应数据的时候，我就可以直接将令牌响应给前端。
②.在前端程序当中接收到令牌之后，就需要将这个令牌存储起来。这个存储可以存储在cookie 当中，也可以存储在其他的存储空间(比如：localStorage)当中。
③.接下来，在后续的每一次请求当中，都需要将令牌携带到服务端。携带到服务端之后，接下来我们就需要来校验令牌的有效性。如果令牌是有效的，
就说明用户已经执行了登录操作，如果令牌是无效的，就说明用户之前并未执行登录操作。
此时，如果是在同一次会话的多次请求之间，我们想共享数据，我们就可以将共享的数据存储在令牌当中就可以了。
<2>.优缺点
优点：支持PC端、移动端，解决集群环境下的认证问题，减轻服务器的存储压力（无需在服务器端存储）
缺点：需要自己实现（包括令牌的生成、令牌的传递、令牌的校验）
4.JWT令牌
①.JWT全称：JSON Web Token （官网：https://jwt.io/）
定义了一种简洁的、自包含的格式，用于在通信双方以json数据格式安全的传输信息。由于数字签名的存在，这些信息是可靠的。
②.JWT的组成： （JWT令牌由三个部分组成，三个部分之间使用英文的点来分割）
第一部分：Header(头）， 记录令牌类型、签名算法等。 例如：{"alg":"HS256","type":"JWT"}
第二部分：Payload(有效载荷），携带一些自定义信息、默认信息等。 例如：{"id":"1","username":"Tom"}
第三部分：Signature(签名），防止Token被篡改、确保安全性。将header、payload，并加入指定秘钥，通过指定签名算法计算而来。
签名的目的就是为了防jwt令牌被篡改，而正是因为jwt令牌最后一个部分数字签名的存在，所以整个jwt 令牌是非常安全可靠的
。一旦jwt令牌当中任何一个部分、任何一个字符被篡改了，整个令牌在校验的时候都会失败，所以它是非常安全可靠的。
<1>.JWT是如何将原始的JSON格式数据，转变为字符串的呢？
其实在生成JWT令牌时，会对JSON格式的数据进行一次编码：进行base64编码
Base64：是一种基于64个可打印的字符来表示二进制数据的编码方式。既然能编码，那也就意味着也能解码。
所使用的64个字符分别是A到Z、a到z、 0- 9，一个加号，一个斜杠，加起来就是64个字符。任何数据经过base64编码之后，
最终就会通过这64个字符来表示。当然还有一个符号，那就是等号。等号它是一个补位的符号
需要注意的是Base64是编码方式，而不是加密方式。
<2>.JWT令牌最典型的应用场景就是登录认证
①. 在浏览器发起请求来执行登录操作，此时会访问登录的接口，如果登录成功之后，我们需要生成
一个jwt令牌，将生成的 jwt令牌返回给前端。
②. 前端拿到jwt令牌之后，会将jwt令牌存储起来。在后续的每一次请求中都会将jwt令牌携带到服务端。
③. 服务端统一拦截请求之后，先来判断一下这次请求有没有把令牌带过来，如果没有带过来，直接
拒绝访问，如果带过来了，还要校验一下令牌是否是有效。如果有效，就直接放行进行请求的处理
155
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
