Web开发中的Session详解及原理分析

本是古典何须时尚 2022-12-10 01:28 136阅读 0赞

## **一. HttpSession机制** ##

### **1.** **HTTP协议与HttpSession的状态保持** ###

> *Session经常被翻译为会话，其本来的含义是指有始有终的一系列动作/消息。比如打电话时，从拿起电话拨号到挂断电话这中间的一系列过程可以称之为一个Session。而在网络中，Session是指从一个浏览器窗口打开再到关闭的这个期间。*  
> *互联网应用层协议基本都是基于 HTTP 和 HTTPS 协议的，它们的本身都是无状态的， 也就是只负责网络的请求和响应。 我们只需要告诉服务器我们需要什么，服务器就会给我们返回相应的资源。 如果没有额外处理的话，服务器并不知道发起请求的人是谁，也无法根据请求者是谁来给你展现和你相关的内容了。*  
> *HTTP 协议之所以一开始被设计成这样，还是有一些历史原因的，当时的互联网多用于学术交流，只用于文章信息的展现，远没有像现在这么丰富多彩。所以在当时的背景下， HTTP 协议被设计成这样，其实也是很符合它的场景的。*  
> *但随着互联网应用越来越广泛，应用的形式也变得越来越多，我们的 Web 应用已不只限于提供简单的信息展现了，还需要用户能够与服务器进行交互，比如能够登录，可以在留言回复、可以进行购物、社交等。 这就需要 HTTP 协议能够记录用户的状态，而这个状态就可以由HttpSession来进行保存。*

### **2. HttpSession工作原理** ###

![05736ea5184cfdedc8c7cdbc4c0fcec3.png][]

*  Client(浏览器)第一次发送请求的时候，Web Container(Tomcat、Jetty等服务器容器)会生成唯一的Session ID(这个Session ID包括随机数+时间+JVM ID)，并将其返回给Client(在Web Container返回给Client的Response中)，但是Web Container上的这个HttpSession是临时的。
 *  接下来Client在每次发送请求给服务器时，都会将Session ID发送给Web Container，这样Web Container就能很容易区分出是哪个Client。
 *  Web Container会使用这个Session ID，找到对应的HttpSession，并将这个Request与这个HttpSession联系起来。

当用户第一次访问Servlet时,服务器端会给用户客户端创建一个独立的Session；
    该Session会有一个Session ID(JSESSIONID),格式如：JSESSIONID=7F149950097E7B5B41B390436497CD21，其中JSESSIONID是固定的。而这个Session ID在响应浏览器的时候会被存储到Cookie中,从而被保存到浏览器中；
    而后面的value值对应的则是给该客户端新创建的session的ID；
    当用户再一次访问Servlet时,请求C都会携带着Cookie中的SessionID去访问；
    服务器会根据这个Session ID去查看是否有对应的Session对象；
    如果有就拿出来使用;如果没有就创建一个Session(相当于用户第一次访问)。

### **3.** **HttpSession生命周期：** ###

### **3.1 什么时候创建HttpSession** ###

*  (1). 对于JSP而言:  
    　 是否浏览器访问服务端的任何一个JSP，服务器都会立即创建一个HttpSession对象呢？ 不一定。  
    　　①.若当前的JSP或Servlet，是客户端访问当前WEB应用的第一个资源，且JSP的page指令中的session属性为false时，服务器是不会为JSP创建HttpSession对象的；  
    　　②.若当前JSP不是客户端访问的WEB应用的第一个资源，且其他页面已经创建了一个HttpSession对象，则服务器也不会为当前JSP创建一个新的HttpSession对象，而是会把和当前会话关联的那个HttpSession对象返回给当前的JSP页面。
 *  (2). 对于Servlet而言:  
    　 若Servlet是客户端访问的第一个WEB应用资源，只有调用了request.getSession()或request.getSession(true) 才会创建HttpSession对象。

### **3.2 什么时候销毁HttpSession对象：** ###

*  (1). 直接调用HttpSession的invalidate()方法，会使HttpSession失效；
 *  (2). 服务器卸载了当前Web应用;
 *  (3). 超出了HttpSession的过期时间。

