一、考察点
1.1、Session 的理解
数据存储在服务器端，只把关联数据的一个加密串放到cookie中标记
1.2、Token 的理解
浏览器接受服务器的set-cookie指令，并把cookie保存到客户端浏览器上，每个网站保存的cookie只作用于自己的网站
1.3、Cookie 的理解
是用户请求时附带的请求字段，用于验证身份与权限
二、技术点
2.1、session的实现原理
服务器创建session出来后，会把sessionid以cookie的形式回写给客户端浏览器，只要不关闭客户端浏览器，每次访问服务器时，都会携带sessionid，服务器根据客户端携带的sessionid来识别用户身份，然后为与之对应的session(session保存在服务器端)提供服务。
2.2、cookie的实现原理
cookie由服务器生成，发送给客户端浏览器，浏览器以键值对的形式将cookie保存到某个目录下的文本文件中，客户端每次请求网站时都会把该cookie发送给服务器
服务器根据客户端携带的cookie识别用户的身份
2.3、token的实现原理
基于token的身份验证是无状态的，我们不会将用户信息保存到服务器或session中。这样就解决了在服务端存储信息时许多Nosession的问题，也就意味着你的程序可以根据需要去增减机器，而不用担心用户是否处于登录状态。
基于token的身份验证过程如下：
- 用户发送数据请求
- 程序验证
- 程序返回一个签名的token给客户端
- 客户端存储token，用于每次发送请求
- 服务端验证token并返回数据
token通常在http的请求头中发送给服务器
三、总结答案
| cookie | session | token | |
|---|---|---|---|
| 存储位置 | 客户端 | 服务端 | 客户端 |
| 安全性 | 较差 | 较高 | 相对最高 |
| 占用服务器资源 | 消耗少 | 访问量大时消耗多 | 基本不消耗资源 |
| 作用 | 记录用户状态，辨认身份(传话管理，个性化、追踪) | 同cookie | 减轻数据库查询的压力，提供授权和认证功能 |
| 优点 | 易于使用和实现，不消耗服务器资源，透明性、持久性 | 信息非常安全都是存储在服务端 | 无状态，可扩展和解耦，提供授权和认证功能 |
| 缺点 | 安全性差，容易被劫持 | 服务器压力大，扩展性不强，分布式、夸系统实现困难 | 占带宽(最小的token也比cookie大)，性能差(需要验证两次)，无法在服务端注销，很难解决劫持问题 |
| 适用范围 | 在线订货系统，网站个人化和网站跟踪 | session更适用于客户端代码与服务端代码运行在同一台服务器上 | token更适用于前后端分离的项目(客户端代码与服务端代码运行在不同的服务器上) |