如何理解Cookie、Session和Token

前言

Web诞生之初，功能比较单一：允许Internet上任意一个用户都可以从许多文档服务计算机的数据库中搜索和获取文档。服务器不需要记录谁在某一段时间里都浏览了什么文档，每次请求都是一个新的HTTP协议， 即请求加响应，服务器不用记住是谁刚刚发了HTTP请求， 每个请求对服务器来说都是全新的。

随着交互式Web应用的兴起，网站有了登录的需求，如在线购物网站，社交网站等等。这就面临一个问题，服务器必须记住哪些人登录了系统， 哪些人往自己的购物车中添加了商品， 也就是说服务器要识别每个用户。

因为HTTP请求是无状态的，所以想出的办法就是给大家发一个会话标识(session id)， 说白了就是一个随机的字串，每个用户收到的都不一样。 当用户向服务器发起HTTP请求的时候，带上这个字符串， 这样服务器就能识别不同的用户了。

所以就有了Session的引入，即服务端和客户端都保存一段文本，客户端每次发起请求都带着，这样服务器就知道客户端是否发起过请求。

这样，就导致客户端频繁向服务端发出请求数据，服务端频繁的去数据库查询用户名和密码并进行对比，判断用户名和密码正确与否。而Session的存储是需要空间的，频繁的查询数据库给服务器造成很大的压力。

随着Web移动端的兴起，这种验证的方式逐渐暴露出了问题。尤其是在可扩展性方面。

基于服务器验证方式暴露的一些问题

1.Seesion：每次认证用户发起请求时，服务器需要去创建一个记录来存储信息。当越来越多的用户发请求时，内存的开销也会不断增加。

2.可扩展性：在服务端的内存中使用Seesion存储登录信息，伴随而来的是可扩展性问题。

3.CORS(跨域资源共享)：当我们需要让数据跨多台移动设备上使用时，跨域资源的共享会是一个让人头疼的问题。在使用Ajax抓取另一个域的资源，就可以会出现禁止请求的情况。

4.CSRF(跨站请求伪造)：用户在访问银行网站时，他们很容易受到跨站请求伪造的攻击，并且能够被利用其访问其他的网站。

于是有人就一直在思考， 服务器为什么要保存这些信息呢， 只让每个客户端去保存该多好？

在这种情况下，Token应用而生。

Token是服务端生成的一串字符串，以作客户端进行请求的一个令牌。当客户端第一次访问服务端，服务端会根据传过来的唯一标识userId，运用一些算法，并加上密钥，生成一个Token，然后通过BASE64编码一下之后将这个Token返回给客户端，客户端将Token保存起来（可以通过数据库或文件形式保存