【面试高频】cookie、session、token？看完再也不担心被问了

在以往的面试记录里，我又看到了一个多次被问到的知识点，那就是 cookie、session、token 的区别有哪些？如果现在来问你，不知道你能否说清楚呢？

今天不仅仅是整理出这三者的区别，更重要的是能够真正去理解这三者之间的作用和联系。

cookie、session、token三者联系

在互联网里，一样事物的诞生往往是为了解决某种问题，这句话同样适用于此。

其实说到底，cookie、session、token 都围绕了一个点：身份认证。

为什么要认证

很简单，比如电商购物网站需要登录。在输入账号密码点击登录之后，对服务器就产生了一次会话 session，就像你我之间进行了一次交谈，我根据你的名字样貌记住了你。那么服务器也需要能够记住你，需要把大家区分开来。

但是，由于http协议是无状态的，已经登录过的用户没法通过协议层把状态保存下来，所以下次再请求的时候，服务器还是不知道你是谁。

有什么办法呢？

Session

当服务器收到登录请求之后，生成一个 session id 一起返回给客户端，客户端下次再请求的时候把 session id 一起带上。这时候每个客户端请求对应各自的 session id
，服务就知道怎么区分了。

Cookie

而客户端与服务器之间的会话，一般会使用 Cookie 来管理。

服务在向客户端返回响应时，会在首部字段Set-Cookie内写入 Session ID(如 PHPSESSID=028a8c…)。

客户端接收到从服务器端发来的 Session ID 后，会将其作为 Cookie 保存在本地。

比如我登录了一个论坛，浏览器 F12 就可以看到保存在本地的 cookie。

产生的问题

由于服务器也要保存这 session信息用于跟客户端传过来的进行比对，数量小了还好，请数量大了，服务器要保存的内容页就越多，会吃不消。

此外，还会影响服务器的拓展能力。比如服务由2台机器组成一个集群，而我之前登录后，session id保存在服务器A上，但是下次请求如果发送到服务器B就不行了，因为人家没存，所以不认。

还会有如下等问题：

• 对于非浏览器的客户端、手机移动端等不适用，因为session依赖于cookie，而移动端经常没有cookie
• 因为session认证本质基于cookie，所以如果cookie被截获，用户很容易收到跨站请求伪造攻击。并且如果浏览器禁用了cookie，这种方式也会失效
• 前后端分离系统中更加不适用，后端部署复杂，前端发送的请求往往经过多个中间件到达后端，cookie中关于session的信息会转发多次
• 由于基于Cookie，而cookie无法跨域，所以session的认证也无法跨域，对单点登录不适用

服务器：唉！该死的 sessionid，要是可以不用该多好呀 o(╥﹏╥)o。

Token

嗯？其实这个事情核心在于身份认证，想个办法既能解决认证，又不用服务器保存不就好了：

1. 客户端使用用户名和密码请求登录
2. 服务端收到请求，验证用户名和密码
3. 验证成功后，服务端会签发一个 token 令牌，再把这个token返回给客户端
4. 客户端收到 token 后可以把它存储起来，比如放到cookie中
5. 客户端每次向服务端请求资源时需要携带服务端签发的 token，可以在 cookie 或者 header 中携带
6. 服务端收到请求，然后去验证客户端请求里面带着的 token，如果验证成功，就向客户端返回请求数据

重点就是在于服务端可以不用保存 token。

比如，当第一次收到客户端传过来的用户名和密码时，服务器认证通过后，通过加密算法生成一个字符串当做 token。当拿到后续请求中的 token，服务器再解析这个token，可以从中获取关键的信息，从而判断该token的有效性。

目前接触到的大多数系统，都是基于token验证来的，因为它的优点更适合当下的系统应用环境：

• 无状态，可以更方便扩展
• 更安全，可以防止跨站请求伪造 CSRF
• 方便多平台跨域
• 可以标准化，比如基于JWT Json web token (JWT)