摘要：客户端发起非登录请求时，服务端通过中的找到对应的来知道此次请求是谁发出的。数量随着登录用户的增多而增多，存储会增加很多。
还记得在上家公司做全干工程师的时候，基本从页面写到运维，当时做登录这块的时候，被session、cookie、token各种概念差点整蒙圈了，上网查询相关概念，发现很多人都是类似的疑惑，比如：来了字节跳动之后，前端很少接触HTTP请求之后的事情，而且登录相关的SDK封装的很好，所以这篇文章就简单的学习记录一下。
首先这是因为HTTP是无状态的协议，所谓无状态就是在两次请求之间服务器并不会保存任何的数据，相当于你和一个人说一句话之后他就把你忘掉了。所以，登录就是用某种方法让服务器在多次请求之间能够识别出你，而不是每次发请求都得带上用户名密码这样的识别身份的信息。
从登录成功到登出的这个过程，服务器一直维护了一个可以识别出用户信息的数据结构，广义上来说，这个过程就叫做session，也就是保持了一个会话。
忽然想到一点，看了网上很多问题，我觉得大家应该区分两个概念：广义的session和狭义的session
广义的session：广义的session就是从登录成功到登出的过程，在这个过程中客户端和服务器端维持了保持登录的状态，至于具体怎么维持住这种登录的状态，没有要求。
狭义的session：狭义的session就是登录成功后，服务器端存储了一些必须的用户信息，这部分存在服务器端的用户信息就叫做session，也就是接下来要说的第一种登录的实现方式。
服务器session+客户端sessionId先用图来看：
详细说的说一下，这里面主要是这么几个过程：
客户端带着用户名和密码去访问 /login 接口，服务器端收到后校验用户名和密码，校验正确就会在服务器端存储一个sessionId和session的映射关系
服务器端返回response，并且将sessionId以set-cookie的方式种在客户端，这样一来，sessionId就存在了客户端。这里要注意的是，将sessionId存在cookie并不是一种强制的方案，而是大家一般都这么做，而且发请求的时候符合domain和path的时候，会自动带上cookie，省去了手动塞的过程。
客户端发起非登录请求时，服务端通过cookie中的sessionId找到对应的session来知道此次请求是谁发出的。
前面说到sessionId的方式本质是把用户状态信息维护在server端，token的方式就是把用户的状态信息加密成一串token传给前端，然后每次发请求时把token带上，传回给服务器端；服务器端收到请求之后，解析token并且验证相关信息；
所以跟第一种登录方式最本质的区别是：通过解析token的计算时间换取了session的存储空间
业界通用的加密方式是jwt（json web token），jwt的具体格式如图：
简单的介绍一下jwt，它主要由3部分组成：
header 头部
{
"alg": "HS256",
"typ": "JWT"
}
payload 负载
{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022,
"exp": 1555341649998
}
signature 签名header里面描述加密算法和token的类型，类型一般都是JWT；
payload里面放的是用户的信息，也就是第一种登录方式中需要维护在服务器端session中的信息；
signature是对前两部分的签名，也可以理解为加密；实现需要一个密钥（secret），这个secret只有服务器才知道，然后使用header里面的算法按照如下方法来加密：
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)总之，最后的 jwt = base64url(header) + "." + base64url(payload) + "." + signature
jwt可以放在response中返回，也可以放在cookie中返回，这都是具体的返回方式，并不重要。
客户端发起请求时，官方推荐放在HTTP header中：
Authorization: Bearer
这样子确实也可以解决cookie跨域的问题，不过具体放在哪儿还是根据业务场景来定，并没有一定之规。
session方式由于会在服务器端维护session信息，单机还好说，如果是多机的话，服务器之间需要同步session信息，服务横向扩展不方便。
session数量随着登录用户的增多而增多，存储会增加很多。
session+cookie里面存sessionId的方式可能会有csrf攻击的问题，常见的方式是使用csrf_token来解决
jwt的过期时间需要结合业务做设置，而且jwt一旦派发出去，后端无法强行使其作废
理清概念，一身轻松
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/7311.html
摘要：我拖拖拖拖放基础篇前端掘金不要搞错，本文不是讲如何拖地的。结构说明前端应该从哪些方面来优化网站前端掘金不知道是哪位大牛的文章，转过来回答。 我拖拖拖 --H5 拖放 API 基础篇 - 前端 - 掘金不要搞错，本文不是讲如何拖地的。看过《javascript精粹》朋友应该知道，他实现拖放的过程比较复杂，现在时代不同了，我们用H5的新的拖放API就能非常方便的实现拖放效果了。最近在园子见...
摘要：在使用非对称加密算法进行签名的时候，还可以用于验证的发件人是否与中申明的发件人是同一个人。如果没有用非对称加密算法的话，把复制之后直接可以去官网在线解析。 这篇博客主要是简单介绍了一下什么是JWT，以及如何在Spring Boot项目中使用JWT(JSON Web Token)。 1.关于JWT 1.1 什么是JWT 老生常谈的开头，我们要用这样一种工具，首先得知道以下几个问题。 这...
摘要：探究系统登录验证码的实现后端掘金验证码生成类手把手教程后端博客系统第一章掘金转眼间时间就从月份到现在的十一月份了。提供了与标准不同的工作方式我的后端书架后端掘金我的后端书架月前本书架主要针对后端开发与架构。 Spring Boot干货系列总纲 | 掘金技术征文 - 掘金原本地址：Spring Boot干货系列总纲博客地址：http://tengj.top/ 前言 博主16年认识Spin...
摘要：搭建简单登录注册还是我又来了近来突然对数据库和后台有点感兴趣就开始了漫长的学习之路想想自己只是一个前端只会斯科瑞普所以就开始看看着看着突然发现和更配哦遂就开了我的之路由于我的表达能力有限下面的文章可能写的不是那么详细有看不懂的可以去我上看源 nodejs+mongodb搭建简单登录注册 biu!biu!biu!还是我又来了!!! 近来突然对数据库和后台有点感兴趣,就开始了漫长的学习之...
阅读 448·2021-10-09 09:57
阅读 444·2019-08-29 18:39
阅读 792·2019-08-29 12:27
阅读 3010·2019-08-26 11:38
阅读 2636·2019-08-26 11:37
阅读 1268·2019-08-26 10:59
阅读 1347·2019-08-26 10:58
阅读 966·2019-08-26 10:48
