之前也是看了很多session、cookie & token相关的介绍文章，还不是很清楚的理解，所以今天把这块的知识点再整理下，也是为了让自己更加理解下，首先默默地在心里问几个问题，为什么要有session、cookie 和 token呢？都有什么原理？又有什么作用？

带着这些问题，我们先依次理以下几个概念：

Http是一种无状态的协议

无状态是指上一次的请求和这一次没有关系，没有关联，不需要记录浏览了什么内容，每次发送的请求都是全新的，好处很明显就是快！当然也有不好的一面，就是当把同个域名下有关联的网页要关联起来就得依靠一些工具，譬如网购的时候商品浏览、购买、配送，如何确定是谁在看什么商品，买什么商品，给寄送到哪去怎么关联起来呢。

由于Http是无状态的，为了使同一个域名下所有网页共享某些数据，就出现cookie和session。

Cookie

cookie是浏览器里可以永久存储的一种数据，是浏览器实现存储数据的一种实现方式。

cookie一般是由服务器生成的，发送给浏览器端，浏览器把cookie以KV的形式存储到某个目录下文本文件，下一次请求同一网站时会把该cookie发送给服务器。

如何设置cookie呢？分成客户端和服务端设置，先介绍下客户端设置：

客户端设置cookie的选项有expires, domain, path, secure(secure只在https协议的网页中, 客户端设置secure类型cookie才能生效)。设置好cookie会自动添加到request header中，然后服务端接收到cookie。

服务端设置cookie，不管是请求个什么资源文件还是ajax请求，服务端都会返回response，在response的header中有一项叫set-cookie,是服务端专门来设置cookie的。

【额外补充点】HTML5提供了两种本地存储的方式 sessionStorage 和 localStorage：

session

session就是会话，也是由服务端生产的，因为服务器端要区分当前的请求是谁发的，为了做这种区分，服务端就要给客户端做不同的身份标识，然后客户端每次请求的时候都会带上这个身份标识。那服务器端就能区分请求来自于谁了。

那如何保存session呢？实现方式有很多种，对于浏览端，可以采用cookie的方式。

一般也是用cookie+session，不会单独使用，虽然单独保存也会保持会话状态。

存在问题，扩展性不好，单机没有问题，如果是服务器集群，或者是跨域的服务导向架构，那就要求session数据共享，每台服务器都要读取session。举例说下，同一个公司多个网站要实现单点登录（登录一个网站，然后访问另外一个网站时自动登录）。

策略1：Nginx ip_hash 策略，服务端使用 Nginx 代理，每个请求按访问 IP 的 hash 分配，这样来自同一 IP 固定访问一个后台服务器，避免了在服务器 A 创建 Session，第二次分发到服务器 B 的现象。

策略2：Session复制，任何一个服务器上的 Session 发生改变（增删改），该节点会把这个 Session 的所有内容序列化，然后广播给所有其它节点。

策略3：共享Session：将Session Id 集中存储到一个地方，所有的机器都来访问这个地方的数据。这种方案的优点是架构清晰，缺点是工程量比较大。另外，持久层万一挂了，就会单点失败。

另一种是服务器索性不存session数据了，所有数据就保存在客户端，每次请求都发回服务器。这种方案就是接下来要介绍的基于Token的验证。

Token

token也称作令牌，由uid+time时间戳+sign【+固定参数】组成：

uid：用户身份唯一标识

time：当前时间的时间戳

sign：签名，使用hash/encrypt压缩成定长的十六进制字符串，以防止第三方恶意拼接

【固定参数（可选）】：把一些常用固定参数加到token中，避免重复查库

token的认证也是类似于临时的证书签名，并且是一种服务端无状态的验证方式，适用于rest api 的场景，所谓无状态是指服务端不会保存身份认证的相关数据；

存储：token一般储存在localstorage、cookie或sessionstorage中。在服务器存储在数据库。认证流程和cookie基本一致，如下图：

还有现成实现的标准JWT(JSON Web Token)，JWT最开始的初衷是为了实现授权和身份认证作用的，可以实现无状态，分布式的Web应用授权。大致实现的流程如下。JSON Web Tokens由dot（.）分隔的三个部分组成，它们是：

Header（头部）

Payload（负载）

Signature（签名）

通常如下展示是<p>xxxxx.yyyyy.zzzz</p>。

1、客户端需要携带用户名/密码等可证明身份的的内容去授权服务器获取JWT信息；

2、每次服务都携带该Token内容与Web服务器进行交互，由业务服务器来验证Token是否是授权发放的有效Token，来验证当前业务是否请求合法。

这里需要注意：不是每次请求都要申请一次Token，这是需要注意，如果不是对于安全性要求的情况，不建议每次都申请，因为会增加业务耗时；比如只在登陆时申请，然后使用JWT的过期时间或其他手段来保证JWT的有效性；

区别

Cookie和Session的区别

1、存储位置不同： cookie数据存放在客户的浏览器上，session数据放在服务器上

2、隐私策略不同：cookie不是很安全， 别人可以分析存放在本地的cookie并进行cookie欺骗，考虑到安全应当使用session

3、session会在一定时间内保存在服务器上。当访问增多，就会比较占用你服务器的性能，考虑到减轻服务器性能方面，应当使用cookie

4、存储大小不同： 单个cookie保存的数据不能超过4k, 很多浏览器都限制一个站点最多保存20个cookie

Token和Session的区别

Session是一种HTTP储存机制， 为无状态的HTTP提供持久机制;

Token就是令牌， 比如你授权(登录)一个程序时，它就是个依据，判断你是否已经授权该软件；

Session和Token并不矛盾，作为身份认证Token安全性比Session好，因为每一个请求都有签名还能防止监听以及重放攻击，而Session就必须依赖链路层来保障通讯安全了。如上所说，如果你需要实现有状态的回话，仍然可以增加Session来在服务端保存一些状态。

总结

cookie，session，Token没有绝对好与坏之分，只要还是要结合实际的业务场景和需求来决定采用哪种方式来管理回话，当然也可以三种都用。