目录

Cookie的安全性

Cookie真的安全吗

Cookie内容为什么不能是用户名和密码

Session

Session的实现

session存储在内存中的优缺点

session存储在数据库中的实践

session存储在数据库中的优缺点

session和cookie对比

跨站请求与cookie禁用时的session

Cookie的安全性

cookie由于保存在浏览器端，即用户个人电脑上，所以非常容易受到各种恶意攻击，而导致用户cookie被盗用·，为此浏览器为cookie设置了一些安全属性来限制对于cookie的操作以及cookie的发送。

• httponly
• secure
• samesite

httponly限制了cookie只能用于HTTP请求时携带，而不能使用javascript操作，如document.cookie操作cookie，这样可以有效保护cookie不被XSS的注入js脚本盗取。

secure限制了cookie只能用于HTTPS请求时携带，这样保护了cookie不会在网络中明文传输，即避免了网络传输被截获后，黑客可以直接得到明文cookie。

samesite默认限制了cookie在大部分HTTP请求中只能用于同站发送，比如浏览器网页请求的：

1. 服务器接口的IP地址和cookie的domain设置的IP地址相同，则cookie可以发送
2. 服务器接口的域名和cookie的domain设置的域名相同，则cookie可以发送
3. 服务器接口的域名是cookie的domain设置的域名的子域名，则cookie可以发送

只有少部分情况时，比如a标签超链接跳转GET请求，form表单GET请求，这种导航跳转式的GET请求才可以跨站发送cookie。

所以samesite可以有效保障cookie不会被跨站请求伪造CSRF利用。

Cookie真的安全吗

可能大家觉得cookie有了上面三个安全属性控制，已经很安全了，但其实不然，举个很容易理解的例子：

小明去网吧上网，登录某网站，并手贱地勾选了七天免登录，使用完后，小明直接关闭了浏览器，而没有清除浏览器cookie缓存。

然后，小王又使用了这台电脑，翻看了浏览器历史记录，然后点击了小明曾登录的网站，意外地发现可以免登录，且当前登录用户是小明，而小王又是一个程序员，他熟练地打开浏览器的cookie窗口，并发现了cookie中有类似于username和password的密文信息，于是它试着对username和password进行了破译，最终成功破译得到了明文的用户名和密码。

上面这个例子，小明用户名密码的泄漏原因并非来自于网络上的攻击，而是来自于网络外的攻击，由于小明的不良使用习惯，对cookie没有安全意识，导致了cookie泄漏，而这里的cookie内容又是用户名密码，进一步增加了用户名密码泄漏的风险。

所以，cookie不安全的根本原因是cookie将用户身份认证信息保存在了客户端主机上，而客户端主机没有像服务器主机一样的双重防护，即网络外的安全规范的人为操作 + 网络内的安全严谨的技术保障。虽然浏览器尽力在为客户端主机提供安全的技术保障，但是却无法强制每个用户都能进行安全规范的操作。

Cookie内容为什么不能是用户名和密码

上面例子中，cookie的内容是用户名和密码，那必然决定了服务器获取到cookie后会基于解析出的用户名和密码进行身份认证。这产生了两个严重的安全问题：

• cookie有效期无意义
• cookie可能被破译出明文的用户名和密码

为什么cookie有效期无意义了呢？

由于服务器是根据cookie解析出的用户名和密码进行身份认证的，所以有了cookie中的用户名和密码在任何时候都可以用于身份认证。

另外浏览器端支持手动修改cookie有效期，这可能导致cookie有效期被篡改而长期有效。

Cookie身份认证机制中，服务器端不需要记录生成cookie的有效期，cookie有效期的管理全权交给了浏览器，但是浏览器请求服务器时只会发送cookie内容，而不会发送cookie有效期属性，这导致了服务器无法验证cookie的有效期。

Session

那么如何基于Cookie进行安全的身份认证呢？

首先，服务器不能将用户名和密码作为cookie交给浏览器保存，其次服务器需要记录生成cookie的有效期，不能依赖于浏览器管理cookie的有效期。

所以基于Cookie，产生了Session身份认证技术。

Session身份认证技术脱胎于Cookie，它主要是解决Cookie上述两个安全隐患，所以Session工作流程如下：

