登录
我们知道,HTTP
是无状态的。也就是说,HTTP
请求方和响应方间无法维护状态,都是一次性的,单一的,它不知道上一次请求都发生了什么。在开发中,一个应用避免不了登录。在登录中我们常用到的就是 token
和 session
鉴别。下面我们简单了解一下,更加理解这里面的细节。
服务端 session
session
又叫服务端的 cookie
。广义上来看就是保存在了服务端。而 cookie
是在用户端来保存的。
流程:
-
浏览器发送账号密码,服务端查询校验
-
服务端保存用户登录状态, 即
session
。 发送一个对应session
的id
, 即sessionId
-
通过登录接口返回,把
sessionId
种到cookie
上 -
此后
sessionId
随着cookie
。进行携带, 并比较。
因为由服务端保存,这就又带来了一些问题。
-
需要维持很多用户,服务器是有压力的
-
服务端并不在只有一台服务器,如何在多台服务器之间进行共享状态
第一个问题的解决就下面的 token
,就是解决方法。第二个问题:
-
把
session
集中存储。如果我们用独立的Redis
或普通数据库,就可以把session
都存到一个数据库里。这样就能共享了。 -
让相同
IP
的请求在负载均衡时都打到同一台机器上。以nginx
为例,可以配置ip_hash
来实现。但这种方式就违背了负载均衡。 而nginx
负载均衡的特性。是它的一大特色,也是受欢迎的原因之一。
用户端 token
为了解决上面提到的第一个问题。采用 token
是一种方式。由原来的 服务端保存转为了用户端保存。减小了服务器压力。
流程:
-
用户登录,服务端校验账号密码,获得用户信息
-
把用户信息、
token
返回给用户浏览器 -
用户端进行管理保存,此后进行携带
token
。
这里由用户端进行保存,方式就有很多了, cookie
, localstroage
, sessionStroage
。
延展一下:token
里通常包含 Access Token
和 Refresh Token
。业务接口用来鉴权使用 Access token
。越是权限敏感的业务,我们越希望 Access token
有效期足够短,以避免被盗用。但这又不够友好,所以,使用 Refresh token
, 来专门生成 Access Token
。它的有效期长一些,在 Access Token
失效之后,用户端拿着 Refresh Token
去请求服务端生成一个新的 Access Token
。 但如果两个 token
均失效,则需要重新去登录了。
看到最后了 欢迎访问我的 blog , 里面有你想要的面试信息,学习指引 大厂招聘信息。同时你有什么好的信息,可以给我 pr
。