深入分析JavaWeb内幕读书笔记——(六)

深入理解session与Cookie

Cookie

当用户通过Http访问一个服务器时，服务器会将一些key/value键值对返回给用户浏览器，并给这些数据加上一些限制条件，在条件符合时，用户下次访问服务器时，数据又被完整地带回给服务器。它就像是你办的一张会员积分卡，会员积分卡中存放了你的一些个人信息，当你下次消费时，你就可以利用会员积分卡获得便利与优惠。

Cookie的属性

• set-Cookie 属性项（版本0）
  • NAME=VALUE：键值对，可以设置要保存的key/value，注意这里的NAME不能和其他属性项的名字一样
  • Expires：过期时间，在设置的某个时间点后，该Cookie就会失效
  • Domain：生成该Cookie的域名
  • Path：该Cookie是在当前哪个路径下生成
  • Secure：如果设置了该属性，那么只会在SSH连接下返回该Cookie
• set-Cookie2 属性项（版本1）
  • NAME=VALUE：与版本0相同
  • Version：通过Set-Cookie2设置的响应头创建必须符合RFC2965规范，如果通过Set-Cookie响应头设置则默认值为0；如果要设置为1，则该Cookie要遵循RFC2109规范。
  • Comment：注释项，用户说明该Cookie有何用途
  • CommentURL：服务器为此Cookie提供的URI注释
  • Discard：是否在会话结束后丢弃该Cookie项，默认为false
  • Domain：与版本0基本一致
  • Port：Cookie在什么端口下可以回传服务器，多个端口以逗号隔开
  • Secure：与版本0基本一致

Session

同一个客户端每次和服务端交互时都会传回一个NAME为JSESSIONID的一个Cookie，这个ID值是客户端第一次访问服务器时生成的，且每个客户端是唯一的。

Session的工作方式

基于URL Path Parameter,默认支持。当浏览器不支持Cookie功能时，浏览器会将用户的SessionCookieName重写到用户请求的URL参数中，例如：/path/Servlet;name=value;name2=value2?name3=value3，在Servlet中；后面的key/value就是要传递的Path Parameters,如果在web.xml中配置的session-config配置项，其cookie-config下的name属性就是SessionCookieName的值。如果没有配置session-config配置项，默认SessionCookieName就是JSESSIONID,Request根据这个SessionCookieName到Parameters中拿到SessionID并设置到Request.setRequestedSessionId中。如果客户端支持Cookie，Tomcat仍然会解析Cookie中的SessionID并覆盖URL中的SessionID。

在基于Cookie，如果默认没有修改Context容器的Cookies标识，则默认也是支持的。

在基于SSL，默认不支持，只有connector.getAttribute("SSLEnabled")为TRUE时才支持。在这种情况下，会根据javax.servlet.request.ssl_session属性值来设置SessionID。

服务端根据SessionID来创建HttpSession对象，第一次触发通过request.getSession方法，如果SessionID有对应的HttpSession对象，就创建一个新的，并添加到org.apache.catalina.Manager的sessions容器中保存，这个类负责管理所有Session的生命周期，Session过期将被回收，服务器关闭，Session被序列化到磁盘等。只有HttpSession对象存在，用户就可以根据SessionID来获取这个对象，也就做到了对状态的保持。当Servlet容器重启或关闭时，Manager的实现类StandardManager类负责持久化没有过期的StandardSession对象到一个叫做“SESSIONS.ser”的文件中。当Servlet容器重启时，StandardManager初始化时，会重新读取这个文件，并校验Session对象是否过期，失效已经过期的Session，恢复没有过期的Session。（要保存Session对象就必须调用Servlet容器的stop和Start命令。不能直接结束容器进程，在直接结束进程的情况下，没有机会调用unload方法来持久化session对象。）

分布式Session框架

分布式Session框架解决的主要问题：

• Session配置统一管理
• Cookie使用的监控和统一规范管理
• Session存储的多元化
• Session配置的动态修改
• Session加密key的定期修改
• 充分的容灾机制，保证框架的使用稳定性
• Session各种存储的监控和报警支持
• Session框架的可扩展性，兼容更多的session机制
• 跨域名Session和Cookie共享问题

分布式Session框架的主要思路是，建立一个服务订阅服务器，应用启动时可以从服务订阅服务器中订阅它需要的可写Session项和可写Cookie项，这些配置的Session和Cookie可以限制这个而应用能够使用哪些Session和Cookie，甚至可以紧缺控制读写操作。如果某个应用要使用一个新增的Cookie，则可以通过一个统一的平台来申请，申请通过才将这个配置项增加到订阅服务器，如果是全局的Cookie，那么只需要将这个Cookie统一推送到各个应用系统。由于各个应用系统的Session必须同步且共享，因此必须将他们存储在一个分布式缓存中，可以随时读写。

分布式Session框架的主要步骤是：配置一个filter拦截用户请求->在请求到达MVC之前，重新封装HttpServletRequest和HttpServletResponse成我们自己的对象->将这个新的对象设置到request和response对象中->应用系统通过request.getHttpSession返回我们创建的新的Session对象->session初始化，并获取用户私密信息->session设置到request和response中->将新的session提交到分布式缓存中->重要的值同时写入Cookie中备份。

关于表单重复提交的解决方案：客户端请求表单页面->生成唯一token->存储到用户session中->生成一个隐藏表单域来存储唯一token->客户端提交表单->获取隐藏表单域存储的token->获取隐藏表单域的token与session中的token比对->验证成功，则进行后续操作（验证失败，则提示用户不能重复提交）。

---

自己使用整理收集，如有侵权 请联系删除!