1. 浏览器发送登录请求到服务器，服务器基于登录请求中的用户名和密码进行身份认证，认证成功后，将用户名和密码保存在服务器本地内存或硬盘上，并为其创造一个随机唯一串作为查询索引，我们将随机唯一串称为sessionid。
2. 服务器将sessionid作为响应头中Set-Cookie的值交给浏览器保存
3. 浏览器再次请求服务器，自动携带保存的cookie（即sessionid）到请求头Cookie中
4. 服务器受到请求，解析出请求头Cookie值（即sessionid），并基于sessionid到本地内存或硬盘上查询对应的用户名和密码进行身份认证，认证成功，则继续业务处理。

这里我们将保存在服务器端的用户登录状态数据称为session。

可以分析出，浏览器端不再保存实际的登录状态数据，只是保存了一个无业务意义的随机串sessionid，所以Session技术的安全性要比Cookie强。

sessionid的作用是，作为凭据交给浏览器端保存，解决了浏览器端cookie被破解后暴露出明文用户名密码的安全问题。sessionid还有一个作用就是，在服务器端，和session组成键值对，也可以理解为查找session的索引值。

Session的实现

Session技术实际上就是将登录状态数据从浏览器端转移到服务器端保存，即需要在服务器端考虑登录状态数据session的管理，具体管理行为可以参照浏览器端cookie的管理：

• cookie的设置：浏览器自动将服务器HTTP响应set-cookie的值保存到内存或硬盘中，当cookie有效期为会话时，它将被缓存在内存中，当cookie有效期为指定时间时，它将被持久化在硬盘中。
• cookie的获取：浏览器发送HTTP请求给服务器时，自动添加对应服务器域名domain和资源路径path下的，expires/max-age处于有效的，httpOnly,secure,samesite符合要求的cookie
• cookie的清除：当cookie有效期到达后，浏览器自动清除它。

所以服务器端也需要对session考虑以上管理行为

• session保存在哪？
• session如何获取？
• session何时清除？

服务器端既可以将session缓存在内存中，也可以将session持久化在硬盘中。但是缓存在内存中的session的生命周期不一定是会话级别的，持久化在硬盘中的session也可能是会话级别的。

为什么会这样呢？我们需要先了解会话生命周期的概念：

cookie的会话生命周期指的是：从浏览器请求服务器得到cookie开始，到浏览器关闭为止。

会话级别的cookie一定是保存在浏览器内存中的，而会话结束，意味着cookie要失效清除，同时会话结束，也意味着浏览器关闭，浏览器关闭会释放自身内存，此时内存中的cookie也会被清除，这就是会话级别cookie保存在浏览器内存中的原因。

类比可得，保存在服务器上的session会话生命周期指的是：从服务器接收浏览器请求生成session开始，到服务器关闭为止。

而服务器不会轻易关闭，这会导致session的会话生命周期很长，影响安全性。同时服务器也不会为了控制会话时间跨度而关闭自身。session理论上不存在会话生命周期。

但是一般我们可以设定固定时间为一个会话周期，比如20分钟为一次会话周期，20分钟到后，服务器强制清除对应session。

所以服务器端将session生命周期和其保存位置无关。

服务器端在保存session时，会生成一个sessionid，该sessionid是一个随机唯一的字符串，作用是作为在服务器端查询session的索引，和在浏览器端作为免登录的凭证。

所以服务器端获取session靠的是sessionid。

无论是cookie还是session，理论上都应该在其失效时清除，而不同的是清除手段。对于cookie而言，如果存储在内存中，则可以通过关闭浏览器释放内存来间接清除，如果存储在硬盘中，则需要浏览器内部代码逻辑清除。对于session，存储位置与生命周期无关，所以都只能通过代码清除，清除时，需要检查对应的session的有效期。

下面是基于express和cookie-parser开发的session中间件

const uuid = require('uuid').v1

module.exports = function(options = {}){
  // session store
  const SESSION = {}

  return function(req, res, next) {
    // 获取浏览器请求中的cookie:sessionid值，若首次访问，则sid为undefined,若非首次访问，则sid有值
    let sid = req.cookies.sessionid
    // 由于并不是每次浏览器请求都需要服务器响应set-cookie头，所以使用一个needCookie标识
    let needCookie = false
    // 根据sid到session_store中查询是否有对应session
    let session = SESSION[sid]
    
    // 如果session_store没有对应session 或者 session_store有对应session，但是已经失效，则需要重新生成新的sid和session,并且需要重新set-cookie给浏览器
    if(!session || (+session.expires <= Date.now())) {
      delete SESSION[sid]
      sid = uuid()
      needCookie = true
      session = SESSION[sid] = Object.create(null)
    }
    
    // 由于session有效期要与cookie:sessionid的有效期保持一致，所以只能以服务器端设置的有效期为准，且只能使用有效日期，而不是存活时间maxAge
    let expires
 
    if(options.maxAge) {
      expires = new Date(Date.now() + options.maxAge)
      delete options.maxAge
      options.expires = expires
    } else if(options.expires) {
      expires = options.expires
    } else {
      expires = new Date(Date.now() + 20 * 60 * 1000)
    }

    session.expires = expires

    // 提供修改session有效期的入口，方便实现七天免登录这样的功能
    session.setExpires = function(exp) {
      session.expires = exp
      options.expires = exp
      needCookie = true
    }

    // 提供删除session的入口，方便实现注销登录的功能
    session.destory = function(){
      delete SESSION[sid]
    }

    req.session = session
    if(needCookie) {
      res.cookie('sessionid', sid, options)
    }
    next()
  }
}

