大话Cookie、Session、Token的区别

最新推荐文章于 2024-05-08 21:58:24 发布

请给小胡大红包

最新推荐文章于 2024-05-08 21:58:24 发布

阅读量199

点赞数

分类专栏：软件测试文章标签： session cookie

本文链接：https://blog.csdn.net/tairu/article/details/106354807

版权

软件测试专栏收录该内容

17 篇文章 5 订阅

订阅专栏

Web发展史

第一阶段，Web基本就是文档的浏览操作，作为服务器，不需要记住刚刚是谁发了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挂掉了，小F的请求就不得不转到机器B上。

于是，只能做session的复制了，这样把session搬来搬去，也不是办法。既然这样，那就把session id几种存储到一个地方，所有的机器都来访问这个地方的数据，这样就不用复制了，但是又有一个问题，如果那个负责session的机器挂了，这样所有的用户就都得重新登录一遍。

第三阶段，思来考去，session的存储确实是个大问题，祭坛这样就直接不存储了，但是不存储，服务器如何知道客户端发过来的session是不是自己生成的呢？于是，就产生了令牌（token），里面包含了客户端的user id，下一次访问的时候，把token通过Http header带过来就可以了。

不过，从目前来看，token的本质了session是没有区别的，服务器既没有办法验证客户端带来的token是不是自己生成的，也不能防止别人伪造token。既然这样，那就对数据做一个签名，比如用HMAC-SHA256算法，加上一个只有服务器知道的密钥，对数据做一个签名，把签名和数据一起作为token，由于密钥别人不知道，也就无法伪造了。

这样看来，伪造的问题解决了，那么怎么验证客户端带来的token对不对呢？很简单，当客户端把token发过来的时候，服务器端根据HMAC-SHA256算法对数据再计算一次签名，如果相同，服务器端就可以知道客户端已经登录过了，直接取客户端的user id，如果不同，那就验证不通过。

Cookie

Cookie是浏览器里面能永久存储的一种数据，仅仅是浏览器实现的一种数据存储功能。cookie由服务器生成，发送给浏览器，浏览器将cookie以kv的形式保存，下次请求同一网站时会把该cookie发送给服务器。浏览器端加了一些限制防止cookie被恶意使用，同时每个域的cookie是有限的，不会占用太大空间。

Session

session，就是会话。比如你和一个人交谈，对方的一些特征让你知道你现在是在和张三交谈，而不是李四。session也是类似道理，服务器为了区分当前发送给自己的请求是谁，而给每个客户端分配不同的“身份标识”，然后客户端每次向服务器端发送请求时，都将这个“身份标识”带上，这样服务器就知道这个请求是来自于谁了。客户端保存这个“身份标识”有很多种方式，浏览器客户端，大家默认采用cookie的方式。

在基于服务器的验证中，服务器使用session将用户的信息临时保存在了服务器上，用户离开网站后，session就会被销毁。如果web服务器做了负载均衡，那么下一个操作请求到了另一个服务器的时候，session就会丢失。

在基于session的身份验证中，服务器在用户登录后，为用户创建一个session，然后，session id会被存储在用户浏览器的cookie中。当用户保存登录状态时，cookie将与每个后续请求一起被发送出去。然后，服务器可以将存储在cokkie中的session id与存储在内存中或者数据库中的session信息进行比较，以验证用户的身份，返回给用户客户端响应信息时，会附带用户当前的状态。