了解Cookie、session、token
了解Cookie、session、token
在Web开发中，Cookie、Session和Token是三种常用的身份验证机制。它们各自有不同的工作原理、特点和使用场景。本文将详细介绍这三种机制的工作原理、特点和使用场景，并对比它们的优缺点。
一、为什么会有它们？
HTTP协议是无状态的，客户端想和服务端通信，需要连接通信，因为HTTP是无状态的，所以每次的通信都会重新连接一次，而且下次请求和上次请求是没有关系的。为了解决这个问题。为了让服务端知道客户端（访问浏览器的用户）是谁，所以给客户端整了一个身份证：session、cookies、token、sign。客户端使用这个身份证访问服务端，服务端就知道原来是你小子。
二、cookies：
Cookies是保存在客户端或者说是浏览器中的一小块数据，大小4KB左右，浏览器每次请求会携带 cookie 在请求头中。
cookie有2种存储方式，一种是会话性，一种是持久性：
会话性：如果cookie为会话性，那么cookie仅会保存在客户端的内存中，当我们关闭客服端时cookie也就失效了
持久性：如果cookie为持久性，那么cookie会保存在用户的硬盘中，直至生存期结束或者用户主动将其销毁。
cookie我们是可以进行设置的，我们可以人为设置cookie的有效时间，什么时候创建，什么时候销毁。
客户端与服务端之间的状态流转，如图所示：
从上图中可以看到使用 cookie 进行用户确认流程是比较简单的，大致分为以下几步：
客户端发送请求到服务端（比如登录请求）。
服务端收到请求后生成一个 session 会话。
服务端响应客户端，并在响应头中设置 Set-Cookie。Set-Cookie 里面包含了 sessionId，它的格式如下：Set-Cookie: value[; expires=date][; domain=domain][; path=path][; secure]。其中 sessionId 就是用来标识客户端的，类似于去饭店里面，服务员给你一个号牌，后续上菜通过这个号牌来判断上菜到哪里。
客户端收到该请求后，如果服务器给了 Set-Cookie，那么下次浏览器就会在请求头中自动携带 cookie。
客户端发送其它请求，自动携带了 cookie，cookie 中携带有用户信息等。
服务端接收到请求，验证 cookie 信息，比如通过 sessionId 来判断是否存在会话，存在则正常响应。
cookie 主要有以下特点：
cookie 存储在客户端
cookie 不可跨域，但是在如果设置了 domain，那么它们是可以在一级域名和二级域名之间共享的。
三、session：
session 主要由服务端创建，主要作用就是保存 sessionId，用户与服务端之间的权限确认主要就是通过这个 sessionId。
简单描述下 session：
session 由服务端创建，当一个请求发送到服务端时，服务器会检索该请求里面有没有包含 sessionId 标识，如果包含了 sessionId，则代表服务端已经和客户端创建过 session，然后就通过这个 sessionId 去查找真正的 session，如果没找到，则为客户端创建一个新的 session，并生成一个新的 sessionId 与 session 对应，然后在响应的时候将 sessionId 给客户端，通常是存储在 cookie 中。如果在请求中找到了真正的 session，验证通过，正常处理该请求。
总之每一个客户端与服务端连接，服务端都会为该客户端创建一个 session，并将 session 的唯一标识 sessionId 通过设置 Set-Cookie 头的方式响应给客户端，客户端将 sessionId 存到 cookie 中。
通常情况下，我们 cookie 和 session 都是结合着来用，当然你也可以单独只使用 cookie 或者单独只使用 session，这里我们就将 cookie 和 session 结合着来用。
我们可以在修改一下整个请求过程图，如下所示：
四、Cookie和session的区别：
安全存放位置：session 比 cookie 更加安全，因为它是存在服务端的，cookie 是存在客户端的。
数据类型：cookie 只支持存储字符串数据，session 可以存储任意数据。
有效时长：cookie 的有效期可以设置较长时间，session 有效期都比较短。
存储大小：session 存储空间很大，cookie 有限制4KB左右。
性能使用程度不同：session放在服务器上，访问增多会占用服务器的性能；考虑到减轻服务器性能方面，应使用cookie。
五、token：
token（令牌）是服务端生成的一串字符串，以作客户端进行请求的一个令牌，当第一次登录后，服务器生成一个Token便将此Token返回给客户端，以后客户端只需带上这个Token前来请求数据即可，无需再次带上用户名和密码。
🌱 token的使用小结：
◾ 前端登陆的时候向服务器发送请求，服务器验证成功，会生成一个token
◾ 前端会存储这个token，放在session或cookie中，用于之后的业务请求身份验证
◾ 拿着这个token，可以在当前登录的账号下进行请求业务，发送请求时，token会放在请求头里，服务器收到这个业务请求，验证token，成功就允许这个请求获取数据
◾ token可以设置失效期
利用token机制进行登录认证，可以有以下方式：
a. 用设备mac地址作为token
客户端：客户端在登录时获取设备的mac地址，将其作为参数传递到服务端
服务端：服务端接收到该参数后，便用一个变量来接收，同时将其作为token保存在数据库，并将该token设置到session中。客户端每次请求的时候都要统一拦截，将客户端传递的token和服务器端session中的token进行对比，相同则登录成功，不同则拒绝。
此方式客户端和服务端统一了唯一的标识，并且保证每一个设备拥有唯一的标识。缺点是服务器端需要保存mac地址；优点是客户端无需重新登录，只要登录一次以后一直可以使用，对于超时的问题由服务端进行处理。
b. 用sessionid作为token
客户端：客户端携带用户名和密码登录
服务端：接收到用户名和密码后进行校验，正确就将本地获取的sessionid作为token返回给客户端，客户端以后只需带上请求的数据即可。
此方式的优点是方便，不用存储数据，缺点就是当session过期时，客户端必须重新登录才能请求数据。
当然，对于一些保密性较高的应用，可以采取两种方式结合的方式，将设备mac地址与用户名密码同时作为token进行认证。
APP利用token机制进行身份认证
用户在登录APP时，APP端会发送加密的用户名和密码到服务器，服务器验证用户名和密码，如果验证成功，就会生成相应位数的字符产作为token存储到服务器中，并且将该token返回给APP端。
以后APP再次请求时，凡是需要验证的地方都要带上该token，然后服务器端验证token，成功返回所需要的结果，失败返回错误信息，让用户重新登录。其中，服务器上会给token设置一个有效期，每次APP请求的时候都验证token和有效期。
token的存储
token可以存到数据库中，但是有可能查询token的时间会过长导致token丢失（其实token丢失了再重新认证一个就好，但是别丢太频繁，别让用户没事儿就去认证）。
为了避免查询时间过长，可以将token放到内存中。这样查询速度绝对就不是问题了，也不用太担心占据内存，就算token是一个32位的字符串，应用的用户量在百万级或者千万级，也是占不了多少内存的。
token的加密
token是很容易泄露的，如果不进行加密处理，很容易被恶意拷贝并用来登录。加密的方式一般有：
在存储的时候把token进行对称加密存储，用到的时候再解密。
文章最开始提到的签名sign：将请求URL、时间戳、token三者合并，通过算法进行加密处理。
最好是两种方式结合使用。
还有一点，在网络层面上token使用明文传输的话是非常危险的，所以一定要使用HTTPS协议。
总结:
鉴权认证方式 特点 优点 缺点
cookie 1.存储在客户端。2.请求自动携带 cookie。3.存储大小 4KB。 1.兼容性好，因为是比较老的技术。2.很容易实现，因为 cookie 会自动携带和存储。 1.需要单独解决跨域携带问题，比如多台服务器如何共享 cookie。2.会遭受 CSRF 攻击。3.存储在客户端，不够安全。
session 1.存储在服务端。2.存储大小无限制。 1.查询速度快，因为是个会话，相当于是在内存中操作。2.结合 cookie 后很容易实现鉴权。3.安全，因为存储在服务端。 1.耗费服务器资源，因为每个客户端都会创建 session。2.占据存储空间，session 相当于存储了一个完整的用户信息。
token 1.体积很小。2.自由操作存储在哪里。 1.安全，因为 token 一般只有用户 id，就算被截取了也没什么用。2.无需消耗服务器内存资源，它相当于只存了用户 id，session 相当于存储了用户的所有信息。3.跨域处理较为方便，比如多台服务器之间可以共用一个 token。
1.查询速度慢，因为 token 只存了用户 id，每次需要去查询数据库。