实现session身份认证机制-Node.js文档类资源-CSDN文库

以上是0积分可下载的示例项目链接。

session存储在内存中的优缺点

优点：

• 获取session速度快
• session存放在内存中，比存放在硬盘中更安全

缺点：

• 占用服务器内存，特别是当大量用户登录时，会产生大量session，占用大量服务器内存，严重时会导致服务器内存溢出。
• 每当服务器重启时，服务器都会释放自身内存，导致内存中存储的session被清除，进而导致浏览器端存储的sessionid失效。
• 对于分布式部署到多个服务器的项目而言，每个服务器内存中的session都是私有的，无法直接共享给其他服务器的，所以当用户被负载均衡分配到A服务器进行登录，但是又被负载均衡分配到B服务器进行其他业务时，会因为B服务器没有同步A服务器该用户的登录session数据导致业务无法进行。

session存储在数据库中的实践

前面说过session既可以存储在服务器内存中，也可以存储在服务器本地硬盘中。常见的存储在服务器本地硬盘的形式有：文件和数据库。

其中数据库可以更好地管理数据，所以我们一般选择将session存储在数据库中。

下面是基于node express框架开发的将session存储进Mongodb数据库的中间件代码

const uuid = require('uuid').v1
const mongoose = require('mongoose')

const sessionSchema = new mongoose.Schema({
  sessionid: {
    type: String,
    required: true
  },
  expires: {
    type: Date,
    default: new Date(Date.now() + 20 * 60 * 1000)
  },
  user: Object
})

const Session = mongoose.model('session', sessionSchema, 'session')

Session.prototype.setExpires = function(exp, res) {
  this.expires = exp
  res.setHeader('set-cookie', `sessionid=${this.sessionid};expires=${exp.toUTCString()};path=/;`)
}

Session.prototype.destory = async function(){
  await this.deleteOne()
}

module.exports = function(options = {}) {
  return async function(req, res, next) {
    let sid = req.cookies.sessionid
    let needCookie = false

    let session = await Session.findOne({sessionid:{$eq:sid}})

    if(!session || (+session.expires <= Date.now())) {
      if(session){
        await session.deleteOne()
      }
      
      if(options.maxAge) {
        options.expires = new Date(Date.now() + options.maxAge)
        delete options.maxAge
      }

      session = new Session({
        sessionid: uuid(),
        expires: options.expires
      })

      await session.save()

      sid = session.sessionid
      needCookie = true
    }

    req.session = session
    if(needCookie) {
      res.cookie('sessionid', sid, options)
    }
    next()
  }
}

session存储到数据库实践-Node.js文档类资源-CSDN文库

0积分可下载的实践项目

session存储在数据库中的优缺点

优点

• session不会因为服务器的重启而被清除，因为session被持久化到了数据库上
• 分布式部署到多个服务器的项目可以共用同一个session数据库，这样就不需要担心session同步问题

缺点

• session获取速度变慢
• session数据库需要注意安全防护，防止被黑客入侵

session和cookie对比

概念

session和cookie都是用户登录状态数据

工作流程

cookie由服务器生成，通过响应头Set-Cookie传递给浏览器，cookie由浏览器保存，每次请求服务器时，浏览器都会通过请求头Cookie将对应的cookie传递给服务器，服务器基于请求头Cookie信息进行身份认证。

session由服务器生成，并且保存在服务器，服务器在生成session的同时会生成与之一一对应的sessionid，sessionid有两个作用，一是在服务器端作为查找session的索引，二是作为登录凭据通过响应头Set-Cookie传递给浏览器，并保存在浏览器端。浏览器每次请求服务器都会通过请求头Cookie将sesionid传递给服务器，服务器通过sessionid查询到服务器端保存的session，并基于session进行身份认证。

安全性

