前端开发登录状态的保持，主要有两种方法：cookie+session 和 token技术
登录状态保持，起源于http的无状态，无记忆
1. 最早的时候，web的作用就是网页的浏览。 服务器只用提供简单的网页浏览器操作即可，不用记住刚刚谁发了请求，更没有登录，注册之类的操作
2. http设计之初就是无状态的
3. http无状态： http不会记住每一次的请求 就跟公交车司机不会记住乘客一样
4. 这段时间很嗨皮，业务逻辑非常简单。
cookie+session实现登录状态保持
1.随着交互型的网页的兴起，在线购物网站，需要登录的网站变得越来越多。但是http是无状态的
2.通过cookie+session实现状态保持
3.服务端登录的时候，给分配一个session用于存储数据，同时将sessionID返回给浏览器
4.浏览器通过cookie把sessionID存储起来，下次访问时携带上
5.服务端就可以通过sessionID来确定用户是否登录【喝咖啡的例子】
cookie+session实现状态保持的缺点
1.通过cookie+sesion技术实现了状态的保持，大家都很嗨皮
2.服务端不嗨皮了，原因如下：
-每个人登录都需要在服务端开辟一块空间来信息，如果访问的人越来越多了，该怎么办？
-浪费了大量的内存，对于服务器来说是一个很大的开销。
-手机端很多浏览器不支持cookie或者是禁用cookie
-如果要集群了，会很麻烦
集群+session持久化
1.因为需要访问的用户越来越多，一台服务器扛不住压力了
2.那就准备2台，3台，甚至是更多的服务器进行服务
3.问题：如果小明的请求第一次访问了A服务器，下一次访问了B服务器怎么办？
4.可以通过session共享解决，也就是在每一台服务器中都共享所有的用户信息，这样就占用了更多的服务器内存
5.通过数据持久化解决，使用缓存（redis/Memcached）,将所有的session存储到数据库中，所有的session都统一去数据库中进行查找
6.服务端也嗨皮了，但是数据库服务器崩了咋办？？？
登录状态保持-token技术
token的基本介绍
1.想想，我们为什么要存储session呢，浪费大量的内存，要是不存该有多好啊，但是不存储session，我怎么验证合法用户？关键点就在于验证服务端不存储任何的数据，我还能验证你的真实身份
2.新的想法产生了：当小明登录系统的时候，根据小明的用户名生成一个token(令牌)，把令牌交给小明，服务端不做任何存储。下次小明登录时，小明带上token进行访问，服务端对token进行校验，当然这个令牌必须是通过一定的算法进行严格加密的，只有服务器才能解析校验
3.校验token比存储session省事多了
token的优势
1. token无状态，服务端不用存储token，服务端只需要签发和校验token即可。
2. 集群：token是无状态，集群的时候，算法一致，无论访问哪台服务器，都是一样的
3. 性能： 解析token效率比查询数据库高的多
4. 跨站点：只要服务端算法一致，token就可以夸站点登录
5. 移动端：在移动端开发中，使用cookie非常麻烦，使用token验证非常常见
token的使用
1.客户端收到服务器返回的JWT，可以储存在Cookie里面，也可以储存在localStorage。
2.此后，客户端每次与服务器通信，都要带上这个JWT。你可以把它放在Cookie里面自动发送，但是这样不能跨域，所以更好的做法是放在HTTP请求的头信息Authorization字段里面。
