彻底理解 Cookie,Session,Token
文章目录
发展史
- 很久很久以前,Web基本上就是文档的浏览而已,既然是浏览,作为服务器,不需要记录谁在某一段时间里都浏览了什么文档,每次请求都是一个新的HTTP协议,就是请求加响应,尤其是我不用记住是谁刚刚发了HTTP请求,每个请求对我来说都是全新的。这段时间很嗨皮。
- 但是随着交互式Web应用的兴起,像在线购物网站,需要登录的网站等等,马上就面临一个问题,那就是要管理会话,必须记住哪些人登录系统, 哪些人往自己的购物车中放商品, 也就是说我必须把每个人区分开,这就是一个不小的挑战,因为HTTP请求是无状态的,所以想出的办法就是给大家发一个会话标识(session id), 说白了就是一个随机的字串,每个人收到的都不一样, 每次大家向我发起HTTP请求的时候,把这个字符串给一并捎过来, 这样我就能区分开谁是谁了
- 这样大家很嗨皮了,可是服务器就不嗨皮了,每个人只需要保存自己的session id,而服务器要保存所有人的session id!如果访问服务器多了,就得由成千上万,甚至几十万个。
这对服务器说是一个巨大的开销,严重的限制了服务器扩展能力,比如说我用两个机器组成了一个集群,小F通过机器A登录了系统,那session id会保存在机器A上,假设小F的下一次请求被转发到机器B怎么办?机器B可没有小F的session id啊。
有时候会采用一点小伎俩:session sticky,就是让小F的请求一直粘连在机器A上,但是这也不管用,要是机器A挂掉了,还得转到机器B去。
那只好做session的复制了,把session id在两个机器之间搬来搬去,快累死了。
后来有个叫Memcached的支了招:把session id集中存储到一个地方,所有的机器都来访问这个地方的数据,这样一来,就不用复制了,但是增加了单点失败的可能性,要是那个负责session 的机器挂了,所有人都得重新登录一遍,估计得被人骂死。
也尝试把这个单点的机器也搞出集群,增加可靠性,但不管如何,这小小的session 对我来说是一个沉重的负担。 - 于是有人就一直在思考,我为什么要保存这可恶的session呢,只让每个客户端去保存该多好?
可是如果不保存这些session id,怎么验证客户端发给我的session id的确是我生成的呢