在身份认证实践中，session比cookie更加安全，因为session机制会将用户登录状态数据保存在服务器端，浏览器端只有一个无意义字串sessionid。而cookie机制将用户登录状态数据保存在浏览器端。黑客盗取浏览器保存的cookie，要比盗取服务器保存的session，容易的多。

同时，cookie机制中，服务器无法验证cookie有效期，cookie有效期完全由浏览器管理，同时浏览器具备多种入口篡改cookie有效期，这可能导致cookie有效期被故意篡改导致长期有效。

而session机制中，服务器端可以在生成session时，保持session的有效期和作为cookie的sessionid的有效期一致，并且以服务器端保存的session的有效期为准，这保障了即使cookie:sessionid在浏览器端被篡改的长期有效，但是服务器端session的有效期却无法被篡改。

管理难度

cookie保存在浏览器端，浏览器已经有了一套成熟的管理机制：

保存：自动将服务器HTTP响应头中Set-Cookie信息保存在浏览器内存或硬盘中

获取：自动将保存在浏览器内存或硬盘中的cookie取出作为HTTP请求头Cookie发生给服务器

清除：自动清除内存或硬盘中失效的cookie

而session保存在服务器端，服务器本身没有内置管理session的机制，需要第三方工具或者人为开发管理代码

性能方面

另外cookie是将每个用户的登录状态数据分散保存在用户个人电脑上，对于服务器来说内存友好，性能友好。

session是将每个用户的登录状态数据集中保存在服务器内存或服务器连接的数据库中，对于服务器来说内存不友好，性能也不友好。

跨站请求与cookie禁用时的session

大部分跨站请求时，浏览器是禁止HTTP请求携带目的站点cookie的。

而session是基于cookie工作的，所以发生跨站请求时，session也是无法工作的。

另外浏览器提供了cookie禁用设置渠道，所以一旦用户禁用了cookie，那么session也是无法工作的。

node第三方模块express-session

express-session是express推荐的用于服务器端session管理的模块，下面是express-session使用示例

在express服务器中引入express-session模块，express-session模块对外暴露一个函数，如上图const session = require('express-session')中的session就是一个函数，该函数：

• 入参：配置对象
• 返回：express中间件

我们将该函数返回的express中间件注册到express服务器实例app上，则在服务器定义的HTTP请求对象req上会挂载一个session对象，我们可以通过req.session来操作服务器端session。

下面介绍一下入参配置对象的属性，及其作用

其中常用的有secret，name，cookie，rolling，store。

上面配置中name被指定为sessionid，所以在浏览器端存储的cookie的名称就是sessionid

浏览器端保存的cookie:sessionid的值为

s:HYm7whqjvhQ1CQVFCItHTNVTi_47CroP.t7ytiOOMSYIsLww5afl1dKXlTr0nh9bgEPZuhxmrDQo

 发现该值被:和.分为了三段，可以猜测第一段值：s，可能是指定签名算法，第二段是sessionid的值，即存入session store的_id的值，第三段就是根据secret和指定签名算法对sessionid值进行加密的签名，这保证了第二段sessionid值一旦被篡改，服务器端可以通过第三段签名值判断出来。

另外从session store存储的session信息可以分析

{

  "_id" : "HYm7whqjvhQ1CQVFCItHTNVTi_47CroP",

  "expires" : ISODate("2022-03-23T11:57:21.390Z"),

  "session" : "{\"cookie\":{\"originalMaxAge\":604800000,\"expires\":\"2022-03-23T11:57:21.135Z\",\"httpOnly\":true,\"path\":\"/\"},\"user\":{\"name\":\"qfc\",\"pass\":\"123456\"}}"

}

_id就是sessionid值，

expires是session有效期，

session分为cookie和user，其中cookie就是cookie:sessionid的属性，user就是登录状态数据

req.session可以用来操作session store，比如增删改查session store中的session信息。

一、关于 cookie 的前言概括

在之前的 HTTP 格式的介绍当中，有详细的介绍过 cookie 的相关用法。

简单回顾总结就是：

1. cookie 是让程序员能够在客户端持久存储数据的一种机制
2. 存储的是程序员自己定义的键值对
3. 通过服务器响应 set-cookie 这个 header 获取到 cookie 的值，并保存到本地
4. 下一次请求就会带上 cookie ，发送给服务器

用户输入账号密码登录后，再次登录不需要再次输入账号密码就可以直接的登录成功就是依靠 cookie 来实现的

