cookie、session、token的区别和联系

cookie、session、token的区别和联系

HTTP是一种无状态的协议，为了分辨链接是谁发起的，支持客户端与服务器之间的交互，需要通过不同的技术为交互存储状态，给用户颁发许可证，许可证的实现技术有cookie、Session和Token。

cookies

是服务器生成，保存在本地机器上存储的小段文本并随每一个请求发送至同一服务器，是在客户端保持状态的方案。

主要内容包括：cookie名，cookie值，过期时间，路径和域。

设置过期时间，则cookie会被保存在硬盘上，过期后自动清除；若没有设置过期时间，则cookie被保存在浏览器内存中，浏览器关掉就消失了。路径和域就是对应的域名，a网站的cookie自然不能给b用。

Session

存在服务器端的一种用来存放对象的HashTable结构，是一种保存上下文信息的机制，它通过sessionId来区分不同的客户端，而sessionId是保存在客户端的，做为客户端与服务器的验证标识，它是一个24位的随机字符串，用户每次提交页面时，浏览器都会把这个sessionId包含在HTTP头中提交给WEB服务器。

session生成过程

当服务器接收到客户端的请求，要求产生一个session时，服务器会先检查下，客户端的cookies中是否有sessionId，并且判断它是否过期。若存在sessionId且还没有过期，则会根据该sessionId值将服务器中的session检索出来；否则，将产生一个新的session，当创建一个新session后，服务器也会产生一个sessionId号，回写客户端的cookies当中。

一般这个值会有个时间限制，超时后毁掉这个值，默认30分钟。

cookie和session的区别

存储数据方面：session存储对象，cookie存储String存放地址：cookie保存在客户端，session保存在服务端Session过多时会消耗服务器资源，大型网站会有专门Session服务器；每个域的cookie数量和数据大小都是有限的，单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。session不区分路径，同一个用户在同一个网站期间，所有的session在任何一个地方都可以访问到。而cookies是区分路径的，如果设置了路径参数，那么同一个网站不同路径下的cookies是互相访问不到的。 单点登录中，cookie 被禁用了怎么办？

单点登录的原理是后端生成一个 session ID，设置到 cookie，后面所有请求浏览器都会带上cookie，然后服务端从cookie获取 session ID，查询到用户信息。所以，保持登录的关键不是cookie，而是通过cookie 保存和传输的 session ID，本质是能获取用户信息的数据。除了cookie，还常用 HTTP 请求头来传输。但这个请求头浏览器不会像cookie一样自动携带，需手工处理

实现负载均衡时session存在的问题及解决方案

为了保障高可用，一般服务器至少需要两台机器，通过负载均衡的方式来决定到底请求该打到哪台机器上。这就涉及到了session多服务器间共享问题：

session 复制

A 生成 session 后复制到 B, C，这样每台机器都有一份 session，但是同一样的一份 session 保存了多份，数据冗余

session 粘连

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

session 共享

将 session 保存在 redis，memcached 等中间件中，请求到来时，各个机器去这些中间件取一下 session 即可。就是每个请求都要去 redis 取一下 session，多了一次内部连接，消耗了一点性能。

 session多服务器间共享

服务器实现的 session 复制或 session 共享，如 webSphere或 JBOSS 在搭集群时配置实现 session 复制或 session 共享.致命缺点:不好扩展和移植。
利用成熟技术做session复制，如12306使用的gemfire，如常见内存数据库redis或memorycache，虽较普适但依赖第三方.
将 session维护在客户端，利用 cookie，但客户端存在风险数据不安全，且可以存放的数据量较小，所以将session 维护在客户端还要对 session 中的信息加密。
第二种方案和第三种方案的合体，可用gemfire实现 session 复制共享，还可将session 维护在 redis中实现 session 共享，同时可将 session 维护在客户端的cookie 中，但前提是数据要加密。
这三种方式可迅速切换，而不影响应用正常执行。在实践中，首选 gemfire 或者 redis 作为 session 共享的载体，一旦 session 不稳定出现问题的时候，可以紧急切换 cookie 维护 session 作为备用，不影响应用提供服务

Token

token意思是令牌，是用户身份的验证方式。最简单的token组成：uid(用户唯一的身份标识)、time（当前时间的时间戳）、sign（签名）等元素加密产生的加密字符串。

Token认证的五点认识

Token就是一些信息的集合；在Token中包含足够多的信息，以便在后续请求中减少查询数据库的几率；服务端需要对cookie和HTTP Authrorization Header进行Token信息的检查；基于上一点，你可以用一套token认证代码来面对浏览器类客户端和非浏览器类客户端；因为token是被签名的，所以我们可以认为一个可以解码认证通过的token是由我们系统发放的，其中带的信息是合法有效的；

为什么有了session还需要token？

随着Web，应用程序，已经移动端的兴起，基于服务器验证方式逐渐暴露出了问题。尤其是在可扩展性方面。

Seesion：每次认证用户发起请求时，服务器需要去创建一个记录来存储信息。当越来越多的用户发请求时，内存的开销也会不断增加。

可扩展性：在服务端的内存中使用Seesion存储登录信息，伴随而来的是可扩展性问题。

CORS(跨域资源共享)：当我们需要让数据跨多台移动设备上使用时，跨域资源的共享会是一个让人头疼的问题。在使用Ajax抓取另一个域的资源，就可以会出现禁止请求的情况。

CSRF(跨站请求伪造)：用户在访问银行网站时，他们很容易受到跨站请求伪造的攻击，并且能够被利用其访问其他的网站。

在这些问题中，可扩展行是最突出的。因此我们有必要去寻求一种更有行之有效的方法。

Token的身份验证的过程

用户通过用户名和密码发送请求。

程序验证。

程序返回一个签名的token给客户端。

客户端储存token，并且每次用于每次发送请求。

服务端验证token并返回数据。

Token和session的区别

session是一种认证方式；token是认证授权的方式，认证是针对用户，授权是针对App。多数场景上使用 session 会更合理；如果在单点登录（一次性命令认证上），或者第三方共享、允许第三方调用 API 接口，使用 token 会更合适，最好在不同的业务场景中合理选型，才能达到事半功倍的效果。

Session是存放在服务器端的，可以保存在：内存、数据库、NoSQL中。它采用空间换时间的策略来进行身份识别，若Session没有持久化落地存储，一旦服务器重启，Session数据会丢失。Token是放在客户端存储的，采用了时间换空间策略，它也是无状态的，所以在分布式环境中应用广泛。