Spring Session - Cookie VS Session VS Token 以及 Session不一致问题的N种解决方案

爱被打了一巴掌 2022-10-29 14:29 39阅读 0赞

### 文章目录 ###

*  Cookie VS Session VS Token
 *   *  History
     *  Cookie
     *  Session
     *  Token
 *  Session不一致问题
 *  Session不一致解决方案
 *   *  nginx session sticky
     *  Tomcat session 复制
     *  Session 外部化存储

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70]

--------------------

# Cookie VS Session VS Token #

我们在学习Spring Session 之前， 先聊聊 几种主流的会话方式以及发展历史

--------------------

## History ##

众所周知 HTTP请求是无状态的， 随着交互式Web应用的兴起，要管理会话，那必须记住哪些人登录了系统， 怎么办呢？

大家就想着颁发一个会话标识(session id), 实际上呢就是一个随机字符串，每个人收到的都不一样 。

这样每次向系统发起HTTP请求的时候，把这个字符串给一并捎过来， 这样服务端就可以很好地区分了。

举个例子试想一下， 两个节点组成了一个集群， 用户一通过节点A登录了系统， 那session id会保存在节点A上，如果用户一的下一次请求被转发到节点B怎么办？节点B可没有用户一的 session id 即相当于用户一没有登录呀~

当然了可以通过一些办法解决，比如ng上开启 session sticky ， 就是让用户一的请求一直粘连在节点A上 。 但是节点A挂掉了， 还得转到节点B去。 那就是session 的复制呗， 把session id 在两个节点之间同步（tomcat之间进行session复制） 。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 1]

随着用户数据量的激增 ， 每个人只需要保存自己的session id，而服务器要保存所有人的session id ， **对服务器说是一个巨大的开销 ， 严重的限制了服务器扩展能力 。**

后来呢，大家说把session放到外面来管理吧 ，这样就不用复制来复制去了 ，数据量大了还影响带宽。。。。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 2]

艾玛 ，你这个存储session的，还是个单点呀，那我还得确保你这个节点高可用啊。。。。服务端想想说 ，我不管这些破session行不行 ，让你客户端去管你自己的这些数据呀？

--------------------

**又进化出了一版本 TOKEN**

可是如果不保存这些session id , 怎么验证客户端发给服务端的session id 的确是服务端生成的呢？ 如果不去验证， 都不知道他们是不是合法登录的用户， 那…为所欲为了。

so , 重点来了， **服务端验证合法性**

举个例子，用户一已经登录了系统，服务端给用户一发一个令牌(token)， 里边包含了用户一的 user id等信息， 下一次用户已再次通过Http 请求访问服务端的时候， 把这个token 通过Http header 带过来 就可以了。

等等， 那别人伪造怎么办？ 怎么让别人伪造不了呢？

**数据签名**

比如哈， 管理端用HMAC-SHA256 算法，加上一个只有管理端自己才知道的密钥， 对数据做一个签名， 把这个签名和数据一起作为token ， 由于密钥别人不知道， 就无法伪造token了。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 3]

token 管理端 不保存， 当用户把这个token 发过来的时候，管理端再用同样的HMAC-SHA256 算法和同样的密钥，对数据再计算一次签名， 和token 中的签名做个比较， 如果相同， 这认为已经登录过了，并且可以直接取到存储在其中的的user id , 如果不相同， 数据部分肯定被人篡改过， 即为没有认证。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 4]

Token 中的数据是明文保存的（虽然会用Base64做下编码， 但不是加密）， 还是可以被别人看到的， 所以Token中不能在其中保存像密码等敏感信息。

当然， 如果一个人的token 被别人偷走了，那其他用户使用该token登录 也会被认为合法用户， 这其实和一个人的session id 被别人偷走道理是一样的 。 **只能防止篡改，不能防止泄露**

这样一来， 管理端就不保存session id 了， 只负责生成token , 然后验证token ，消除了session id 这个负担， 那么管理端的集群现在可以轻松地做水平扩展， 用户访问量激增， 加节点…  
![在这里插入图片描述][20210215221746962.png]

--------------------

## Cookie ##

cookie 指的是浏览器里面能永久存储的一种数据，仅仅是浏览器实现的一种数据存储功能。

cookie由服务器生成，发送给浏览器，浏览器把cookie以kv形式保存到某个目录下的文本文件内，下一次请求同一网站时会把该cookie发送给服务器。

由于cookie是存在客户端上的，所以浏览器加入了一些限制确保cookie不会被恶意使用，同时不会占据太多磁盘空间，所以每个域的cookie数量是有限的。