但是有关于用户的信息实际上是非常多的，比如访问网站的浏览记录，上次访问网站的时间等等，这么多的信息在服务器客户端之间传输来又去的非常浪费带宽。更何况 cookie 的存储容量又是有限的，一个站点最多保留20个 cookie，这么多的用户信息没有办法单纯的依靠 cookie 来保存在客户端，因此将数据保存到服务器端才是比较科学的做法。

二、session 工作原理

因为要将信息存储在服务器端，就引入了会话机制 session。

session是服务端存储的一个对象，主要用来存储所有访问过客户端网页的用户信息（也可以存储其他信息），从而实现保持用户会话状态。但是服务器重启时，内存会被销毁，存储的用户信息也就消失了。

面试题：详述 session 工作原理

1. 当客户端登录完成后，就会在服务器端产生一个 session,，实际上是一个键值对，key 是 sessionId（随机唯一的字符串），value 保存的就是身份信息（HttpSession 对象）。服务器端将这些键值对形式的会话通过hash 表的形式管理起来
2. 此时服务器端就会将 sessionId返回到客户端浏览器。
3. 客户端将 sessionId 存储在浏览器的 cookie 中
4. 当用户再次登录的时候，就会拥有对应的 sessionId ，就将该 sessionId 发送到服务器端请求登录
5. 服务器端在内存中找到对应的 sessionId 就完成登录，如果找不到，说明还没有登录（每个用户登录都会生成一个会话），就返回登录页面让用户进行登录

session 工作原理和校园卡差不多，校园卡中实际上并没有保存太多的内容，但是有着它在学校中拥有的唯一的信息——学号。因此你（客户端）拎着这张卡，通过学号（相当于sessionId）就可以在系统中（服务器）搜索到有关于你的相关具体学生信息，就可以凭借卡进出宿舍大门，在图书馆借书，在食堂吃饭等等。

三、常用的方法

3.1 getSession()

这是 HttpServletRequest 类中的方法，作用是在服务器中获取会话。

HttpSession session = req.getSession(true);
HttpSession session = req.getSession(false);

参数为true

1. 查看请求中是否有 sessionId ，并判断其合法性
2. 如果有 sessionId 且合法，就根据该 sessionId 找到对应的 HttpSession对象
3. 如果没有 sessionId，就生成一个唯一的 sessionId，创建一个HttpSession 对象，把这一组键值对插入到服务器管理 session 的 hash 表中，把 sessionId 通过 Set-Cookie 在响应中返回给客户端

参数为false

1. 查看请求中是否有 sessionId ，并判断其合法性
2. 如果有 sessionId 且合法，就根据该 sessionId 找到对应的 HttpSession对象
3. 如果没有 sessionId，就直接返回 null

通常用法就是前者用于登录，后者用于查看登录的情况。

3.2 getAttribute()和setAttribute()

HttpSession 对象中就保存着我们需要保存的身份信息，这些身份信息的存储方式也是键值对的形式

**1. Object getAttribute(String name) **

该方法返回在该 session 会话中具有指定名称的对象，如果没有指定名称的对象，则返返回 null

int num = (Integer)session.getAttribute("number");
//通过number这个key来找对应的value，找的对象是int类型，需要进行强制类型转换

2. void setAttribute(String name, Object value)

该方法使用指定的名称绑定一个对象到该 session 会话

session.setAttribute("users",user);//将user是value; users是key

简单来说，就是 HttpSession 对象中的键值对，通过 key 来获取 value 的值的方法就是getAttribute，根据 key 来设置 value 的值的方法就是 setAttribute

四、关系总结图

可以看见Cookie，session，HttpSession 对象中的值都是键值对的形式，其中的关系需要理清。

五、实操：实现登录功能并计算访问页面的次数

5.1 登录页面实现（login.html）

<body>
    <form action="login" method="post">
        <input type="text" name="userName"><br>
        <input type="text" name="passWord"><br>
        <input type="submit" value="提交">
    </form>
</body>

通过的 form 表单简单的构造一个登录页面

1. action=“login” 中，login是处理 post 请求的 Servlet 程序，用于判断用户登录是否成功

2. method="post"指的是请求的方法时POST

3. form 表单默认的body格式是 x-www-form-urlencoded ，因此构造的请求 body为 userName=xxx&passWord=xxx

5.2 判断是否登录成功 Servlet 程序（LoginServlet）

