对于http的无状态性质，现阶段有何种解决方案？

1、http协议有一个特性就是无状态，何为无状态。就是上一次的请求对这次的请求没有任何影响，服务端也不会对客户端上一次的请求进行任何记录处理。

2、http协议的无状态性带来的问题：用户登录后，切换到其他界面，进行操作，服务器端是无法判断是哪个用户登录的。 每次进行页面跳转的时候，得重新登录。

3、解决方案

3.1 token

待整理： 参考项目中的解决办法

每次用户调用登录接口的时候，就会根据UUID生成一个token, 然后把token和对应的UserInfo(用户信息)存入到redis中去，String类型,key是token，value是对应的UserInfo信息。并且最终会把生成的token返回给前端。下次请求其他操作的时候，会在请求的head中包含token信息。String token = UUID.randomUUID().toString();

待该用户请求其他界面操作的时候，首先拦截器会对请求进行拦截，如果不在白名单中的url请求，会先从请求的头部中获取到token值，然后根据token去redis缓存中获取UserInfo，如果不存在相应的UserInfo, 那么表明用户没有登录。直接返回请重新登录。否则就处理相关的请求。

在用户退出登录的时候，会根据退出登录中的token，做删除操作，删除redis中的用户信息，以及其他的信息。
待下次登录的时候，又会重新生成。

http无状态
页面之间的跳转是原生进行的，不同的操作对应不同的接口请求。如果

登录的时候，在服务器端使用uuid随机生成一个token

String token = UUID.randomUUID().toString();

登录 – 验证用户名和密码的正确性

正确的，就跳转到指定的界面。进行指定的操作。如果错误就重新登录。

现在是如果验证通过，还要根据um账号，获取用户的相关信息，并且返回给前端。在详细的用户信息中体现出来。

一个账号和密码，不能在不同的手机上进行同时登录。会被踢掉。

token(第一次登录)

token是一次登录的周期，从用户登录被生成到最后退出被删除。并不是永久存在，退出后删除，重新登录后又会有新的生成。
主要是确保，登录后状态的

“pa-market-token”:101010910 , token
“p_i“:”” , token
token UserInfo

            //设置UserInfoExt
            UserTokenUtil.setUserInfoExt(
                    new UserInfoExt(dto.getDeviceId(), dto.getOsType(), user)
                    , token, valOpsStr);

            token --- userInfo之间的关系
            account --- token之间的关系

        这种映射关系，确保同一个用户只能同时登录同一个设备下有作用。  
        //根据登录账号获取存在本地token，和传过来的token作比较，如果不一致则认为该token是在别的机器登录并且生成的
        String localToken = (String) valOpsStr.get(UserTokenUtil.TOKEN_HEADER + dto.getAccount());
        //将那个用户下线
        if (localToken != null && !localToken.equals(UserTokenUtil.getTokenByRequest(request))) {
            valOpsStr.getOperations().delete(localToken);
        }

对于每次请求头中都会保存token这个值，那么第一次登录的时候，token只是多少？
每次登录请求的时候，请求头中是否包含token值？

加上设备号和操作系统类型，方便后期推送使用，跟这次用户登录没有关系

一个账号只能登录一个设备。同时登录的时候，会被挤下去。

3.2 cookie

Cookie会根据从服务器端发送的响应报文内的一个叫做Set-Cookie的首部字段信息，通知客户端保存Cookie，当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入Cookie值后发送出去。也就是Cookie是服务器生成的，但是发送给客户端，并且由客户端来保存。每次请求加上Cookie就行了。服务器端发现客户端发送过来的Cookie后，会去检查究竟是从哪一个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前的状态信息。

Cookie请求的处理流程：

注意sid其实就是SessionId。 也就是Session机制是依靠Cookie来实现的。

3.3 Session

Session也是一种很好的解决http协议无状态的方案。典型的场景比如购物车, 当你点击下单按钮的时候，由于Http协议无状态，并不知道哪个用户登录，所以需要某个机制来判断是哪个用户登录的。

第一次创建Session的时候，服务端会在HTTP协议中告诉客户端，需要在 Cookie 里面记录一个Session ID，以后每次请求把这个会话ID发送到服务器，我就知道你是谁了。

Session 和 Cookie的区别 ：

1. 由于HTTP协议是无状态的协议，所以服务端需要记录用户的状态时，就需要用某种机制来识具体的用户，这个机制就是Session.典型的场景比如购物车，当你点击下单按钮时，由于HTTP协议无状态，所以并不知道是哪个用户操作的，所以服务端要为特定的用户创建了特定的Session，用用于标识这个用户，并且跟踪用户，这样才知道购物车里面有几本书。这个Session是保存在服务端的，有一个唯一标识。在服务端保存Session的方法很多，内存、数据库、文件都有。集群的时候也要考虑Session的转移，在大型的网站，一般会有专门的Session服务器集群，用来保存用户会话，这个时候 Session 信息都是放在内存的，使用一些缓存服务比如Memcached之类的来放 Session。2. 思考一下服务端如何识别特定的客户？这个时候Cookie就登场了。每次HTTP请求的时候，客户端都会发送相应的Cookie信息到服务端。实际上大多数的应用都是用 Cookie 来实现Session跟踪的，第一次创建Session的时候，服务端会在HTTP协议中告诉客户端，需要在 Cookie 里面记录一个Session ID，以后每次请求把这个会话ID发送到服务器，我就知道你是谁了。有人问，如果客户端的浏览器禁用了 Cookie 怎么办？一般这种情况下，会使用一种叫做URL重写的技术来进行会话跟踪，即每次HTTP交互，URL后面都会被附加上一个诸如 sid=xxxxx 这样的参数，服务端据此来识别用户。3. Cookie其实还可以用在一些方便用户的场景下，设想你某次登陆过一个网站，下次登录的时候不想再次输入账号了，怎么办？这个信息可以写到Cookie里面，访问网站的时候，网站页面的脚本可以读取这个信息，就自动帮你把用户名给填了，能够方便一下用户。这也是Cookie名称的由来，给用户的一点甜头。所以，总结一下：Session是在服务端保存的一个数据结构，用来跟踪用户的状态，这个数据可以保存在集群、数据库、文件中；Cookie是客户端保存用户信息的一种机制，用来记录用户的一些信息，也是实现Session的一种方式。

扩展： 上次康康说道现阶段业界有多少个登录的方式呢？

1、常规的用户名和密码登录
2、手机号+短信验证码登录
3、第三方授权登录（微信、qq、微博等授权登录）
4、长登录（典型的就是支付宝，支付宝登录以后，如果不是自己手动退出，不存在再次登录的情况？ 好奇后面的技术方案，一直保持链接状态? 那得占据多大的链接池资源）

在知鸟APP的登录就是包含了这四中登录的APP。