您现在的位置: 首页 > 网站导航收录 > 百科知识百科知识

token是什么意思(手机显示token登录失效怎么登录)

用户,购物车,的话token是什么意思(手机显示token登录失效怎么登录)

发布时间：2020-12-06加入收藏来源：互联网点击：

很多朋友想了解关于cookie的一些资料信息，下面是小编整理的与cookie相关的内容分享给大家，一起来看看吧。很多朋友想了解关于session的一些资料信息，下面是小编整理的与session相关的内容分享给大家，一起来看看吧。

原文链接：https://mp.weixin.qq.com/s/StIo-eC-7UeBr-fb6lIZkQ

作者：码海

Cookie

1991年，HTTP 0.9诞生了。当时只是为了满足浏览web文档的需求，所以只有GET请求。浏览了一下，就走了。两个连接之间没有连接，这也是HTTP无状态的原因，因为它诞生之初没有这个要求。

但是，随着交互式web的兴起(所谓交互式是指你不仅可以浏览，还可以登录、发表评论、购物等。)，单纯的浏览网页已经不能满足人们的要求。比如网购的兴起，需要记录用户的购物车记录，这样就需要一个机制来记录每一个连接的关系，这样我们就可以知道加入购物车的商品是属于谁的，Cookie就诞生了。

有时是复数形式。类型“小文本文件”是指一些网站为了识别用户身份和跟踪会话而存储在用户本地终端的数据(通常是加密的)，以及用户客户端电脑临时或永久保存的信息。

工作机制如下

以加入购物车为例。在每次浏览器请求之后，服务器会将当前的产品id存储在一个Cookie中，并将其返回给客户端。客户端会将Cookie保存在本地，上次保存在本地的Cookie会在下次发送到服务器，这样每个Cookie都会保存用户的产品id，购买记录不会丢失。

仔细看上面这张图，相信你很容易发现，随着购物车里的商品越来越多，每个请求的cookie也越来越大，对于每个请求来说都是一个不小的负担。我只是想在购车单上加一项。为什么要把历史商品记录返回给服务器？事实上，购物车信息已经记录在服务器中。像浏览器一样操作不是没必要吗？如何改善？

Session

经过深思熟虑，由于用户购物车的信息会存储在服务器中，所以只需要在Cookie中保存能够识别用户身份的信息，并知道是谁发起加入购物车的操作，这样每次请求后，Cookie中都要带入用户的身份信息，请求体中也要带入这个购物车的商品id。cookie的大小大大减小。我们把这种可以识别哪个请求是由哪个用户会话发起的机制称为(session mechanism)，生成的可以识别用户身份信息的字符串称为sessionId。其工作机制如下

首先，当用户登录时，服务器将为用户生成一个会话，并为其分配一个惟一的sessionId。这个sessionId是和某个用户绑定的，也就是说根据这个sessionid(假设是abc)就可以查出是哪个用户。然后，这个sessionid通过cookie发送给浏览器后，浏览器只需要在每次添加购物车时将sessionId=abc键值对带入cookie中即可。服务器根据sessionId找到其对应的用户后，将传递的商品Id保存到服务器中对应用户的购物车中，你可以看到这样就不再需要发送cookie中购物车的所有商品id，大大减轻了请求的负担！

另外，从上面不难观察到cookie 是存储在 client 的，而 session 保存在 server，sessionId需要cookie的帮助才有意义。

session 的痛点

看起来问题已经被cookie session解决了，但是我们忽略了一个问题。上述情况能够正常工作是因为我们假设服务器工作在单机上，但实际上在生产中，为了保证高可用性，一般服务器至少需要两台机器，采用负载均衡的方法来决定调用哪台机器的请求。

平衡

如图示：客户端请求后，由负载均衡器（如 Nginx）来决定到底打到哪台机器

假设登录请求打到了 A 机器，A 机器生成了 session 并在 cookie 里添加 sessionId 返回给了浏览器，那么问题来了：下次添加购物车时如果请求打到了 B 或者 C，由于 session 是在 A 机器生成的，此时的 B,C 是找不到 session 的，那么就会发生无法添加购物车的错误，就得重新登录了，此时请问该怎么办。主要有以下三种方式

1、session 复制

A 生成 session 后复制到 B, C，这样每台机器都有一份 session，无论添加购物车的请求打到哪台机器，由于 session 都能找到，故不会有问题

balance (1)

这种方式虽然可行，但缺点也很明显：

同一样的一份 session 保存了多份，数据冗余如果节点少还好，但如果节点多的话，特别是像阿里，这种由于 DAU 上亿，可能需要部署成千上万台机器，这样节点增多复制造成的性能消耗也会很大。

2、session 粘连

这种方式是让每个客户端请求只打到固定的一台机器上，比如浏览器登录请求打到 A 机器后，后续所有的添加购物车请求也都打到 A 机器上，Nginx 的 sticky 模块可以支持这种方式，支持按 ip 或 cookie 粘连等等，如按 ip 粘连方式如下

upstreamtomcats{ip_hash;server10.1.1.107:88;server10.1.1.132:80;}

这样的话每个 client 请求到达 Nginx 后，只要它的 ip 不变，根据 ip hash 算出来的值会打到固定的机器上，也就不存在 session 找不到的问题了，当然不难看出这种方式缺点也是很明显，对应的机器挂了怎么办？

3、session 共享

这种方式也是目前各大公司普遍采用的方案，将 session 保存在 redis，memcached 等中间件中，请求到来时，各个机器去这些中间件取一下 session 即可。

缺点其实也不难发现，就是每个请求都要去 redis 取一下 session，多了一次内部连接，消耗了一点性能，另外为了保证 redis 的高可用，必须做集群，当然了对于大公司来说, redis 集群基本都会部署，所以这方案可以说是大公司的首选了。

Token：no session!

通过上文分析我们知道通过在服务端共享 session 的方式可以完成用户的身份定位，但是不难发现也有一个小小的瑕疵：搞个校验机制我还得搭个 redis 集群？大厂确实 redis 用得比较普遍，但对于小厂来说可能它的业务量还未达到用 redis 的程度，所以有没有其他不用 server 存储 session 的用户身份校验机制呢，这就是我们今天要介绍的主角：token。

首先请求方输入自己的用户名，密码，然后 server 据此生成 token，客户端拿到 token 后会保存到本地，之后向 server 请求时在请求头带上此 token 即可。

相信大家看了上图会发现存在两个问题

1、 token 只存储在浏览器中，服务端却没有存储，这样的话我随便搞个 token 传给 server 也行？

答：server 会有一套校验机制，校验这个 token 是否合法。

2、怎么不像 session 那样根据 sessionId 找到 userid 呢，这样的话怎么知道是哪个用户？

答：token 本身携带 uid 信息

第一个问题，如何校验 token 呢？我们可以借鉴 HTTPS 的签名机制来校验。先来看 jwt token 的组成部分

 1/2    1 2 下一页 尾页