Session是以Cookie技术或URL重写实现。默认以Cookie技术实现,服务端会给这次会话创造一个JSESSIONID的值。
这个id值会发送给client,client每次请求都会把这个id值放到http请求的头部发送给服务端,而这个id值在client会保存下来,保存的容器就是cookie。上面代码就是依据requestedSessionId 去查找session,找不到就创建新的session。那么requestedSessionId 怎么获取的呢?protected Session doGetSession(boolean create) {
// There cannot be a session if no context has been assigned yet
if (context == null)
return (null);
// Return the current session if it exists and is valid
if ((session != null) && !session.isValid())
session = null;
if (session != null)
return (session);
// Return the requested session if it exists and is valid
Manager manager = null;
if (context != null)
manager = context.getManager();
if (manager == null)
return (null); // Sessions are not supported
if (requestedSessionId != null) {
try {
session = manager.findSession(requestedSessionId);
} catch (IOException e) {
session = null;
}
if ((session != null) && !session.isValid())
session = null;
if (session != null) {
session.access();
return (session);
}
}
// Create a new session if requested and the response is not committed
if (!create)
return (null);
if ((context != null) && (response != null) &&
context.getCookies() &&
response.getResponse().isCommitted()) {
throw new IllegalStateException
(sm.getString("coyoteRequest.sessionCreateCommitted"));
}
// Attempt to reuse session id if one was submitted in a cookie
// Do not reuse the session id if it is from a URL, to prevent possible
// phishing attacks
if (connector.getEmptySessionPath()
&& isRequestedSessionIdFromCookie()) {
session = manager.createSession(getRequestedSessionId());
} else {
session = manager.createSession(null);
}
// Creating a new session cookie based on that session
if ((session != null) && (getContext() != null)
&& getContext().getCookies()) {
String scName = context.getSessionCookieName();
if (scName == null) {
scName = Globals.SESSION_COOKIE_NAME;
}
Cookie cookie = new Cookie(scName, session.getIdInternal());
configureSessionCookie(cookie);
response.addSessionCookieInternal(cookie, context.getUseHttpOnly());
}
if (session != null) {
session.access();
return (session);
} else {
return (null);
}
}
![关于tomcat session机制梳理 - bohu83 - bohu83的博客 关于tomcat session机制梳理 - bohu83 - bohu83的博客](http://img0.ph.126.net/oAsc6RyApaP69JkzIEwfZQ==/6631367932379119002.png)
![关于tomcat session机制梳理 - bohu83 - bohu83的博客 关于tomcat session机制梳理 - bohu83 - bohu83的博客](http://img1.ph.126.net/N7at7acYj3DbfEjyLQDCIQ==/6631410813332606686.png)
Request详细的逻辑是调用Context容器的getManger方法获取Session管理器(session管理器详情下文介绍),然后假设SessionId假设已经被解析出来了。那么则会调用findSession方法从session对象池中获取相应的session,反之假设sessionId不存在,则须要又一次创建一个Session,并放入session对象池中。
类RequestFacade的getSession方法:
![关于tomcat session机制梳理 - bohu83 - bohu83的博客 关于tomcat session机制梳理 - bohu83 - bohu83的博客](http://img0.ph.126.net/sdKC11M9PfpLSZoa892EMg==/4869798572171412543.png)
![关于tomcat session机制梳理 - bohu83 - bohu83的博客 关于tomcat session机制梳理 - bohu83 - bohu83的博客](http://img1.ph.126.net/YdSbgeaQh5yHnvvgw4ObvA==/6631322852402379433.png)
![关于tomcat session机制梳理 - bohu83 - bohu83的博客 关于tomcat session机制梳理 - bohu83 - bohu83的博客](http://img1.ph.126.net/cbcvcUV7Qn6D0-oneqEPhg==/1630021590231782893.png)
![关于tomcat session机制梳理 - bohu83 - bohu83的博客 关于tomcat session机制梳理 - bohu83 - bohu83的博客](http://img1.ph.126.net/uPejQBTYw94JdCYhTvRd_g==/2003257409350252189.png)
实现包的路径是:org.apache.catalina.session,tomcat对外提供session调用的接口不在这个实现包里。对外接口是在包javax.servlet.http下的HttpSession。而实现包里的StandardSession是tomcat提供的标准实现,当然对外tomcat不希望用户直接操作StandardSession,而是提供了一个StandardSessionFacade类,tomcat容器里详细操作session的组件是servlet。而servlet操作session是通过StandardSessionFacade进行的。这样就能够防止程序猿直接操作StandardSession所带来的安全问题。
![关于tomcat session机制梳理 - bohu83 - bohu83的博客 关于tomcat session机制梳理 - bohu83 - bohu83的博客](http://img2.ph.126.net/W7fzp34GGA-XAO1tqfAXOA==/6631320653379109940.jpg)
(1) Manager:定义了关联到某一个容器的用来管理session池的基本接口。这是catalina包下的。
(2) ManagerBase:实现了Manager接口。该类提供了Session管理器的常见功能的实现。
(3) StandardManager:继承自ManagerBase,tomcat的默认Session管理器(不指定配置,默认使用这个),是tomcat处理session的非集群实现(也就说是单机版的),tomcat关闭时,内存session信息会持久化到磁盘保存为SESSION.ser,再次启动时恢复。
(4) PersistentManagerBase:继承自ManagerBase,实现了和定义了session管理器持久化的基础功能。
(5) PersistentManager:继承自PersistentManagerBase,主要实现的功能是会把空暇的会话对象(通过设定超时时间)交换到磁盘上。
(6)StoreBase:存放持久化有关store接口的基本实现。
![关于tomcat session机制梳理 - bohu83 - bohu83的博客 关于tomcat session机制梳理 - bohu83 - bohu83的博客](http://img2.ph.126.net/PSPDXzbISF4Q7mucCid7qQ==/6598286926089051287.png)
接口Store及事实上例是为session管理器提供了一套存储策略。store定义了主要的接口。而StoreBase提供了主要的实现。
当中FileStore类实现的策略是将session存储在以setDirectory()指定文件夹并以.session结尾的文件里的。JDBCStore类是将Session通过JDBC存入数据库中,因此须要使用JDBCStore,须要分别调用setDriverName()方法和setConnectionURL()方法来设置驱动程序名称和连接URL。
(7) StandardSession :tomcat的session实现类。
2.4 Tomcat session相关的配置
从两个层面总结一下session相关的配置和设置。首先是从配置文件层面,session是有过期时间的,这个默认的过期时间是 在$catalina_home/conf/web.xml有定义的。详细的默认配置例如以下(默认的过期时间是30min,即30min没有訪 问,session就过期了):
另一点就是session管理假设不配置就默认使用StandardManager。但假设要配置的话能够 在$catalina_home/conf/context.xml当中指定(当中从这个配置当中能够看到session管理器是和context容器关 联的,也就说每一个web应用都会有一个session管理器)详细的配置例如以下:
Tomcat7.x默认这个manager的配置是凝视掉的。假设要指定的PersistentManager为默认管理器的话能够这么指定:
事实上看到这也就发现了,事实上session管理器或者Store存储策略。仅仅要实现了相关的接口,都是能够自己定义的。
自己写一个配置在这里就ok了。
另外在从代码层面总结一下:session的一些配置信息是写死在代码里的,比方SessionConfig这个类就定义了一些session的设 置信息。Session在cookie中的名字是JSESSION. Session通过URL重写的方式放在path里时,键值的名字是jsessionids,详细的代码例如以下:
另一点就是sessionId默认指定的长度是16个字节,这个在SessionIdGenerator当中指定:
这个 SessionIdGenerator应该是tomcat7的。我在6上源代码找不到。
关于tomcat6的源代码里面。有这种方法generateSessionId:
protected synchronized String generateSessionId() {
byte random[] = new byte[16];
String jvmRoute = getJvmRoute();
String result = null;
// Render the result as a String of hexadecimal digits
StringBuffer buffer = new StringBuffer();
do {
int resultLenBytes = 0;
if (result != null) {
buffer = new StringBuffer();
duplicates++;
}
while (resultLenBytes < this.sessionIdLength) {
getRandomBytes(random);
random = getDigest().digest(random);
for (int j = 0;
j < random.length && resultLenBytes < this.sessionIdLength;
j++) {
byte b1 = (byte) ((random[j] & 0xf0) >> 4);
byte b2 = (byte) (random[j] & 0x0f);
if (b1 < 10)
buffer.append((char) ('0' + b1));
else
buffer.append((char) ('A' + (b1 - 10)));
if (b2 < 10)
buffer.append((char) ('0' + b2));
else
buffer.append((char) ('A' + (b2 - 10)));
resultLenBytes++;
}
}
if (jvmRoute != null) {
buffer.append('.').append(jvmRoute);
}
result = buffer.toString();
} while (sessions.containsKey(result));
return (result);
}
实现原理:一个随机数加时间加上jvm的id值,jvm的id值会依据server的硬件信息计算得来,因此不同jvm的id值都是唯一的
再补充一点:session本身也是基于kv的hashmap实现的,比方:StandardSession 里面
protected Map attributes = new ConcurrentHashMap();
全部的会话信息的存取都是通过这个属性来实现的。另外上面web.xml的配置有效期tomcat是怎么实现的呢?
就是ManagerBase.processExpires。一直查询全部的session对象。每一个检查是否有效,超期就删除。
详细代码參见
![关于tomcat session机制梳理 - bohu83 - bohu83的博客 关于tomcat session机制梳理 - bohu83 - bohu83的博客](http://img2.ph.126.net/UPe3-3MJLNxEyk-e52lRYw==/6631435002588416912.png)
![关于tomcat session机制梳理 - bohu83 - bohu83的博客 关于tomcat session机制梳理 - bohu83 - bohu83的博客](http://img0.ph.126.net/DDN3xfGtgerB4qf685sdLw==/6598292423647190727.png)
当中session在expire会触发相应的listener事件,从而对session信息进行监控,以下是expire方法部分截图。
![关于tomcat session机制梳理 - bohu83 - bohu83的博客 关于tomcat session机制梳理 - bohu83 - bohu83的博客](http://img1.ph.126.net/sMKuqVPUFU35FuKjusiZTQ==/1629177165301652125.png)
**********************总结*********************
在实际运用中session所带来的问题
由上面所描写叙述的session实现机制。我们会发现。为了弥补http协议的无状态的特点。服务端会占用一定的内存和cpu用来存储和处理session计算的开销,这也就是tomcat这个的web容器的并发连接那么低(tomcat官方文档里默认的连接数是200)原因之中的一个。因此非常多java语言编写的站点。在生产环境里web容器之前会加一个静态资源server,比如:apacheserver或nginxserver。静态资源server没有解决http无状态问题的功能,因此部署静态资源的server也就不会让出内存或cpu计算资源专门去处理像session这种功能。这些内存和cpu资源能够更有效的处理每一个http请求,因此静态资源server的并发连接数更高,所以我们能够让那些没有状态保持要求的请求直接在静态server里处理。而要进行状态保持的请求则在java的web容器里进行处理。这样能更好的提升站点的效率
解决session相关问题的技术方案
由上所述,session一共同拥有两个问题须要解决:
1) session的存储应该独立于web容器。也要独立于部署web容器的server。
2)怎样进行高效的session同步。
以下是一篇用zookeeper实现的分布式session方案: