session和cookie和 token

随着交互式Web应用的兴起，像在线购物网站，需要登录的网站等等，马上就面临一个问题，那就是要管理会话，必须记住哪些人登录系统，  哪些人往自己的购物车中放商品，也就是说我必须把每个人区分开， 因为HTTP请求是无状态的，所以想出的办法就是给客户端发一个会话标识(session id), 说白了就是一个随机的字串，每个客户端收到的都不一样，  每次客户端向服务器发起HTTP请求的时候，把这个字符串给一并捎过来， 这样服务器就能区分开谁是谁了。

每个客户端只需要保存自己的session id，而服务器要保存所有人的session id，这对服务器说是一个巨大的开销 ， 严重的限制了服务器扩展能力， 比如说用两个机器组成了一个集群， 小F通过机器A登录了系统，  那session id会保存在机器A上，  假设小F的下一次请求被转发到机器B怎么办？  机器B可没有小F的 session id啊。这时候有常用的两种解决方式，一个是使用session replication 策略，也就是复制会话，即一个用户访问了一次就把session复制到所有的服务器或这一部分服务器。这样的好处是如果正访问的服务器down了用户可以自动被转到别的服务器session不丢失，缺点当然是效率低。二是使用session sticky策略，此策略则是不复制，一个用户访问了一次后，同一个session周期内，所有的请求都定向到这个服务器，down了session就丢了。

为了能让服务器不去保存session，减轻服务器的压力，就有了令牌(token)。其实token的意义是和session id的意义是一样的，都是为了验证客户端的登录信息。比如说， 小F已经登录了系统，服务器给他发一个令牌(token)， 里边包含了小F的 user id， 下一次小F 再次通过Http 请求访问服务器的时候， 把这个token 通过Http header 带过来不就可以了。为验证这个token是服务器本身生成的而不是伪造的，服务器就要去验证，但是服务器又没有保存相同的token，所以在服务器给客户端发送的token的时候，服务器对token进行加密。比如说客户端用HMAC-SHA256 算法，加上一个只有客户端才知道的密钥，  对数据做一个签名， 把这个签名和数据一起作为token ， 由于密钥别人不知道， 就无法伪造token了。这个token 服务器不保存，  当小F把这个token 给服务器发过来的时候，服务器再用同样的HMAC-SHA256 算法和同样的密钥，对数据再计算一次签名， 和token 中的签名做个比较， 如果相同， 我就知道小F已经登录过了，并且可以直接取到小F的user id ,  如果不相同， 数据部分肯定被人篡改过， 我就告诉发送者： 对不起，没有认证。

                                      

这样一来，服务器就不保存session id 了，服务器只生成token , 然后验证token，服务器用CPU的计算时间获取了服务器中的session 存储空间 。

而cookie 是一个非常具体的东西，指的就是浏览器里面能永久存储的一种数据，仅仅是浏览器实现的一种数据存储功能。cookie由服务器生成，发送给浏览器，浏览器把cookie以key-value的形式保存到某个目录下的文本文件内，下一次请求同一网站时会把该cookie发送给服务器。由于cookie是存在客户端上的，所以浏览器加入了一些限制确保cookie不会被恶意使用，同时不会占据太多磁盘空间，所以每个域的cookie数量是有限的。