Session、Cookie、Token讲解-育师

我们都知道HTTP 协议是无状态的，所谓的无状态就是客户端每次想要与服务端通信，都必须重新与服务端链接，意味着请求一次客户端和服务端就连接一次，下一次请求与上一次请求是没有关系的。
这种无状态的方式就会存在一个问题：如何判断两次请求的是同一个人？就好比用户在页面 A 发起请求获取个人信息，然后在另一个页面同样发起请求获取个人信息，我们如何确定这俩个请求是同一个人发的呢？
为了解决这种问题，我们就迫切需要一种方式知道发起请求的客户端是谁？此时，cookie、token、session 就出现了，它们就可以解决客户端标识的问题，在扩大一点就是解决权限问题。
它们就好比让每个客户端或者说登录用户有了自己的身份证，我们可以通过这个身份证确定发请求的是谁！

一、Cookie讲解

1、概念

Cookie是一种在客户端存储数据的技术（这里指的是Web端），它是由服务器发送给客户端的小型文本文件，存储在客户端的浏览器中,大小限制大致在 4KB 左右。在客户端发送请求时，浏览器会自动将相应的 Cookie 信息发送给服务器，服务器通过读取 Cookie 信息，就可以判断该请求来自哪个客户端。Cookie 可以用于存储用户的登录状态、购物车信息等。

在以前很多开发人员通常用 cookie 来存储各种数据，后来随着更多浏览器存储方案的出现，cookie 存储数据这种方式逐渐被取代，主要原因有如下:
1、cookie有存储大小限制，4KB 左右。
2、浏览器每次请求会携带 cookie 在请求头中。
3、字符编码为 Unicode，不支持直接存储中文。
4、数据可以被轻易查看。

2、Cookie 的主要属性

名称（Name）和值（Value）
核心内容，以键值对形式存储信息。
名称和值在创建时设置，并且会被编码（通常为 URL 编码）。
有效期（Expires和Max-Age）
Expires：指定一个绝对的过期日期/时间（GMT 格式）。超过此时间，Cookie失效。
例如：Expires=Wed, 21 Oct 2026 07:28:00 GMT
如果不设置或设置为过去的日期，Cookie将成为会话 Cookie，浏览器关闭后即删除。
Max-Age：指定一个以秒为单位的相对过期时间。优先级高于Expires。
例如：Max-Age=3600 （1小时后过期）
值为 0 或负数会立即删除该 Cookie。
作用域（Domain和Path）
Domain：指定哪些主机可以接收此Cookie。
例如：设置为.example.com，则www.example.com、api.example.com等子域名都能访问。
如果不设置，默认为当前文档的主机（不包含子域名），且现代浏览器会将其限制为当前主机。
不能设置为当前域名所属域之外的域（这是安全限制）。
Path：指定 URL 路径前缀，只有路径匹配时才会发送 Cookie。
例如：Path=/docs，则/docs、/docs/Web/下的请求都会携带此Cookie，而/admin则不会。
默认为当前请求路径的父目录，但通常设为 / 表示整个站点。
安全性（Secure,HttpOnly,SameSite）
Secure：标记为Secure的Cookie只能通过HTTPS协议加密传输，防止明文传输被窃听。
HttpOnly：标记为HttpOnly的Cookie无法通过JavaScript的document.cookie API访问。
关键安全属性，能有效防止跨站脚本攻击（XSS）窃取 Cookie。
SameSite：控制 Cookie 在跨站请求时是否发送，是防御跨站请求伪造（CSRF）攻击的重要机制。
Strict：最严格。完全禁止在跨站请求中发送Cookie。例如，从其他网站链接过来，不会发送此 Cookie。
Lax：（现代浏览器默认值）。允许在安全的顶级导航（如点击链接）或 GET 请求中发送 Cookie，但禁止在跨站的 POST 请求或嵌入资源（如图片、iframe）中发送。平衡了安全与用户体验。
None：允许跨站发送Cookie。必须同时设置Secure属性（即仅 HTTPS 下可用）。常用于需要跨站身份验证的场景（如第三方登录）。

3、使用流程

那么我们是如何通过 cookie 来实现用户确定或者权限的确定呢？看下图：

