JavaWEB 篇四 Cookie 和 Session

目录

Cookie 和 Session 的区别?

概述

Cookie 和 session 的不同点：

session 共享怎么做的（分布式如何实现 session 共享）？

问题描述

1、服务器实现的 session 复制或 session 共享，这类型的共享 session 是和服务器紧密相关的，

2、利用成熟的技术做 session 复制，比如 12306 使用的 gemfire，比如常见的内存数据库如

3、将 session 维护在客户端，很容易想到就是利用 cookie，但是客户端存在风险，数据不安全，

在单点登录中，如果 cookie 被禁用了怎么办？

单点登录的原理是后端生成一个 session ID，然后设置到 cookie，后面的所有请求浏览器都

---

4-1 、Cookie 和 Session 的区别?

概述

• Cookie是web服务器发送给浏览器的一块信息，浏览器会在本地一个文件中给每个web服务器存储cookie。以后浏览器再给特定的web服务器发送请求时，同时会发送所有为该服务存储的cookie。当用户在应用程序的web页之间跳转时，存储在Session对象中的变量将不会丢失，而是在整个用户会话中一直存在下去

Cookie 和 session 的不同点：

• 1、无论客户端做怎样的设置，session都能够正常工作。当客户端禁用cookie时将无法使用cookie

• 2、在存储的数据量方面：session能够存储任意的java对象，cookie只能够存储String类型的对象

4-2 session 共享怎么做的（分布式如何实现 session 共享）？

问题描述

• 一个用户在登录成功以后会把用户信息存储在 session 当中，这时 session 所在服务 器为 server1，那么用户在 session 失效之前如果再次使用 app，那么可能会被路由到 server2， 这时问题来了，server 没有该用户的 session，所以需要用户重新登录，这时的用户体验会非常 不好，所以我们想如何实现多台 server 之间共享 session，让用户状态得以保存

1、服务器实现的 session 复制或 session 共享，这类型的共享 session 是和服务器紧密相关的，

比如 webSphere 或 JBOSS 在搭建集群时候可以配置实现 session 复制或 session 共享，但是这 种方式有一个致命的缺点，就是不好扩展和移植，比如我们更换服务器，那么就要修改服务器配 置

2、利用成熟的技术做 session 复制，比如 12306 使用的 gemfire，比如常见的内存数据库如

redis 或 memorycache，这类方案虽然比较普适，但是严重依赖于第三方，这样当第三方服务器 出现问题的时候，那么将是应用的灾难。

3、将 session 维护在客户端，很容易想到就是利用 cookie，但是客户端存在风险，数据不安全，

而且可以存放的个增强，这里主要重写了几个 request 的方法，但是最重要的是重写了 request.getSession()，写到这里大家应该都明白为什么重写这个方法了吧，当然是为了获取 MySession， 于是这样就在 filter 中，偷偷的将原生的 request 换成 MyRequest 了，然后再将替换过的 request 传入 chan.doFilter()，这样 filter 时候的代码都使用的是 MyRequest 了，同时对业务代 码是透明的，业务代码获取 session 的方法仍然是 request.getSession（），但其实获取到的已经是 MySession 了，这样对 session 的操作已经变 成了对 redis 的操作。 这样实现的好处有两个，第一开发人员不需要对 session 共享做任何关注，session 共享对用户 是透明的；第二，filter 是可配置的，通过 filter 的方式可以将 session 共享做成一项可插拔的功 能，没有任何侵入性。 这个时候已经实现了一套可插拔的 session 共享的框架了，但是我们想到如果 redis 服务出了问 题，这时我们该怎么办呢，于是我们延续 redis 的想法，想到可以将 session 维护在客户端内 （加密的 cookie），当然实现方法还是一样的，我们重写 HttpSession 接口，实现其所有方法， 比如 setAttribute 就是写入 cookie，getAttribute 就是读取 cookie，我们可以将重写的 session 称作 MySession2，这时怎么让开发人员透明的获取到 MySession2 呢，实现方法还是在 filter 内 偷梁换柱，在 MyRequest 加一个判断，读取 sessionType 配置，如果 sessionType 是 redis 的， 那么 getSession 的时候获取到的是 MySession，如果 sessionType 是 coolie 的，那么 getSession 的时候获取到的是 MySession2，以此类推，用同样的方法就可以获取到 MySession 3,4,5,6 等等。 这样两种方式都有了，那么我们怎实现两种 session 共享方式的快速切换呢，刚刚我提到一个 sessionType，这是用来决定获取到 session 的类型的，只要变换 sessionType 就能实现两种 session 共享方式的切换，但是 sessionType 必须对所有的服务器都是一致的，如果不一致那将 会出现比较严重的问题，我们目前是将 sessionType 维护在环境变量里，如果要切换 sessionType 就要重启每一台服务器，完成 session 共享的转换，但是当服务器太多的时候将是 一种灾难。而且重启服务意味着服务的中断，所以这样的方式只适合服务器规模比较小，而且用 户量比较少的情况，当服务器太多的时候，务必需要一种协调技术，能够让服务器能够及时获取 切换的通知。基于这样的原因，我们选用 zookeeper 作为配置平台，每一台服务器都会订阅 zookeeper 上的配置，当我们切换 sessionType 之后，所有服务器都会订阅到修改之后的配置， 那么切换就会立即生效，当然可能会有短暂的时间延迟，但这是可以接受的。

4-3 在单点登录中，如果 cookie 被禁用了怎么办？

单点登录的原理是后端生成一个 session ID，然后设置到 cookie，后面的所有请求浏览器都

会带上 cookie，然后服务端从 cookie 里获取 session ID，再查询到用户信息。所以，保持登录 的关键不是 cookie，而是通过 cookie 保存和传输的 session ID，其本质是能获取用户信息的数 据。除了 cookie，还通常使用 HTTP 请求头来传输。但是这个请求头浏览器不会像 cookie 一样 自动携带，需要手工处理。