up:: 登陆状态的保存和验证
说明： 在本小节我们将深入的去理解session，主要是讲他的安全性，包括小伙伴有一些提问，其中也反映了小伙伴对session理解不够透彻，会有一些误区，我们会进行解答，另外的还会介绍sessionid 的生存规则，那其次呢？我们会介绍它的劫持与防护这部分内容。
session的安全性
疑问：
系统在进行session.setAttribute()的时候呢，，不同的用户在执行这一行代码的时候呢，虽然看似都是同一个key， 但是它背后的主体的部分，也就是这个 key 的更上层次的那个结构是不一样的，因为我们分开会给每一个用户，每一个sessionid 都分配一个自己的空间，在这个空间里面无论你是放这个user啊还是说你放用户 id 还是说你放别的东西都可以，你往里面去放，但是你看的时候只影响到你这个空间，只影响到你这个 sessionid 里面的内容，而对于其他用户的session空间而言呢，是不会受到影响的，所以我们没有必要对这个 key 呢，进行一个动态的升级唯一化处理，这就是这问题。
说明： 以下供以参考
来看一下postman中究竟是这个流程如何执行的，这个生成的 sessionid 究竟长什么样，以及服务器和客户端之间是怎么做这个set-cookie这个交互的。
postman演示
1.选择用户登陆，登陆成功后，看见了sessionid
此时我们将cookie叉掉，表示不带上cookie,重新登陆下
再点击cookie查看，就是我们set-Cookie里新生成的cookie值
然后我们比如查询商品，购买商品，点击cookie查看里面都带上了登陆成功后浏览器给我们的sessionid
session的劫持与防护
说到在这个劫持上，你可能会问，你有可能是这样的，sessionid既然是作为校验你这个用户的标识，你有sessionid就可以确认说你就是这个用户，那么有没有可能说这个泄露出去？有没有可能说被心怀不轨的人把我的sessionid 被他挪去用了，那一旦被他挪去用了是不是就意味着他就能去操作我的订单，他就能够下单了呢？确实是这样的，假设我们的 sessionid 被别人拿走了，他就能够去代替我们去做很多事情就相当于他窃取了我们的sessionid并且他就让服务器以为我们就像是他的真正的客户一样，那么这个就叫做session的劫持，这个劫持就是说他把我们去传给服务端的这个sessionid给在中间劫持了一下，劫持之后呢，他再利用这个身份去做很多不好的事情，这个风险确实是存在的，那么该如何防护呢？我们就要想一下这个风险究竟暴露在什么地方，那我们就有地方使得去针对这个位置进行一个防护，对吧？那我们现在就来讲一下这个sessionid在哪些环节可能会暴露。
HttpOnly: 服务端告诉前端这个东西独一无二，是很重要的，不允许前端代码读取，而浏览器这里生效以后，之允许浏览器读取，就会对其保护起来，防止被前端劫持
说明： 参考下https://www.jianshu.com/p/ba6500990694
**如果HTTP响应标头中包含HttpOnly标志（可选），客户端脚本将无法访问cookie（如果浏览器支持该标志的话）。因此即使客户端存在跨站点脚本（XSS）漏洞，浏览器也不会将Cookie透露给第三方。 如果浏览器不支持HttpOnly，并且后端服务器尝试设置HttpOnly cookie，浏览器也会忽略HttpOnly标志，从而创建传统的，脚本可访问的cookie。那么该cookie（通常是会话cookie）容易受到XSS攻击
session的缺点
说明：
(3)session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，如果主要考虑到减轻服务器性能方面，应当使用COOKIE
第一个是扩展性差。扩展性差指的是说当我们的用户量逐渐增多之后，很难非常平滑的去处理这个 session，因为假设我们把session保存在内存中啊。一旦你的服务是分布式的，有多台机器的话，你就会涉及到一个同步和复制的问题，第二个缺点呢？主要是需要服务端去存储数据，因为假设我们的用户量特别大数100万的话，那么你会发现这个用户数据的存储啊也不是一件简单的事情，不管你是存在内存中还是 redis 中，或者是数据库中的？那都会有对应的一些问题和难点，所以呢，从下一个小节开始我们就来学习追 Jwt， 很好的克服了session的这两个缺点。