JavaWeb session与Tomcat配置参数

在学习Tomcat时有一些误解,主要来自于Tomcat配置文档中关于maxThread和maxConnection的问题。
Thread和Connection怎么对应?和session又怎么对应,这么一想我对整个C/S交互其实并没有怎么梳理过。
我一开始的想法自然是,Thread对应Connection,Connection对应session,相信应该也有过同样想法的朋友
对于session一开始的概念是这样的,某些写得很烂的教科书上面可能也类似这样一笔带过——
“在浏览器创建会话时创建一个session,关闭浏览器session结束。”
这也是为什么我会把Connection对应到session,以至于无法理解配置中的keep-alive参数
如果session对应Connection,那么keep-alive干嘛?我们不都一直连着吗
又假如,keep-alive设得比较小,那么不keep的连接一断开,那我岂不是取不到session中的东西了吗
另一方面,假如这样,那么Tomcat中默认的maxThread=200不就意味着只能200个人同时访问吗
应该是错的,仔细一想就觉得不可能。

于是我开始测试。新建一个Web项目,全部默认,只有一个index.jsp。
然后再新建一个Listener,用于监听HTTPSession。当连接建立,连接断开在控制台输出。

@WebListener
public class SessionListener implements HttpSessionListener {

	@Override
	public void sessionCreated(HttpSessionEvent httpSessionEvent) {
		HttpSession session=httpSessionEvent.getSession();
		System.out.println(session.getId()+"created");		
	}

	@Override
	public void sessionDestroyed(HttpSessionEvent httpSessionEvent) {
		HttpSession session=httpSessionEvent.getSession();
		System.out.println(session.getId()+"destoryed");
	}
}

然后当我打开页面,没错,session created,但是关闭浏览器后,并没有输出session destroyed
果然,session并不对应connection,因为连接已经断开。
所以我的理解有问题,接下来便是系统整理的部分了。


第一个问题,session是什么?
session是一种机制,用于保存会话信息,和cookie有些类似,可以理解为在服务器端保存的一个文件,而cookie保存在客户端处。不同于cookie,它保存的而在客户端这边的就只有session id,也即“痕迹信息”,当一个请求建立,会发生以下几件事

  1. 客户端木有session id,不发,有的话,发到服务器
  2. 服务器检查session id是否存在,也即有没有这个文件
  3. 没有的话新建,当然没发过来也新建
  4. 根据session文件中保存的东西进行查询啥的

关于session的实现机制,其实有好几种,其中一种是使用会话cookie,也即用cookie保存session id,会话结束也即关闭浏览器时,这个cookie被删,那么服务器自然找不到原有的session,使用会话cookie的方式时,就可以理解为session在关闭浏览器时就无效了。

但是,但是,服务器是没有机会知道的,它只存了个文件,你关了浏览器人文件还在,并不是没了。所以为了应对这种情况,它有一个失效时间——太长时间不用这个session,服务器那边就删了。
另外一些机制可以实现关闭浏览器依旧留着session id,不用回话cookie,存在别的地方,这里不详谈。
(其实学java的童鞋现在可以打住了,往下可以甩给运维操心去了,但看一下对于理解理论挺不错的)

第二个问题,Tomcat中的connection指的是什么?
要理解这个,还需官方文档,maxConnection参数隶属于<Connector></Connector>所以从它入手

The HTTP Connector element represents a Connector component that supports the HTTP/1.1 protocol. ....A particular instance of this component listens for connections on a specific TCP port number on the server.One or more such Connectors can be configured as part of a single Service, each forwarding to the associated Engine to perform request processing and create the response.

翻译过来便是:

HTTP Connector 配置元素代表着支持HTTP/1.1协议的Connector部件(也即Tomcat内置部件),每一个特定的Connector监听着服务器上一个特定的TCP端口。一个或多个Connector可以配置为单独一个Service,每个对应相关联的引擎以处理request请求并response。

