1、Session,白话来讲就是用来区分用户的身份，其实，在我们实际应用系统中，如果我们想查看某个网站或系统的信息，比如我们想查询一下当前火车票还有多少张，那么我就可以直接访问网站去查询我们需要的信息，无需进行登录，这时候其实服务器端也没必要去记住是哪个用户查询的，这时候session的意义就不大了。但是如果必须要求服务器端记住用户的信息，那么就必须把当前的用户信息保存起来，比如，我们在买票时，就必须要登录售票系统才能买票，因为服务器端必须要记住到底是谁买的票，便于用户下次登录后要查询到之前的订单信息。有的人说了，我把谁买的票记录到数据库就行了，和session有什么关系呢？是的，这样说也是没问题的。那么，如果用户买票的时候想从一个界面跳转到另一个界面，并且还要记住用户的登录状态，那么我们该怎么办呢？这时就需要用到session了。试想一下如果没有session：用户请求数据到服务端，服务端返回接受状态信息给客户端，返回成功后连接断开（由于http的无连接性。），下次用户再请求刚刚的数据，服务器端如何快速的知道是刚刚的用户呢？（第一种方式，将每次请求的数据保存到数据库，下次访问时根据用户去查询用户的状态；第二种方式每次访问，服务器端记录用户的sessionid。返回给客户端，客户端第二次访问时，传递sessionid,这是服务器端去校验是否有这个sessionid，如果有就保持当前会话，不需要重新登录。），显然第一种方式是不可行的。增加了数据库的交互性。
2、Session的实现方式：
3、如今在weblogic中间件盛行的时代下，这些中间件已经帮我们处理好了session。处理session的主要实现是：用户登录后保持会话信息，如果会话超时，或者服务器重启，那么要求用户重新登录，这也是自动登录的由来。意思就是说如果用户已经登录过，当会话失效后，可以自动获取登录信息进行重新登录。下面，就我个人工作经验来和大家谈谈token以及实现移动端和服务端的自动登录流程和登录流程，以及实现方案。
4、用户普通登录：移动端传递用户名（account）、密码（password）、当前时间戳（timeStr）和签名（sign）到服务端，服务端首先根据sign和timestr生成的标识进行验证缓存中是否有过此标识信息，如果有则验证失败，若没有则加入缓存记录（不同时间同一用户登录肯定是无重复登录的）。验证成功后，根据用户名查询数据库是否有此用户信息，若有，则从数据库拿出账号、密码信息，并根据前端传来的时间戳生成签名（和前端生成签名的方式一致），并拿生成的签名和前端sign进行比较，如果一致则验证成功。验证成功后生成token数据保存到数据库（自动登录时使用）。实现逻辑如下图：
5、用户前端生成签名的方式：
6、一般来说自动登录的思想就是，用户首次登录成功后，将首次登录的信息保存到数据库或者缓存中,下次当某个服务需要自动登录时，则根赍铈于脏据前端传来的用户账号，时间戳，token签名，通过header方式传递给服务端，服务端通过request.getHeader();服务端首先进行签名校验，校验成功后添加缓存，并进行数据库验证，验证成功后取首次登录的token，前端传来的账号、时间戳生成签名，对比前端的签名和此签名进行对比，成功后，自动登录成功。自动登录一般都是自定义servlet。以过滤器的形式进行业务的处理，如果用户之前登录过，并且签名验证成功，则表示可以再次自动登录。具体的流程图和上述登录类似
7、那么token到底是如何生成的？所谓token就是一个用户登录密码和时间戳加密的结构的数据，前端生成token方式：
8、通俗来讲，如果后台服务重启session（通过request.getsession()）失效的情况下，一般如果用户的那些业务需要自动登录，那么就不需要用户重新登录了，直接后台系统自动处理自动登录，这就是自动登录的功能，也增加了好的用户体验。