class User {
    public String userName;
    public String passWord;
}
@WebServlet("/login")
public class LoginServlet extends HttpServlet {
    @Override
    protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        resp.setContentType("text/html;charset=utf8");//设置字符集
        //1.获取到body中的数据
        String userName = req.getParameter("userName");
        String passWord = req.getParameter("passWord");
        //2.验证登录数据的合法性，为null或者为空字符串都为不合法
        if(userName == null||userName.equals("")||passWord == null||passWord.equals("")) {
            resp.sendRedirect("login.html");
            //不合法就重定向到login.html继续用户名及密码的输入
            return;
        }
        //3.核对信息的正确性（在这里假定用户名字为Peter，用户的密码为123）
        if(!userName.equals("Peter")||!passWord.equals("123")) {
            resp.getWriter().write("用户名或者密码错误，登陆失败");
            return;
        }
        //到这儿登录成功啦，就可以创建会话了
        User user = new User();
        user.userName = userName;
        user.passWord = passWord;//构造一个 User 对象
        HttpSession session = req.getSession(true);
        //如果会话中不存在该用户就创建一个新的sessionId
        session.setAttribute("user",user);//设置属性
        session.setAttribute("index",0);//代表访问次数，最初为0
        resp.sendRedirect("index");
        //重定向到index路径，实现访问次数的计数
    }
}

流程总结：

1. 读取到用户提交的用户名和密码
2. 对用户名及密码的合法性进行校验
3. 判断是否登录成功
4. 创建会话，在 HttpSession 对象中保存一些信息
5. 重定向到指定页面

5.3 显示访问次数 Servlet 程序（IndexServlet）

@WebServlet("/index")
public class IndexServlet extends HttpServlet {
    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        resp.setContentType("text/html;charset = utf8");
        //1.首先需要通过session判断一下，是否已经登录成功了
        HttpSession session = req.getSession(false);
        //此时去找记录的时候，如果没有存档就返回null
        if(session == null) {
            //说明没有登录过，重定向到 login.html 页面进行登录
            resp.sendRedirect("login.html");
            return;
        }
        //到这里说明已经登录过了
        User user = (User)session.getAttribute("user");
        int visitCount = (Integer)session.getAttribute("index");
        //获取用户 user 和 设置的访问次数 index,首次访问时为0
        visitCount ++;//访问次数增加
        session.setAttribute("index",visitCount); //将值设置回去
        StringBuilder str = new StringBuilder();
        str.append(user.userName);
        str.append("访问次数： ");
        str.append(visitCount);
        resp.getWriter().write(str.toString());
    }
}

5.4 结果验证与展示

首次登录请求：

请求：

可以查看到form表单中接收请求的对象以及 body 部分

响应：

状态码 302 ，Location：index，说明重定向到 index 路径进行访问次数的显示了

由于登录成功，服务器通过 Set-Cookie 的Header向客户端传送 sessionId，该sessionId 的 key 为JSESSIONID ，后面跟着的一长串字符串就是 sessionId 的值（唯一的）

此时服务器端就保存了 sessionId

第二次请求：

这次请求服务器就会带着 sessionId ，服务器根据这来找到 HttpSession 对象，取出里面 index 对应的值，自增，在写回去，同时页面显示访问次数结果

浏览器本地查看的 Cookie 内容：

第二次请求的请求：

第二次请求的响应：

页面结果：

之后的继续访问，原理同上

总体效果展示：

当服务器进行重启，内存中的 session 数据就会没有，此时客户端拿着之前的 sessionId 是没有办法在服务器端找到 HttpSession 对象的，就会返回 null ，进行重新登录。

完！

1.SpringSession简介

1.1 Session 会话管理及带来的问题

HTTP协议本身是无状态，的为了保存会话信息，浏览器Cookie通过SessionID标识会话请求，服务器以SessionID为key来存储会话信息。 在 Web 项目开发中， Session 会话管理是一个很重要的部分， 用于存储与记录用户的状态或相关的数据。

• 通常情况下 session 交由容器（tomcat） 来负责存储和管理， 但是如果项目部署在多台tomcat 中， 则 session 管理存在很大的问题
• 多台 tomcat 之间无法共享 session， 比如用户在 tomcat A 服务器上已经登录了， 但当负载均衡跳转到 tomcat B 时， 由于 tomcat B 服务器并没有用户的登录信息，session 就失效了， 用户就退出了登录
• 一旦 tomcat 容器关闭或重启也会导致 session 会话失效因此如果项目部署在多台 tomcat 中， 就需要解决 session 共享的问题

1.2 SpringSession的特性