--------------------

## Session ##

session 简单来说就是服务器给每个客户端分配的“身份标识”，然后客户端每次向服务器发请求的时候，都带上这个“身份标识”，服务器就知道这个请求来自于谁了。

至于客户端怎么保存这个“身份标识”，可以有很多种方式，对于浏览器客户端，大家都默认采用 cookie 的方式。

服务器使用session把用户的信息临时保存在了服务器上，用户退出后session会被销毁。这种用户信息存储方式相对cookie来说更安全.

--------------------

## Token ##

为什么非要用token呢？

我们都是知道HTTP协议是无状态的，这种无状态意味着程序需要验证每一次请求，从而辨别客户端的身份。

在这之前，程序都是通过在服务端存储的登录信息来辨别请求的。这种方式一般都是通过存储Session来完成。

随着Web，应用程序以及移动端的兴起，这种验证的方式逐渐暴露出了问题。尤其是在可扩展性方面。

主要存在一下几个问题

*  Seesion： 每次认证用户发起请求时，服务器需要去创建一个记录来存储信息。当越来越多的用户发请求时，内存的开销也会不断增加。
 *  **可扩展性： 在服务端的内存中使用Seesion存储登录信息，伴随而来的是可扩展性问题。**
 *  CORS(跨域资源共享)： 当我们需要让数据跨多台移动设备上使用时，跨域资源的共享会是一个让人头疼的问题。在使用Ajax抓取另一个域的资源，就可以会出现禁止请求的情况。
 *  CSRF(跨站请求伪造)： 用户在访问银行网站时，他们很容易受到跨站请求伪造的攻击，并且能够被利用其访问其他的网站。

在这些问题中，可扩展行是最突出的。因此有必要去寻求一种更有行之有效的方法， TOKEN就随之而来

主要流程如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 5]

1.  用户通过用户名和密码发送请求。
2.  程序验证。
3.  程序返回一个签名的token 给客户端。
4.  客户端储存token,并且每次用于每次发送请求。
5.  服务端验证token并返回数据。

--------------------

优点

*  无状态、可扩展
 *  支持移动设备
 *  跨程序调用
 *  安全

--------------------

好了，扯皮结束了，我们先关注分布式环境下Session的解决方案， 至于Token我会结合JWT来分享 。

![在这里插入图片描述][20210215225907535.png]

--------------------

# Session不一致问题 #

假设我们的应用部署在Tomcat中

【单个节点的tomcat 】

浏览器在第一次访问服务器Tomcat1时，发现请求的 Cookie 中不存在 sessionid ，所以创建一个 sessionid 为 xxxxxxx 的 Session ，同时将该 sessionid 写回给浏览器的 Cookie 中。

浏览器在下一次访问 Web 服务器 时，Tomcat1会发现请求的 Cookie 中已存在 sessionid 为 xxxxxxx ，则直接获得 xxxxxxx 对应的 Session 。

【多个节点的tomcat 】

在多台 Tomcat 的情况下，采用 Nginx 做负载均衡。

接上面的请求，继续 浏览器又发起一次请求访问 Web 服务器，Nginx 负载均衡转发请求到 Tomcat2 上。Tomcat2 会发现请求的 Cookie 中已存在 sessionid 为 X ，则直接获得 xxxxxxx 对应的 Session 。结果 Tomcat2 在JVM中找不到 xxxxxxx 对应的 Session

这样就会出现 Session 不一致的问题 。

--------------------

# Session不一致解决方案 #

## nginx session sticky ##

使用 Nginx 实现会话黏连，将相同 sessionid 的浏览器所发起的请求，转发到同一台服务器。这样，就不会存在多个 Web 服务器创建多个 Session 的情况，也就不会发生 Session 不一致的问题。

**不过，这种方式目前基本不被采用。 如果一台服务器重启，那么会导致转发到这个服务器上的 Session 全部丢失。**

主要是安装 nginx-sticky-module

