文章目录

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

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复制）。

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

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

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

又进化出了一版本 TOKEN

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

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

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

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

数据签名

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

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

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

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

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

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就随之而来

主要流程如下：

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

优点

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

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

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

# 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）

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

方式二：基于应用层封装 HttpServletRequest 请求对象，包装成自己的 RequestWrapper 对象，从而让实现调用 HttpServletRequest#getSession() 方法时，获得读写外部存储器的 SessionWrapper 对象。比如 Spring Session解决方案

使用Spring session框架提供的会话管理工具，这个方案既不依赖tomcat容器，又不需要改动代码，是目前非常完美的session共享解决方案。

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

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

【网络通信与信息安全】之深入分析Token、session和cookie的使用场景和区别
在 Web 开发领域,相信大家对于 Cookie 和 Session 都很熟悉,Cookie 和 Session 都是会话保持技术的解决方案.随着技术的发展,Token 机制出现在我们面前,不过很多开 ...
session,cookie和token,以及负载均衡
参考 session,cookie,token 负载均衡的session解决办法转载于:https://www.cnblogs.com/Jamie1032797633/p/11201972.html
Cookie、token、session的区别是什么？
背景: 最近在总结一些容易理解混淆的概念,之前面试的时候提到过,我觉得也说不清楚,这两天项目做接口测试发现用的cookie而不是之前的token,于是总结一下,便于以后用到的时候再阅读以及分享给需要的 ...
客户端与服务器端的认证方式（cookie，token，session）
目录 ■问题起因方式1:cookie ●cookie保存位置 ●cookie文件的形式 ●cookie的内容 (时代在发展) 方式2:session ■cookie・session ■查看cooki ...
Session/Cookie/Token还傻傻分不清？
Cookie.Session.Token 傻傻分不清 Session/Cookie/Token 还傻傻分不清? 相信项目中用JWT Token的应该不在少数,但是发现网上很多文章对 token 的介绍 ...
java session 永不过期_Java Web Application使Session永不失效(利用cookie隐藏登录)
在做 Web Application 时,因为 Web Project 有 session 自动失效的问题,所以如何让用户登录一次系统就能长时间运行三个月,就是个问题. 后来,看到 session 失 ...
json session cookie介绍和使用
Cookie的介绍和使用:cookie的作用是当用户通过http访问一个服务器时,这个服务器会将一些key/value键值对返回给客户端浏览器,并给这些数据加上限制条件,在条件符合时用户下次访问服务器 ...
spring-web项目采用token认证session创建过多导致OOM
本文介绍关于session过多,分问题.解决方案.分析在另写文章. 问题:spring-boot微服务互相调用时,采用的是spring-security来认证,比如A服务调用B服务用feign调用方式 ...
Token和Session有什么区别，面试官满意的答案
活动地址:CSDN21天学习挑战赛 token 和 Session 的问题在面试中几乎是必问的,不管是开发也好,还是测试也好,本文通过图形说明它们的原理以及弊端,遇到面试官不慌. 什么是 token ...

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