文章目录
- cookie和Session
- session和token
- cookie和token总结
- 分布式Session
cookie和Session
为什么要有session的出现？
答：是由于网络中http协议造成的，因为http本身是无状态协议，这样，无法确定你的本次请求和上次请求是不是你发送的。如果要进行类似论坛登陆相关的操作，就实现不了了。
Cookie和Session都是客户端与服务器之间保持状态的解决方案，具体来说，cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。
1、Cookie 及其相关 API ：
Cookie实际上是一小段的文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie，而客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器，服务器检查该Cookie，以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。
2、Session 及其相关 API：
同样地，会话状态也可以保存在服务器端。客户端请求服务器，如果服务器记录该用户状态，就获取Session来保存状态，这时，如果服务器已经为此客户端创建过session，服务器就按照sessionid把这个session检索出来使用；如果客户端请求不包含sessionid，则为此客户端创建一个session并且生成一个与此session相关联的sessionid，并将这个sessionid在本次响应中返回给客户端保存。保存这个sessionid的方式可以采用 cookie机制 ，这样在交互过程中浏览器可以自动的按照规则把这个标识发挥给服务器；若浏览器禁用Cookie的话，可以通过 URL重写机制将sessionid传回服务器。（？）
浏览完了就走了，两个连接之间是没有任何联系的，这也是 HTTP 为无状态的原因，因为它诞生之初就没有这个需求。
但随着交互式 Web 的兴起（所谓交互式就是你不光可以浏览，还可以登录，发评论，购物等用户操作的行为），单纯地浏览 web 已经无法满足人们的要求，比如随着网上购物的兴起，需要记录用户的购物车记录，就需要有一个机制记录每个连接的关系，这样我们就知道加入购物车的商品到底属于谁了，于是 Cookie 就诞生了。
Cookie，有时也用其复数形式 Cookies。类型为“小型文本文件”，是某些网站为了辨别用户身份，进行 Session 跟踪而储存在用户本地终端上的数据（通常经过加密），由用户客户端计算机暂时或永久保存的信息 。
▶▶▶二者存储位置：
Cookie 是web 服务器发送给浏览器的一块信息，浏览器会在本地一个文件中给每个web 服务器存储cookie以后浏览器再给特定的web 服务器发送请求时，同时会发送所有为该服务器存储的cookie。
Session 是存储在web 服务器端的一块信息。session 对象存储特定用户会话所需的属性及配置信息。当用户在应用程序的 Web 页之间跳转时，存储在 Session 对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。
Cookie 和session 的不同点：
1、无论客户端做怎样的设置，session 都能够正常工作。当客户端禁用cookie 时将无法使用cookie。
2、在存储的数据量方面：session 能够存储任意的java 对象，cookie 只能存储String 类型的对象。
以加入购物车为例，每次浏览器请求后 server 都会将本次商品 id 存储在 Cookie 中返回给客户端，客户端会将 Cookie 保存在本地，下一次再将上次保存在本地的 Cookie 传给 server 就行了，这样每个 Cookie 都保存着用户的商品 id，购买记录也就不会丢失了
cookie图示：
不难观察出 cookie 是存储在 client 的，而 session 保存在 server，sessionId 需要借助 cookie 的传递才有意义。
session和token
为什么会有token的出现？
答：首先，session的存储是需要空间的，其次，session的传递一般都是通过cookie来传递的，或者url重写的方式；而token在服务器是可以不需要存储用户的信息的，而token的传递方式也不限于cookie传递，当然，token也是可以保存起来的；
我们知道通过在服务端共享 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 主要由三部分组成
- header：指定了签名算法
- payload：可以指定用户 id，过期时间等非敏感数据
- Signature: 签名，server 根据 header 知道它该用哪种签名算法，再用密钥根据此签名算法对 head + payload 生成签名，这样一个 token 就生成了。
当 server 收到浏览器传过来的 token 时，它会首先取出 token 中的 header + payload，根据密钥生成签名，然后再与 token 中的签名比对，如果成功则说明签名是合法的，即 token 是合法的。而且你会发现 payload 中存有我们的 userId，所以拿到 token 后直接在 payload 中就可获取 userid，避免了像 session 那样要从 redis 去取的开销
注：header, payload 实际上是以 base64 的形式存在的，文中为了描述方便，省去了这一步。
cookie和token总结
Cookie 有哪些局限性？
1、 Cookie 跨站是不能共享的，这样的话如果你要实现多应用（多系统）的单点登录（SSO），使用 Cookie 来做需要的话就很困难了（要用比较复杂的 trick 来实现，有兴趣的话可以看文末参考链接）
画外音: 所谓单点登录，是指在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。
但如果用 token 来实现 SSO 会非常简单，如下
只要在 header 中的 authorize 字段（或其他自定义）加上 token 即可完成所有跨域站点的认证。
2、 在移动端原生请求是没有 cookie 之说的，而 sessionid 依赖于 cookie，sessionid 就不能用 cookie 来传了，如果用 token 的话，由于它是随着 header 的 authoriize 传过来的，也就不存在此问题，换句话说token 天生支持移动平台，可扩展性好
综上所述，token 具有存储实现简单，扩展性好这些特点。
token 有哪些缺点
那有人就问了，既然 token 这么好，那为什么各个大公司几乎都采用共享 session 的方式呢，可能很多人是第一次听到 token，token 不香吗? token 有以下两点劣势：
1、 token 太长了
token 是 header, payload 编码后的样式，所以一般要比 sessionId 长很多，很有可能超出 cookie 的大小限制（cookie 一般有大小限制的，如 4kb），如果你在 token 中存储的信息越长，那么 token 本身也会越长，这样的话由于你每次请求都会带上 token，对请求来是个不小的负担
2、 不太安全
网上很多文章说 token 更安全，其实不然，细心的你可能发现了，我们说 token 是存在浏览器的，再细问，存在浏览器的哪里？既然它太长放在 cookie 里可能导致 cookie 超限，那就只好放在 local storage 里，这样会造成安全隐患，因为 local storage 这类的本地存储是可以被 JS 直接读取的，另外由上文也提到，token 一旦生成无法让其失效，必须等到其过期才行，这样的话如果服务端检测到了一个安全威胁，也无法使相关的 token 失效。
所以 token 更适合一次性的命令认证，设置一个比较短的有效期
分布式Session
引入问题：
如果代码在一台应用系统，所有操作都在一台Tomcat上，没有什么问题。但是当我们部署多台系统，配合Nginx的时候会出现用户登录的问题
原因
由于 Nginx 使用默认负载均衡策略（轮询），请求将会按照时间顺序逐一分发到后端应用上。
也就是说刚开始我们在 Tomcat1 登录之后，用户信息放在 Tomcat1 的 Session 里。过了一会，请求又被 Nginx 分发到了 Tomcat2 上，这时 Tomcat2 上 Session 里还没有用户信息，于是又要登录。这就需要分布式session来解决登陆多次问题
解决分布式session的几个方案：
1、服务器实现的session 复制或session 共享，这类型的共享session 是和服务器紧密相关的，比如webSphere或JBOSS 在搭建集群时候可以配置实现session 复制或session 共享，但是这种方式有一个致命的缺点，就是不好扩展和移植，比如我们更换服务器，那么就要修改服务器配置。
2、利用成熟的技术做session复制，比如12306使用的gemfire，比如常见的内存数据库如redis 或memorycache，这类方案虽然比较普适，但是严重依赖于第三方，这样当第三方服务器出现问题的时候，那么将是应用的灾难。
3、将session 维护在客户端，很容易想到就是利用cookie，但是客户端存在风险，数据不安全，而且可以存放的数据量比较小，所以将session 维护在客户端还要对session 中的信息加密。
我们实现的方案可以说是第二种方案和第三种方案的合体，可以利用gemfire 实现session 复制共享，还可以将session 维护在redis 中实现session 共享，同时可以将session 维护在客户端的cookie 中，但是前提是数据要加密。
这三种方式可以迅速切换，而不影响应用正常执行。我们在实践中，首选gemfire 或者redis 作为session 共享的载体，一旦session 不稳定出现问题的时候，可以紧急切换cookie 维护session 作为备用，不影响应用提供服务。
