在以往的面试记录里，我又看到了一个多次被问到的知识点，那就是 cookie、session、token 的区别有哪些？如果现在来问你，不知道你能否说清楚呢？
今天不仅仅是整理出这三者的区别，更重要的是能够真正去理解这三者之间的作用和联系。文章源自玩技e族-https://www.playezu.com/185470.html
cookie、session、token三者联系文章源自玩技e族-https://www.playezu.com/185470.html
在互联网里，一样事物的诞生往往是为了解决某种问题，这句话同样适用于此。文章源自玩技e族-https://www.playezu.com/185470.html
其实说到底，cookie、session、token 都围绕了一个点：身份认证。文章源自玩技e族-https://www.playezu.com/185470.html
为什么要认证文章源自玩技e族-https://www.playezu.com/185470.html
很简单，比如电商购物网站需要登录。在输入账号密码点击登录之后，对服务器就产生了一次会话 session，就像你我之间进行了一次交谈，我根据你的名字样貌记住了你。那么服务器也需要能够记住你，需要把大家区分开来。文章源自玩技e族-https://www.playezu.com/185470.html
但是，由于http协议是无状态的，已经登录过的用户没法通过协议层把状态保存下来，所以下次再请求的时候，服务器还是不知道你是谁。文章源自玩技e族-https://www.playezu.com/185470.html
有什么办法呢？文章源自玩技e族-https://www.playezu.com/185470.html
Session文章源自玩技e族-https://www.playezu.com/185470.html
当服务器收到登录请求之后，生成一个 session id 一起返回给客户端，客户端下次再请求的时候把 session id 一起带上。这时候每个客户端请求对应各自的 session id ，服务就知道怎么区分了。文章源自玩技e族-https://www.playezu.com/185470.html
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
嗯？其实这个事情核心在于身份认证，想个办法既能解决认证，又不用服务器保存不就好了：
客户端使用用户名和密码请求登录；
服务端收到请求，验证用户名和密码；
验证成功后，服务端会签发一个 token 令牌，再把这个token返回给客户端；
客户端收到 token 后可以把它存储起来，比如放到cookie中；
客户端每次向服务端请求资源时需要携带服务端签发的 token，可以在 cookie 或者 header 中携带；
服务端收到请求，然后去验证客户端请求里面带着的 token，如果验证成功，就向客户端返回请求数据。
重点就是在于服务端可以不用保存 token。
比如，当第一次收到客户端传过来的用户名和密码时，服务器认证通过后，通过加密算法生成一个字符串当做 token。当拿到后续请求中的 token，服务器再解析这个token，可以从中获取关键的信息，从而判断该token的有效性。
目前接触到的大多数系统，都是基于token验证来的，因为它的优点更适合当下的系统应用环境：
·无状态，可以更方便扩展
·更安全，可以防止跨站请求伪造 CSRF
·方便多平台跨域
·可以标准化，比如基于JWT Jsonwebtoken (JWT)