下载地址： [https://bitbucket.org/nginx-goodies/nginx-sticky-module-ng/get/master.tar.gz][https_bitbucket.org_nginx-goodies_nginx-sticky-module-ng_get_master.tar.gz]

# tar zxf nginx-goodies-nginx-sticky-module-ng-1e96371de59f.tar.gz
    # mv nginx-goodies-nginx-sticky-module-ng-1e96371de59f nginx-sticky
    # tar zxf nginx-1.6.1.tar.gz
    # cd nginx-1.6.1
    # ./configure --prefix=/app/nginx --with-http_gzip_static_module --with-http_flv_module --with-http_dav_module --with-http_stub_status_module --with-http_realip_module --add-module=/app/soft/nginx-sticky/
    # make
    # cd /app/nginx/sbin
    # mv nginx nginx.old
    # cp /app/soft/nginx-1.6.1/objs/nginx ./
    # cd -
    # make upgrade

配置

upstream artisan{ 
    　　　　sticky;
    　　　　server 172.168.15.11:8001;
    　　　　server 172.168.15.12:8002;
    　　　　....
    }
    
    server { 
            listen       80;
            server_name  localhost;
            .....
    
            location ~/xxxxx/.*\.jsp|do|htm$ { 
                    proxy_pass      http://artisan;
                    .....
            } 
    }

不用第三方的模块包的话，那就使用ip\_hash的策略。这种方案的局限性是ip不能变。

--------------------

## Tomcat session 复制 ##

Web 服务器之间，进行 Session 复制同步。仅仅适用于实现 Session 复制的 Web 容器，例如 Tomcat

**不过，这种方式目前基本也不被采用。 session数据量大的时候，复制效率低，占用带宽等等弊端。**

--------------------

## Session 外部化存储 ##

Session 外部化存储 即将 Session 存储外部化，持久化到 MySQL、Redis、MongoDB 等中。这样一搞Tomcat 就可以无状态化，专注作为Web 服务 ，扩容也变得容易。

主要由两种方式

*  方式一：基于 Tomcat、Jetty 等 Web 容器自带的拓展，使用读取外部存储器的 Session 管理器 ，使用的较少，这里不做讨论

> 基于Tomcat的tomcat-redis-session-manager插件，基于Jetty的jetty-session-redis插件、memcached-session-manager插件;

> 好处是对项目来说是透明的，无需改动代码，但是由于过于依赖容器，一旦容器升级或者更换意味着又得重新配置；其实底层是，复制session到其它服务器，所以会有一定的延迟，也不能部署太多的服务器。

网上找了两篇文章，感兴趣的可以参考下

[Tomcat会话管理器（Tomcat Session Manager）][Tomcat_Tomcat Session Manager]

[Jetty集群配置Session存储到MySQL、MongoDB][Jetty_Session_MySQL_MongoDB]

--------------------

*  方式二：基于应用层封装 HttpServletRequest 请求对象，包装成自己的 RequestWrapper 对象，从而让实现调用 HttpServletRequest\#getSession() 方法时，获得读写外部存储器的 SessionWrapper 对象 。 比如 Spring Session解决方案
    
    使用Spring session框架提供的会话管理工具， 这个方案**既不依赖tomcat容器，又不需要改动代码**， 是目前非常完美的session共享解决方案。

我们这里只讨论 Spring Session提供的解决方案 ，支持外部存储包括 Redis . 数据库、Hazelcast、MongoDB等

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 6]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 7]

--------------------

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70]: /images/20221024/fe016d168886451ba2cdb4d81613a344.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 1]: /images/20221024/02d55f9ce30945f8ac22601b0918f39d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 2]: /images/20221024/7d2077e7a0d146139f2378317a3d265c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 3]: /images/20221024/bcf52d7398824e07b691ccd97c9e4e96.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 4]: /images/20221024/a6425afb099f48febc2e1919417910cc.png
[20210215221746962.png]: /images/20221024/4c628c91cce248e2954a5f71f45906aa.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 5]: /images/20221024/f52f2598dfb4494fbcf05a5b669fe0f4.png
[20210215225907535.png]: /images/20221024/126b15b209dc429b841b6eeeb7665663.png
[https_bitbucket.org_nginx-goodies_nginx-sticky-module-ng_get_master.tar.gz]: https://bitbucket.org/nginx-goodies/nginx-sticky-module-ng/get/master.tar.gz
[Tomcat_Tomcat Session Manager]: https://github.com/redisson/redisson/wiki/14.-%E7%AC%AC%E4%B8%89%E6%96%B9%E6%A1%86%E6%9E%B6%E6%95%B4%E5%90%88#146-spring-session%E4%BC%9A%E8%AF%9D%E7%AE%A1%E7%90%86%E5%99%A8
[Jetty_Session_MySQL_MongoDB]: https://blog.csdn.net/xiao__gui/article/details/43271509
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 6]: /images/20221024/a77308f0d7d44ed891d0ad7dba979934.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 7]: /images/20221024/928a28fb6c30405a89380310b80ee66e.png