1.客户端发送请求到服务端（比如登录请求）。
2.服务端收到请求后生成一个session会话。
3.服务端响应客户端，并在响应头中设置Set-Cookie。Set-Cookie里面包含了sessionId，它的格式如下：Set-Cookie: value[; expires=date][; domain=domain][; path=path][; secure]。其中sessionId就是用来标识客户端的，类似于去饭店里面，服务员给你一个号牌，后续上菜通过这个号牌来判断上菜到哪里。
4.客户端收到该请求后，如果服务器给了Set-Cookie，那么下次浏览器就会在请求头中自动携带 cookie。
5.客户端发送其它请求，自动携带了cookie，cookie中携带有用户信息等。
6.服务端接收到请求，验证cookie信息，比如通过sessionId来判断是否存在会话，存在则正常响应。
第一个请求通常是不带 Cookie 的。

4、cookie 主要特点

1.cookie 存储在客户端
2.cookie 不可跨域，但是在如果设置了 domain，那么它们是可以在一级域名和二级域名之间共享的。

二、Session讲解

1、Session概念

Session由服务端创建，当一个请求发送到服务端时，服务器会检索该请求里面有没有包含SessionId标识，如果包含了SessionId，则代表服务端已经和客户端创建过Session，然后就通过这个SessionId去查找真正的Session，如果没找到，则为客户端创建一个新的 session，并生成一个新的SessionId与Session对应，然后在响应的时候将SessionId给客户端，通常是存储在Cookie中。如果在请求中找到了真正的Session，验证通过，正常处理该请求。
每一个客户端与服务端连接，服务端都会为该客户端创建一个Session，并将Session的唯一标识SessionId通过设置Set-Cookie头的方式响应给客户端，客户端将SessionId存到Cookie中。

2、流程图

通常情况下，Cookie和Session都是结合着来用。如下图，具体流程介绍看上面Cookie流程即可。

3、Session和Cookie的区别

Cookie和Session，它们两者之间主要是通过SessionId关联起来的，所以总结出：SessionId是Cookie和Session之间的桥梁。

Session是基于Cookie实现的，它们两个主要有以下特点：
1.Session比Cookie更加安全，因为它是存在服务端的，Cookie 是存在客户端的。
2.Cookie只支持存储字符串数据，Session可以存储任意数据。
3.Cookie的有效期可以设置较长时间，Session有效期都比较短。
4.Session存储空间很大，Cookie有限制。
系统想要实现鉴权，可以单独使用Cookie，也可以单独使用Session，但是建议结合两者使用

三、token讲解

1、概念

Token是一种在客户端和服务端之间传递身份信息的方式。当用户登录成功后，服务端会生成一个Token，将其发送给客户端。客户端在后续的请求中，需要将Token携带在请求头或请求参数中。服务端通过验证Token的合法性，就可以确定该请求来自哪个用户，并且可以根据用户的权限进行相应的操作。Token可以有效地避免了Cookie的一些安全问题，比如 CSRF 攻击。

2、Token的组成

Token是一个由一串字符组成的令牌，用于在计算机系统中进行身份验证和授权。它通常由三个部分组成：标头、有效载荷、签名。
1.标头（Header）：包含了算法和类型，用于指定如何对有效载荷进行编码和签名。常用的算法有HMAC、RSA、SHA等。
2.有效载荷（Payload）：包含了一些信息，如用户ID、角色、权限等，用于验证身份和授权。有效载荷可以是加密的，也可以是明文的。
3.签名（Signature）：是对标头和有效载荷进行签名后得到的值，用于验证token的完整性和真实性。签名通常使用私钥进行签名，并使用公钥进行验证。
一个完整的token包含了标头、有效载荷和签名三个部分，它们一起构成了一个安全的令牌，用于进行身份验证和授权。

3、Token认证流程

1.客户端发起登录请求，比如用户输入用户名和密码后登录。
2.服务端校验用户名和密码后，将用户 id 和一些其它信息进行加密，生成 token。
3.服务端将 token 响应给客户端。
4.客户端收到响应后将 token 存储下来。
5.下一次发送请求后需要将 token 携带上，比如放在请求头中或者其它地方。
6.服务端 token 后校验，校验通过则正常返回数据。