1、Cookie
如图所示，左边是用户端（浏览器），右边是服务端（服务器）。
如果想实现一个登录操作，那么我们可以在浏览器像服务器发送一个HTTP请求，通过对比账号和密码，服务器对比后正确的话，会在服务器设置cookie的值，他是一个key-value的一种结构，通过set-cookie发送给浏览器，浏览器接收到set-cookie的话，会直接将cookie里的值设置成浏览器的cookie里。并且cookie里的东西信息是直接可以读取的，这样可能会暴露给外部，并且如果设置一个无需密码的登录，想通过浏览器每次访问的时候携带cookie就可以免去登录，这种时候如果浏览器关闭就找不到这个cookie了。
2、session
这个时候就会引出session，它是在服务器创建，创建后将sessionId和cookie过期时间设置到set-cookie里，发给浏览器，浏览器读取到cookie会自动设置到浏览器的header上的，每次访问都会携带这个cookie，根据cookie里的sessionId就能找到服务器的session，可以request.session获取对应的session，可以通过session设置一些值之类的，登录的时候获取这些值来判断是否已经登录。但是在多服务器端的过程中，如果在其中一个服务器登录后，这个服务器宕机，于是连接到下一台服务器，此时该服务器并没有存session，这时候就不太好实现，可以通过redis同步每个服务器的session，但是这样redis服务器如果坏了那么还是有可能出现问题，出现问题的地方更多了，并且多出了一些代码，个人认为对健壮性不太好。
3.token
于是引出了token，这是一种无状态的加密的字符序列。我们通常使用的是一种规范的TOKEN叫做JWT，他是JSON WEB TOKEN
jwt分为三部分，header，payload，signature
header部分是声明用什么算法来生成签名，以及生成的格式的token类型
payload部分存的特定的数据 比如有效期
signature部分存的是 header和payload经过base64的编码相加再加上自己专门设置的私钥最后，最后通过header设置的算法把签名算出来
流程是这样的，如果登陆成功，后端会根据设置生成对应的token发送HTTP请求给前端，如果想获取数据就将payload通过base64解码就可以了，如果不需要就不用，之后前端将这个token数据存放到一个前后端都约定好的一个请求头的字段中，每次访问都会写带这个字段以及对应的jwt进行访问，如果后端进行校验是否登录，就会根据header中的算法来验证signature是否正确，如果这个token正确，说明是登录过的。
