Cookie、Session、Token区分

一开始接触这三个东西，肯定会被绕的不知道都是干什么的。

1、为什么要有它们？

首先，由于HTTP协议是无状态的，所谓的无状态，其实就是 客户端每次想要与服务端通信，都必须重新与服务端连接，这就意味着，请求一次，客户端和服务端就连接一次。并且这些请求之间是没有任何关系的。

那这种情况就会造成一个问题：“我”怎么区分这些请求是不是来自于同一个人？

举个例子就是：一个用户在页面A发起了一个请求获取个人信息，然后呢，在另一个页面同样有一个请求要获取个人信息，这要如何确定这两个请求是不是同一个人发的？

为了解决这种问题，首先要解决的就是，知道发起请求的客户端是谁！ 这就引出了 cookie、token、session，他们可以解决客户端标识的问题，顺便还能解决一下权限问题。

2、什么是Cookie？

Cookie，有时候也用复数形式Cookies，类型是小型文本文件。是保存在客户端或者说浏览器中的一小块数据，大小限制大致在4KB左右，在以前经常用来存储各种数据，但随着更多浏览器存储方案的出现，cookie存储数据的方式逐渐被取代，主要原因是：

• cookie有存储大小的限制，4KB左右

• 浏览器每次请求会携带cookie在请求头中

• 字符编码为Unicode，不支持直接存储中文

• 数据可以被轻易查看

cookie 主要有以下属性：

属性名称	属性含义
name	cookie 的名称
value	cookie 的值
comment	cookie 的描述信息
domain	可以访问该 cookie 的域名
expires	cookie 的过期时间，具体某一时间
maxAge	cookie 的过期时间，比如多少秒后 cookie 过期。
path	cookie 的使用路径
secure	cookie 是否使用安全协议传输，比如 SSL 等
version	cookie 使用的版本号
isHttpOnly	指定该 Cookie 无法通过 JavaScript 脚本拿到，比如 Document.cookie 属性、XMLHttpRequest 对象和 Request API 都拿不到该属性。这样就防止了该 Cookie 被脚本读到，只有浏览器发出 HTTP 请求时，才会带上该 Cookie

如何通过cookie来实现用户确定或权限确定呢？

通常的登陆操作及后续操作大致过程如下：

1. 客户端发送请求到服务端（比如登录请求）。

2. 服务端收到请求后生成一个 session 会话。

3. 服务端响应客户端，并在响应头中设置 Set-Cookie。Set-Cookie 里面包含了 sessionId。其中 sessionId 就是用来标识客户端的。

4. 客户端收到该请求后，如果服务器给了 Set-Cookie，那么下次浏览器就会在请求头中自动携带 cookie。

5. 客户端发送其它请求，自动携带了 cookie，cookie 中携带有用户信息等。

6. 服务端接收到请求，检测到客户端发送的cookie与其保存的cookie的值保持一致时，直接信任该连接，不再验证，比如通过 sessionId 来判断是否存在会话，存在则正常响应。

cookie 主要有以下特点：

• cookie 存储在客户端

• cookie 不可跨域，但是在如果设置了 domain，那么它们是可以在一级域名和二级域名之间共享的

3、什么是Session？

在上面所提到的Cookie实现用户权限确认时，提到了session，其实就是会话的意思，session主要是由服务端创建，主要作用就是保存sessionId。 而用户与服务端之间的权限确认主要就是通过sessionId

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 结合着来用。

所以，整个请求过程图，可以粗略分为这么几个过程：

1. 发送登陆请求

2. 创建一个session，并将session的唯一标识sessionId，设置在Set-Cookie响应头中，响应给客户端

3. 发送其他请求并自动携带Cookie，服务端通过sessionId找到session，没找到则重新创建session

4. Cookie验证通过，正常响应请求

4、Cookie和Session的区别？

在上文中，介绍到它们两者之间主要是通过 sessionId 关联起来的。

所以可以总结为：sessionId 是 cookie 和 session 之间的桥梁。或者可以换个说法，session 是基于 cookie 实现的，它们两个主要有以下特点：

• session 比 cookie 更加安全，因为session是存在服务端的，cookie 是存在客户端的。

• cookie 只支持存储字符串数据，session 可以存储任意数据。

• cookie 的有效期可以设置较长时间，session 有效期都比较短。

• session 存储空间很大，cookie 有限制。

系统想要实现鉴权，可以单独使用 cookie，也可以单独使用 session，但是建议结合两者使用。

5、什么是Token？

既然cookie+session可以实现鉴权认证，那为什么还要有token呢？

主要是因为他们的这种认证方式存在一些缺点：

• 增加请求体积，浪费性能，因为每次请求都会携带 cookie。

• 增加服务端资源消耗，因为每个客户端连接进来都需要生成 session，会占用服务端资源的。

• 容易遭受 CSRF 攻击，即跨站域请求伪造。

为了避免上述缺点，token方式的鉴权诞生

Token 通常叫令牌, 最简单的Token组成 ：uid(用户唯一身份标识), time(时间戳), sign(签名),还可以把不变的参数也放进token,避免多次查库。 我们将 token 进行解密就可以拿到诸如 uid 这类的信息，然后通过 uid 来进行接下来的鉴权操作。

token 是如何生成的：

cookie 是服务端设置了 set-cookie 响应头之后，浏览器会自动保存 cookie，然后下一次发送请求的时候会自动把 cookie 携带上。而token 主要是由服务器生成，然后返回给客户端，客户端手动把 token 存下来，比如利用 localstorage 或者直接存到 cookie 当中也行。

Token 的使用流程:

A：当用户首次登录成功（注册也是一种可以适用的场景）之后, 服务器端就会生成一个 token 值，这个值，会在服务器保存token值(保存在数据库中)，再将这个token值返回给客户端；

B：客户端拿到 token 值之后,进行本地保存；

C：当客户端再次发送网络请求(一般不是登录请求)的时候,就会将这个 token 值附带到参数中发送给服务器；

D：服务器接收到客户端的请求之后,会取出token值与保存在本地(数据库)中的token值做对比。

Token的身份认证逻辑：

对比一：如果两个 token 值相同， 说明用户登录成功过!当前用户处于登录状态！

对比二：如果没有这个 token 值, 则说明没有登录成功；

对比三：如果 token 值不同: 说明原来的登录信息已经失效,让用户重新登录。

总结

鉴权认证方式	特点	优点	缺点
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，每次需要去查询数据库。