#代码中设置session过期时间的方式 
    session.setMaxInactiveInterval(5); 
    #web.xml中设置session过期时间的方式 
    <session-config> 
       <session-timeout>30</session-timeout> 
    </session-config>

*  **注：**  
    由于会有越来越多的用户访问服务器，因此Session也会越来越多。为了防止内存溢出，服务器会把长时间内没有活跃的Session从内存中删除，而这个时间就是Session的超时时间。如果超过了超时时间没访问过服务器，Session就自动失效了。

### **4. Session的特点** ###

Session数据保存在服务器端；
    Session中可以保存任意类型的数据；
    Session默认的生命周期是30分钟，可以手动设置更长或更短的时间。

## **二. Cookie机制** ##

### **1. 什么是Cookie** ###

> *Cookie翻译成中文是甜饼的意思，其实就是一个小型的文本文件，用来保存一些简单的信息(浏览器对Cookie的内存大小是有限制的)。Cookie由服务器端生成，并且会发送给 User-Agent (一般是浏览器)，服务器一般会告诉浏览器设置一下Cookie，然后浏览器会自动将该 Cookie 以* *`key/value`*  *的格式保存到浏览器的某个目录下；等到下次请求同一网站时，浏览器会自动通过请求头发送该`Cookie`给服务器，前提是浏览器设置了启用`Cookie`功能。*

### **2. 为什么要有Cookie** ###

> *Web应用程序是使用`HTTP`协议来传输数据的，而`HTTP`协议是无状态的协议，也就是说一旦数据交换完毕，客户端与服务器端的连接就会关闭，等再次交换数据就需要建立新的连接，这就意味着服务器无法从连接上跟踪会话。比如我们登陆一个网站的时候，会提醒你要不要记住账户和密码，这样下次来你就不用再次输入账号密码了，这就是`Cookie`的作用。当我们再次访问的时候，服务器会直接根据我们的`Cookie`来获取上一次取过的东西。*

### **3. Cookie 的特点** ###

### **3.1 Cookie 的过期时间** ###

> *我们每次发送请求的时候，都会根据`domain`来设置相应的Cookie。Cookie有永久的，也有临时的，每个浏览器都有自己的Cookie，我们可以通过设置`expires、max-age`来设置保存日期，如果不设置的话默认是临时存储，也就是说关闭浏览器后Cookie就会消失。*

document.cookie = 'expires=时间/max-age=秒'

### **3.2 Cookie要满足同源策略** ###

