说说Session和Token的那些事儿

很多童鞋对Session和Token懵懵懂懂，今天我们聊一下Session和Token那些事儿。

服务器端创建Session，并将SessionID回传给客户端。

客户端收到SessionID，有4种方式处理:

• 浏览器Cookie;
• LocalStorage；
• URL回写；
• 隐藏表单字段。

也就是说，Session不严格依赖Cookie。

SessionID如果本身不携带或者无法反解析出会话的用户信息，服务端无法判定该SessionID是否是由自己发出的。

此时，服务端需要存储所有用户的SessionID或者Session，然后与传入的SessionID挨个比对，若有匹配的，则证明已登陆过。

需要注意的是: 服务端Session不是只能存储在进程内存，还可以存储在本地文件、数据库、缓存系统(Redis等)
只是一般放在进程内存而已，以方便维护。

海量用户场景下，服务端需要存储大量的Session信息，存储的压力巨大。

那有没有服务端不用存储Session信息的会话技术呢？

答案就是Token。

比如服务端可以对用户ID进行加密，加密后的字符串作为签名sign和用户ID共同组成Token返回给客户端。

客户端携带Token再次请求时，服务端重新对用户ID进行加密，然后与Token中的sign进行对比，若签名相同，则代表用户已登陆过。

因为会话期间，后续的每次请求均需要进行重新加密、验签过程，所以Token是典型的用CPU资源(加解密)来换取存储资源。

为了规范Token的创建方式，JSON Web Token(JWT)横空出世，JWT字符串的生成规则如下图所示:

主要分为3部分:

• header(头)

header主要声明Token的类型为JWT以及使用的加密算法alg是啥。

• payload(荷载)

自定义需要携带的数据，标准格式为用户ID和数据创建时间，也可添加自己想携带的任何信息。

荷载中禁止携带任何涉密的信息(如密码等)，因为base64只是编解码算法，不涉及加密。

• signature(签名)

signature(签名)是基于header(头)和payload(荷载)的拼接字符串调用加密算法(header里声明的算法，服务端持有密钥)生成的。

综上，可以得到以下结论:

• Session常和Cookie搭档，Cookie存在于客户端，而Session存在于服务端，但Cookie不是实现Session的唯一手段；
• Token其实与SessionID类似，均是一长串字符串，区别在于Token中包含有header和sign，服务端可以通过校验sign即可判断客户端是否已登录；
• JWT是Token机制的1种规范实现，相当于Token的子集。