使用框架的会话管理工具，也就是我们要介绍的 Spring session，这个方案既不依赖 tomcat 容器， 又不需要改动代码， 由 Spring session 框架为我们提供， 可以说是目前非常完美的 session 共享解决方案。Spring Session 是 Spring 家族中的一个子项目， 它提供一组 API 和实现， 用于管理用户的 session 信息.它把 servlet 容器实现的 httpSession 替换为 spring-session， 专注于解决 session 管理问题， Session 信息存储在 Redis 中， 可简单快速且无缝的集成到我们的应用中；

Spring Session 的特性：

• 提供用户 session 管理的 API 和实现
• 提供 HttpSession， 以中立的方式取代 web 容器的 session， 比如 tomcat 中的session
• 支持集群的 session 处理， 不必绑定到具体的 web 容器去解决集群下的 session共享问题

2.入门案例

2.1 创建项目

（1）创建一个Maven的web module，名字为01-springsession-web
（2）完善Maven项目的结构

• 在main目录下，创建java目录，并标记为Sources Root
  
• 在main目录下，创建resources目录，并标记为Resources Root
  
• 导入依赖

<!--servlet依赖-->
    <dependency>
      <groupId>javax.servlet</groupId>
      <artifactId>javax.servlet-api</artifactId>
      <version>3.1.0</version>
    </dependency>
    <!--SpringSession redis 集成依赖-->
    <dependency>
      <groupId>org.springframework.session</groupId>
      <artifactId>spring-session-data-redis</artifactId>
      <version>1.3.1.RELEASE</version>
    </dependency>
    <!--Spring Web 模块依赖-->
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-web</artifactId>
      <version>5.2.10.RELEASE</version>
    </dependency>

2.2 代码开发

（1） 创建向 session 放数据的 servlet

package session.servlet;

import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;

@WebServlet(urlPatterns = "/setSession")
public class SetSessionServlet extends HttpServlet {
    @Override
    protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        doGet(req,resp);
    }

    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        req.getSession().setAttribute("url","http://www.baidu.com");
        resp.getWriter().write("OK");
    }
}

（2） 创建从 session 中获取数据的 servlet

package session.servlet;

import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;

@WebServlet(urlPatterns = "/getSession")
public class GetSessionServlet extends HttpServlet {
    @Override
    protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        doGet(req,resp);
    }

    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        String url= (String) req.getSession().getAttribute("url");
        resp.getWriter().write(url==null?"NO Session":url);
    }
}

（3）部署访问测试（目前无法实现 session 共享）

• 配置tomcat9100 服务器，给 tomcat 服务器取名，并修改端口号，并将项目部署到tomcat9100 上

• 配置tomcat9200服务器，操作步骤同上

可以在9100端口的服务器上访问/setSession，再在9200端口的服务器上访问 /getSession
这个时候我们通过测试会发现两个Tomcat服务器之间是无法共享session数据的

2.3 SpringSession 集成配置

• 在resources目录下创建如下两个配置文件
• applicationContext.xml文件

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
    <import resource="classpath:springsession.xml"/>
</beans>

• springsession.xml文件

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd">

    <!--
        启动Spring的注解支持，因为SpringSession中使用到了Spring的相关注解，因此需要启动Spring的注解，这一步是可以省略的
        通常工作时我们会使用 <context:component-scan base-package="com"/>来进行包扫描，这个标签中的功能就包含了
        <context:annotation-config/>的功能，因此实际工作时这个步骤是可以省略
     -->
    <context:annotation-config/>

    <!--
         定义一个用于配置SpringSession的bean标签配置
         只配置RedisHttpSessionConfiguration 的Bean 就可以实现同域名同项目的Session共享
         适合于我们的Nginx集群模式下的P2P项目部署
    -->
    <bean id="redisHttpSessionConfiguration" class="org.springframework.session.data.redis.config.annotation.web.http.RedisHttpSessionConfiguration">
        <!--配置Session的最大生命周期 单位 秒 默认值为1800 表示30分钟 -->
        <property name="maxInactiveIntervalInSeconds" value="1800"/>
    </bean>


    <!-- 配置 jedis 连接工厂， 用于连接 redis
         可选配置步骤，如果当前工程已经配置过了redis，那么这个过程可以省略
    -->
    <bean id="jedisConnectionFactory"
          class="org.springframework.data.redis.connection.jedis.JedisConnectionFactory">
          <!--分别为主机名、redis端口号、redis密码-->
        <property name="hostName" value="127.0.0.1"/> 
        <property name="port" value="6379"/>
        <property name="password" value="123456" />
    </bean>
</beans>

• 点击 config 将这两个配置文件进行关联
  

这次通过上面已经介绍过的测试方法，我们可以发现session数据可以在端口号分别为9100和9200的两个不同的Tomcat服务器上实现共享了

