session、cookie和token的区别

背景介绍:由于http是无状态的会话，所以我们需要一个东西来记录。目前我们用到的主要有三种：session，cookie 和 token。

一,分别介绍

1.1.Cookie：

Cookie实际上是一小段的文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie

客户端浏览器会把Cookie保存起来，服务不保存。每次请求时客户端带上cookie。服务器检查该Cookie,以此来辨认用户状态。

实际就是颁发一个通行证，每人一个，无论谁访问都必须携带自己通行证。这样服务器就能从通行证上确认客户身份了。这就是Cookie的工作原理

cookie 可以让服务端程序跟踪每个客户端的访问，但是每次客户端的访问都必须传回这些 Cookie，

缺点::由于cookie是存在客户端上的，所以浏览器加入了一些限制确保cookie不会被恶意使用，同时不会占据太多磁盘空间，所以每个域的cookie数量是有限的

1.2.Session会话：

服务器在处理客户端请求过程中会创建session，并且为该session生存唯一的session ID。

服务器将session ID发送到客户端

当客户端再次请求时，就会带上这个session ID

服务器接收到请求之后就会一句Session ID 找到相应的Session ，完成请求

session是服务本地保存，发给客户端，客户端每次访问都带着，直接和服务的session比对

缺点：

如果使用单个服务器的话，用户过多的话，会造成服务器开销太大。如果我们系统采用分布式的话，我们登录时，响应我们的那台机器会记录我们登录信息，万一下一个请求，响应我们的不是原来那台机器的话，它并没有存储我们之前会话信息，就会认为我们并没有登录。session粘连或者session复制都不是特别好的方案。

1.3.Token令牌：

Token是服务端生成的一串字符串，当作客户端进行请求的一个令牌，当第一次登录后，服务器生成一个Token并将此Token返回给客户端，以后客户端只需带上这个Token前来请求数据即可，无需再次带上用户名和密码

token是 服务经过计算发给客户端的，服务不保存，每次客户端来请求，经过解密等计算来验证是否是自己下发的

token认证流程(token 的认证流程与cookie很相似)

用户登录，成功后服务器返回Token给客户端。
客户端收到数据后保存在客户端
客户端再次访问服务器，将token放入headers中
服务器端采用filter过滤器校验。校验成功则返回请求数据，校验失败则返回错误码

二、下面详细介绍一下session、cookie、token的区别，详细如下：

2.1.session和cookie区别：

·      数据存放位置不同：Session数据是存在服务器中的，cookie数据存放在浏览器当中。

·      安全程度不同：cookie放在服务器中不是很安全，session放在服务器中，相对安全。

·      性能使用程度不同：session放在服务器上，访问增多会占用服务器的性能；考虑到减轻服务器性能方面，应使用cookie。

·      数据存储大小不同：单个cookie保存的数据不能超过4K，session存储在服务端，根据服务器大小来定。

2.2.token和session区别：

·      token是开发定义的，session是http协议规定的；

·      token不一定存储，session存在服务器中；

·      token可以跨域，session不可以跨域，它是与域名绑定的。

2.3.session 的痛点(负载均衡导致的)

实际在生产上，为了保障高可用，一般服务器至少需要两台机器，通过负载均衡的方式来决定到底请求该打到哪台机器上。

如图示：客户端请求后，由负载均衡器（如 Nginx）来决定到底打到哪台机器

假设登录请求打到了 A 机器，A 机器生成了 session 并在 cookie 里添加 sessionId 返回给了浏览器，那么问题来了：下次添加购物车时如果请求打到了 B 或者 C，由于 session 是在 A 机器生成的，此时的 B,C 是找不到 session 的，那么就会发生无法添加购物车的错误，就得重新登录了，此时请问该怎么办。主要有以下三种方式

2.3.1、session 复制

A 生成 session 后复制到 B, C，这样每台机器都有一份 session，无论添加购物车的请求打到哪台机器，由于 session 都能找到，故不会有问题 

这种方式虽然可行，但缺点也很明显：

1. 同一样的一份 session 保存了多份，数据冗余
2. 如果节点少还好，但如果节点多的话，特别是像阿里，微信这种由于 DAU 上亿，可能需要部署成千上万台机器，这样节点增多复制造成的性能消耗也会很大。

2.3.2、session 粘连

这种方式是让每个客户端请求只打到固定的一台机器上，比如浏览器登录请求打到 A 机器后，后续所有的添加购物车请求也都打到 A 机器上，Nginx 的 sticky 模块可以支持这种方式，支持按 ip 或 cookie 粘连等等，如按 ip 粘连方式如下

upstream tomcats {
　　ip_hash;
　　server 10.1.1.107:88;
　　server 10.1.1.132:80;
}

这样的话每个 client 请求到达 Nginx 后，只要它的 ip 不变，根据 ip hash 算出来的值会打到固定的机器上，也就不存在 session 找不到的问题了，当然不难看出这种方式缺点也是很明显，对应的机器挂了怎么办？

2.3.3、session 共享

这种方式也是目前各大公司普遍采用的方案，将 session 保存在 redis，memcached 等中间件中，请求到来时，各个机器去这些中间件取一下 session 即可。

缺点其实也不难发现，就是每个请求都要去 redis 取一下 session，多了一次内部连接，消耗了一点性能，另外为了保证 redis 的高可用，必须做集群，当然了对于大公司来说, redis 集群基本都会部署，所以这方案可以说是大公司的首选了。

通过上文分析我们知道通过在服务端共享 session 的方式可以完成用户的身份定位，但是不难发现也有一个小小的瑕疵：搞个校验机制我还得搭个 redis 集群？大厂确实 redis 用得比较普遍，但对于小厂来说可能它的业务量还未达到用 redis 的程度，所以有没有其他不用 server 存储 session 的用户身份校验机制呢，token。

首先请求方输入自己的用户名，密码，然后 server 据此生成 token，客户端拿到 token 后会保存到本地，之后向 server 请求时在请求头带上此 token 即可。

相信大家看了上图会发现存在两个问题

1、 token 只存储在浏览器中，服务端却没有存储，这样的话我随便搞个 token 传给 server 也行？

答：server 会有一套校验机制，校验这个 token 是否合法。

2、怎么不像 session 那样根据 sessionId 找到 userid 呢，这样的话怎么知道是哪个用户？

答：token 本身携带 uid 信息

第一个问题，如何校验 token 呢？我们可以借鉴 HTTPS 的签名机制来校验。先来看 jwt token 的组成部分

可以看到 token 主要由三部分组成

1. header：指定了签名算法
2. payload：可以指定用户 id，过期时间等非敏感数据
3. Signature: 签名，server 根据 header 知道它该用哪种签名算法，再用密钥根据此签名算法对 head + payload 生成签名，这样一个 token 就生成了。

当 server 收到浏览器传过来的 token 时，它会首先取出 token 中的 header + payload，根据密钥生成签名，然后再与 token 中的签名比对，如果成功则说明签名是合法的，即 token 是合法的。而且你会发现 payload 中存有我们的 userId，所以拿到 token 后直接在 payload 中就可获取 userid，避免了像 session 那样要从 redis 去取的开销