所以可知,Tomcat中的connection指的是http在进行request时建立的连接,也即http连接
再看到keep-alive,在http中,开启它意味着保留长连接不断开,它的优点在于:
当我们打开网页,就会建立一条http连接,然后会有大量的request和response来来回回,传递html、css、js等等。多个request复用一条连接,无疑加快了传输,所以在http1.1中,这个参数默认开启。
如果我们在http报头中设置:Connection:close,那么打开网页本身就会有不断的http连接建立和断开的过程。
这里要清楚一点,服务器可以不管客户端的keep-alive请求,服务器为什么不管呢?其实就是因为大家默认开启着,如果服务器不灵活一点主动关闭一部分,那么服务器资源就不够。服务器的内存、CPU都是有限的,太多的线程会耗尽服务器资源,大家都keep-alive,占着茅坑不拉屎也不是办法。
第三个问题,Tomcat中关于以上这些东西的配置,以及它们意味着什么?
 

maxThreads——最大线程数
The maximum number of request processing threads to be created by this Connector, which therefore determines the maximum number of simultaneous requests that can be handled. If not specified, this attribute is set to 200.

request请求的最大线程数,因此决定了同时有多少request会被处理,如果未指定,默认200个。

需要注意的是,比如此时有200个人接着服务器,但是不一定发生了200个请求,所以下文maxConnection的配置中,可以看到,maxConnection默认可以指定到10000。
 

maxConnections——最大HTTP连接数
The maximum number of connections that the server will accept and process at any given time. When this number has been reached, the server will not accept any more connections until the number of connections falls below this value. The operating system may still accept connections based on the acceptCount setting. Default value varies by connector type. For BIO the default is the value of maxThreads unless an Executor is used in which case the default will be the value of maxThreads from the executor. For NIO the default is 10000. For APR/native, the default is 8192.

服务器接受和处理的最大连接数,如果达到了这个数,就不再接受连接了,但是如果你指定了acceptCount参数,还是会接受连接,但是不处理。默认由connector类型进行指定,BIO类型(同步阻塞)时等于线程数除非使用了executor,NIO(非同步阻塞)时为10000,APR时为8192。

acceptCount——连接已满时接受请求数
The maximum queue length for incoming connection requests when all possible request processing threads are in use. Any requests received when the queue is full will be refused. The default value is 100.

当所有能用的request处理线程都繁忙时,接受建立连接请求的数量,大于这个参数会被直接拒绝,默认为100.

maxKeepAliveRequests
The maximum number of HTTP requests which can be pipelined until the connection is closed by the server. Setting this attribute to 1 will disable HTTP/1.0 keep-alive, as well as HTTP/1.1 keep-alive and pipelining. Setting this to -1 will allow an unlimited amount of pipelined or keep-alive HTTP requests. If not specified, this attribute is set to 100.

在连接关闭前有多少http request可以同时传输。设为1会直接关闭keep-alive,也即不管客户端报头怎么请求,设成-1会允许无限的同传,如果未指定,默认100个。

keepAliveTimeout
The number of milliseconds this Connector will wait for another HTTP request before closing the connection. The default value is to use the value that has been set for the connectionTimeout attribute.

在关闭http连接前,会等待另外一个request的时间,单位毫秒。默认值由客户端的connectionTimeout指定。
 

总结一下:

  1. 浏览器向服务器发送请求,Tomcat检查是否超过了maxConnections,是否设置了acceptCount,
  2. 没有设置acceptCount,超过了maxConnection则服务器无响应。
  3. 设置了acceptCount,接受连接请求,排队
  4. 连接已建立,检查request请求是否有可用线程,有的话处理,没有排队
  5. 接受request,查看session,进行相应处理
  6. 回传,查看 maxKeepAliveRequests,还有盈余就传,没有等待
  7. 检查是否timeout,是则断开

结语:

虽然梳理了这么一番,但笔者并没有能力进行测试,(Log不知道怎么打),所以有错误请指正!

也请也没有能力测试的朋友,兼听则明,比如关于maxKeepAliveRequest这个配置参数笔者在查阅资料时已经看到不止一种声音了,只能推敲下官方文档,觉得符合逻辑时定下来文中的说法。

参考:

Tomcat官方文档

HttpWebRequest中的KeepAlive - Allan_Dragoon - 博客园

tomcat优化——并发和Tomcat线程数

HTTP的长连接和短连接-烛秋-博客园

session机制详解

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值