• 在浏览器（这里我使用的谷歌浏览器）上检查页面元素会发现两个页面上存储的cookie中存储的Session ID属性值和redis中相同。
  
  
  
  
• 上面的HASH文本框中便是redis上存储的Session ID值
• lastAccessTime：最后一次访问时间
• sessionAttr：session对象中存储数的属性
• maxIntactiveInterval：session的最大生命周期，默认是30分钟
• creationTime：session的创建时间

3.同域名下不同项目的session共享

3.1 案例

1. 在 Deployment 选项卡下，设置本地 tomcat9100的Application context 为/p2p
2. 在 Deployment 选 项卡下 ，设置本地 tomcat9200的Application context 为/shop
3. 在idea中重新启动本地的两台 tomcat 服务器
4. 在浏览器中访问 tomcat9100（p2p）， 设置 session
   
   session设置成功
   
   
5. 在浏览器中访问 tomcat9200（shop），获取 session
   
   获取不到session
   
   
6. 分析 Session 共享失败原因

• 我们通过浏览器提供的开发人员工具可以发现，这两个请求的 cookie 的路径(path)不一致（如下图），虽然我们已经加了Spring Session共享机制，但是后台服务器认为这是两个不同的会话(session)，可以通过 Redis 客户端工具（Redis Destop Mananger） 查看，先清空，然后访问，发现是维护了两个不同的 session，所以不能实现共享。
  
  
  
• 同样redis中也存储了两个不同的session对象，其中一个session对象中没有sessionAttr属性。
  
  

7. 解决方案：设置Cookie路径为根/上下文在springsession.xml文件中，加如下配置：

<bean id="redisHttpSessionConfiguration" class="org.springframework.session.data.redis.config.annotation.web.http.RedisHttpSessionConfiguration">
        <!--配置Session的最大生命周期 单位 秒 默认值为1800 表示30分钟 -->
        <property name="maxInactiveIntervalInSeconds" value="1800"/>
        <!--注入一个Cookie的序列化规则对象 -->
        <property name="cookieSerializer" ref="defaultCookieSerializer"/>
</bean>

    <!--配置一个Cookie序列化规则对象 用于改变Cookie的存放规则 -->
<bean id="defaultCookieSerializer" class="org.springframework.session.web.http.DefaultCookieSerializer">
        <!--指定SpringSession的SessionId存放在域名的根路径下，用于实现同域名不同项目的Session共享 -->
        <property name="cookiePath" value="/" />
</bean>

8. 重新进行测试发现两个不同项目的session数据也能实现共享，且两个请求的cookie路径（path）相同均为" / "。且此时redis中也只有一个session对象。
   

3.同根域名不同二级子域名下的项目实现Session 共享

同一个根域名，不同的二级子域名，比如北京和武汉的58同城域名：

3.1案例

添加域名映射： 找到C:\Windows\System32\drivers\etc路径下的hosts文件，在文件末尾加上：
127.0.0.1 p2p.myweb.com
127.0.0.1 shop.myweb.com

• 通过测试发现这是无法实现两个服务器上session数据的共享
• 原因：我们通过浏览器提供的开发人员工具可以发现，虽然这两个cookie 的路径(path)都设置为了“/”，但是这两个cookie的域名不一致，虽然我们已经加了Spring Session共享机制，但是后台服务器同样认为这是两个不同的会话(session)，可以通过 Redis 客户端工具（Redis Destop Mananger）查看，先清空，然后访问，发现是维护了两个不同的session，所以不能实现共享，也就是说后台区分是否同一个 session 和路径和域名有关。
  
  
• 解决方案：设置Cookie的域名为根域名 web.com，在 applicationContext-session.xml 文件中， 加如下配置：
  注意:域名要和 hosts 文件中配置的域名后面一样

<!--配置一个Cookie序列化规则对象 用于改变Cookie的存放规则 -->
    <bean id="defaultCookieSerializer" class="org.springframework.session.web.http.DefaultCookieSerializer">
        <!--指定SpringSession的SessionId存放在域名的根路径下，用于实现同域名不同项目的Session共享 -->
        <property name="cookiePath" value="/" />
        <!--指定SpringSession的SessionId存放在根域名下，用于实现同根域名不同二级子域名下的Session共享
            适合应用在Nginx的虚拟主机的多城市站点部署
         -->
        <property name="domainName" value="myweb.com"/>
    </bean>

• 经过测试，发现可以实现session共享
  
  
  此时两次请求的Session ID都是存放在.myweb.com域名下