一开始接触这三个东西，肯定会被绕的不知道都是干什么的。
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来实现用户确定或权限确定呢？
通常的登陆操作及后续操作大致过程如下：
客户端发送请求到服务端（比如登录请求）。
服务端收到请求后生成一个 session 会话。
服务端响应客户端，并在响应头中设置 Set-Cookie。Set-Cookie 里面包含了 sessionId。其中 sessionId 就是用来标识客户端的。
客户端收到该请求后，如果服务器给了 Set-Cookie，那么下次浏览器就会在请求头中自动携带 cookie。
客户端发送其它请求，自动携带了 cookie，cookie 中携带有用户信息等。
服务端接收到请求，检测到客户端发送的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 结合着来用。
所以，整个请求过程图，可以粗略分为这么几个过程：
发送登陆请求
创建一个session，并将session的唯一标识sessionId，设置在Set-Cookie响应头中，响应给客户端
发送其他请求并自动携带Cookie，服务端通过sessionId找到session，没找到则重新创建session
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，每次需要去查询数据库。 |
505
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