> *虽然网站`news.baidu.com`与`www.baidu.com`同属于Baidu，但是域名却不一样，也就是说这两者之间是不能互相操作彼此`Cookie`的。只有域名和`path`都必须一样，才能相互访问彼此的Cooki`。但是需要注意不同浏览器对`path`访问规定是不一样的，对于chrome，`path`必须为当前目录，设置为其他目录无效，当前页面只能访问当前目录的`Cookie\`。*

### **3.3 Cookie内存大小受限制** ###

Cookie有个数和大小的限制，大小一般是4k，但是不同的浏览器，具体的Cookie大小也是不同的。

*  Firefox和Safari允许Cookie多达4097个字节，包括名(name)、值(value)和等号;
 *  Opera允许Cookie多达4096个字节，包括名(name)、值(value)和等号;
 *  Internet Explorer允许Cookie多达4095个字节，包括名(name)、值(value)和等号。

![bab5e028eeb5f93a81a54c753820c839.png][]

### **3.4 Cookie的安全性** ###

`Cookie`是保存在浏览器本地的，是可以被修改的，所以敏感的数据不要放在Cookie里。

## **三. Session共享** ##

### **1. Session存在的问题** ###

HttpSession是通过Servlet容器创建和管理的，像Tomcat/Jetty都是保存在内存中的。但是如果我们将Web应用横向扩展成分布式的集群，然后利用LVS或Nginx进行负载均衡，那么对来自同一用户的Http请求，将有可能被负载分发到两个不同的服务器实例中去。那么如何保证不同实例间的Session共享，就成为一个不得不解决的问题。

最简单的解决方法就是把Session数据保存到内存以外的一个统一的地方，例如Memcached/Redis中。那么问题又来了，如何替换掉Servlet容器，来创建和管理HttpSession呢？

### **2. Session共享的实现方案** ###

1.  利用Servlet容器提供的插件功能，自定义HttpSession的创建和管理策略，并通过配置的方式替换掉默认的策略。不过这种方式有个缺点，就是需要耦合Tomcat/Jetty等Servlet容器的代码。这方面其实早就有开源项目了，例如[memcached-session-manager][]，以及[tomcat-redis-session-manager][]，不过这暂时都只支持Tomcat6/Tomcat7。
2.  配置Nginx的负载均衡算法为ip\_hash，这样每个请求按访问IP的hash结果分配，这样来自同一个IP的访客就会固定访问一个后端服务器，有效解决了动态网页存在的Session共享问题。
3.  使用Shiro管理Session，可以用Redis来实现Shiro 的SessionDao接口，这样Session便归Redis来保存了。
4.  设计一个Filter，利用HttpServletRequestWrapper，实现自己的 getSession()方法，来接管创建和管理Session数据的工作。Spring-Session就是通过这样的思路实现的。
5.  Spring-Session结合Redis实现Session共享。

## **四. Spring Session** ##

### **1. 传统Session的问题** ###

> *我们都知道Session是由Web容器管理的，即一个Session只保存在一台机器上，适合于单体应用。但随着架构的演练，不断的向微服务分布式集群演进，此时传统的Session就不能工作了。如：现在有3台Web服务器，客户端通过Nginx负载均衡技术，来负载到某一台服务器上，用户此次的数据就保存到了这台服务器的Web容器中了。等用户下次请求时，如果被负载到其它机器上，那么就拿不到之前保存的数据了，这时候就需要整个服务器集群共享同一个Session。*  
> *为了解决所有服务器共享一个Session，那么Session就不能单独的保存在自己的Web容器中，而是要保存在一个公共的会话仓库(Session Repository)中，也就是说所有的服务器都要访问这同一个仓库，这样所有服务器的状态便都一致了。Spring Session支持的仓库有Reids、MongoDB、JDBC等。*

### **2. Spring Session的存储方式** ###

默认情况下，在Spring Boot中，为Spring Session提供了几种存储方式:

*  JDBC
 *  MongoDB
 *  Redis
 *  Hazelcast
 *  HashMap

在Spring Session可用的情况下，我们可以选择存储Session的存储类型[StoreType][]。例如，按如下配置将使用JDBC作为后端存储：

spring.session.store-type=jdbc
    
    # 通过设置`store-type`为`none`可以禁用Spring Session

### **注:** ###

出于向后兼容，在Redis可用的情况下，Spring Boot中会默认自动配置及使用Redis来存储Spring Session。

另外每种存储方式都有特殊设置，例如，对于jdbc存储可自定义要存储的表名：

spring.session.jdbc.table-name=SESSIONS

### **3. Spring Session的优点** ###

> *Spring Session是基于Servlet规范实现的一套Session管理框架，主要解决了分布式场景下的Session共享问题。Spring Session最核心的类是SessionRepositoryFilter过滤器，用于包装用户的请求和响应，我们可以在程序中直接替换掉HttpSession，而无需修改一行代码。而且也可以很方便的与Spring Security集成，增加诸如findSessionsByUserName、rememberMe等功能，限制同一个账号可以同时在线的Session数量(如设置成1，即可达到把前一次登录顶掉的效果)等等。*

[05736ea5184cfdedc8c7cdbc4c0fcec3.png]: /images/20221123/33477c70d5df4da48da0292a79a321bc.png
[bab5e028eeb5f93a81a54c753820c839.png]: /images/20221123/39589c7479f64a59962503c808947c36.png
[memcached-session-manager]: https://link.zhihu.com/?target=https%3A//link.jianshu.com/%3Ft%3Dhttps%3A//github.com/magro/memcached-session-manager
[tomcat-redis-session-manager]: https://link.zhihu.com/?target=https%3A//link.jianshu.com/%3Ft%3Dhttps%3A//github.com/jcoleman/tomcat-redis-session-manager
[StoreType]: https://link.zhihu.com/?target=https%3A//github.com/spring-projects/spring-boot/tree/v1.4.1.RELEASE/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/session/StoreType.java