登录

我们知道，HTTP 是无状态的。也就是说，HTTP 请求方和响应方间无法维护状态，都是一次性的，单一的，它不知道上一次请求都发生了什么。在开发中，一个应用避免不了登录。在登录中我们常用到的就是 token 和 session 鉴别。下面我们简单了解一下，更加理解这里面的细节。

服务端 session

session 又叫服务端的 cookie。广义上来看就是保存在了服务端。而 cookie 是在用户端来保存的。

流程：

1. 浏览器发送账号密码，服务端查询校验

2. 服务端保存用户登录状态, 即 session。 发送一个对应 session 的 id, 即 sessionId

3. 通过登录接口返回，把 sessionId 种到 cookie 上

4. 此后 sessionId 随着 cookie。进行携带, 并比较。

因为由服务端保存，这就又带来了一些问题。

• 需要维持很多用户，服务器是有压力的

• 服务端并不在只有一台服务器，如何在多台服务器之间进行共享状态

第一个问题的解决就下面的 token ，就是解决方法。第二个问题：

1. 把 session 集中存储。如果我们用独立的 Redis 或普通数据库，就可以把 session 都存到一个数据库里。这样就能共享了。

2. 让相同 IP 的请求在负载均衡时都打到同一台机器上。以 nginx 为例，可以配置 ip_hash 来实现。但这种方式就违背了负载均衡。 而 nginx 负载均衡的特性。是它的一大特色，也是受欢迎的原因之一。

用户端 token

为了解决上面提到的第一个问题。采用 token 是一种方式。由原来的 服务端保存转为了用户端保存。减小了服务器压力。

流程：

1. 用户登录，服务端校验账号密码，获得用户信息

2. 把用户信息、token 返回给用户浏览器

3. 用户端进行管理保存，此后进行携带 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。