Tomcat 安全配置与性能优化

一.Tomcat内存优化

1.JAVA_OPTS参数说明

Tomcat内存优化主要是对 tomcat 启动参数优化，我们可以在 tomcat 的启动脚本 catalina.sh 中设置 JAVA_OPTS参数。

服务器参数配置

配置完成后可重启Tomcat ，通过以下命令进行查看配置是否生效：

1.  首先查看Tomcat 进程号：

 ps -ef|grep java

  

我们可以看到Tomcat 进程号是 12222 。

 

1.  查看是否配置生效：

 sudo jmap -heap 12222

  

我们可以看到MaxHeapSize 等参数已经生效。

 

优化 server.xml

Tomcat的主配置文件，该文件中包含很多主要元素，比如Service、Connector、Host等，这些元素都会创建软件"对象"、排序及进程管道中设置的这些元素嵌套方，使我们可以执行过滤、分组等工作。

如果要对该文件做优化，我们需要先了解该文件的结构！

server.xml的结构图：

该文件描述了如何启动Tomcat Server

<Server>
  <Listener />
  <GlobaNamingResources>
  </GlobaNamingResources
  <Service>
    <Connector />
    <Engine>
      <Logger />
      <Realm />
         <host>
           <Logger />
           <Context />
         </host>
    </Engine>
  </Service>
</Server>

针对该文件，我们需要优化的点有如下：

1、 maxThreads 连接数限制

maxThreads 是 Tomcat 所能接受最大连接数。一般设置不要超过8000以上，如果你的网站访问量非常大可能使用运行多个Tomcat实例的方法， 即，在一个服务器上启动多个tomcat然后做负载均衡处理。

这里还需要注意的一点是，tomcat 和 php 不同。php可以按照cpu和内存的情况去配置连接数，上万很正常。而 java 还需要注意 jvm 的参数配置。如果不注意就会因为jvm参数过小而崩溃。

2、多虚拟主机

强烈建议不要使用 Tomcat 的虚拟主机，推荐每个站点使用一个实例。即，可以启动多个 Tomcat，而不是启动一个 Tomcat 里面包含多个虚拟主机。因为 Tomcat是多线程，共享内存，任何一个虚拟主机中的应用崩溃，都会影响到所有应用程序。虽然采用多实例的方式会产生过多的开销，但至少保障了应用程序的隔离和安全。

3、压错传输

tomcat作为一个应用服务器，也是支持 gzip 压缩功能的。我们可以在 server.xml 配置文件中的 Connector 节点中配置如下参数，来实现对指定资源类型进行压缩。

compression="on"             # 打开压缩功能 
compressionMinSize="50"      # 启用压缩的输出内容大小，默认为2KB 
noCompressionUserAgents="gozilla, traviata"      # 对于以下的浏览器，不启用压缩 
compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain"　# 哪些资源类型需要压缩

提示：

Tomcat 的压缩是在客户端请求服务器对应资源后，从服务器端将资源文件压缩，再输出到客户端，由客户端的浏览器负责解压缩并浏览。相对于普通的浏览过程 HTML、CSS、Javascript和Text，它可以节省40% 左右的流量。更为重要的是，它可以对动态生成的，包括CGI、PHP、JSP、ASP、Servlet,SHTML等输出的网页也能进行压缩，压缩效率也很高。但是， 压缩会增加 Tomcat 的负担，因此最好采用Nginx + Tomcat 或者 Apache + Tomcat 方式，将压缩的任务交由 Nginx/Apache 去做。

一旦启用了这个压缩功能后，我们怎么来测试压缩是否有效呢？首先Tomcat是根据浏览器请求头中的accept-encoding来判断浏览器是否支持 压缩功能，如果这个值包含有gzip，就表明浏览器支持gzip压缩内容的浏览，所以我们可以用httpclient来写一个这样的简单测试程序

import org.apache.commons.httpclient.HttpClient;
import org.apache.commons.httpclient.methods.GetMethod;
 
public class HttpTester {
 
public static void main(String[] args) throws Exception{
HttpClient http = new HttpClient();
GetMethod get = new GetMethod("http://www.dlog.cn/js/prototype.js");
try{
get.addRequestHeader("accept-encoding", "gzip,deflate");
get.addRequestHeader("user-agent", "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar; Maxthon 2.0)");
int er = http.executeMethod(get);
if(er==200){
System.out.println(get.getResponseContentLength());
String html = get.getResponseBodyAsString();
System.out.println(html);
System.out.println(html.getBytes().length);
}
}finally{
get.releaseConnection();
}
}
 
}

执行这个测试程序，看看它所输出的是什么内容，如果输出的是一些乱码，以及打印内容的长度远小于实际的长度，那么恭喜你，你的配置生效了，你会发现你网站的浏览速度比以前快多了。

4、管理AJP端口

AJP是为 Tomcat 与 HTTP 服务器之间通信而定制的协议，能提供较高的通信速度和效率。如果tomcat前端放的是apache的时候，会使用到AJP这个连接器。由于我们公司前端是由nginx做的反向代理，因此不使用此连接器，因此需要注销掉该连接器。

<!--
    <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
-->

5、更改关闭 Tomcat 实例的指令

server.xml中定义了可以直接关闭 Tomcat 实例的管理端口。我们通过 telnet 连接上该端口之后，输入 SHUTDOWN （此为默认关闭指令）即可关闭 Tomcat 实例（注意，此时虽然实例关闭了，但是进程还是存在的）。由于默认关闭 Tomcat 的端口和指令都很简单。默认端口为8005，指令为SHUTDOWN 。因此我们需要将关闭指令修改复杂一点。

当然，在新版的 Tomcat 中该端口仅监听在127.0.0.1上，因此大家也不必担心。除非黑客登陆到tomcat本机去执行关闭操作。

修改实例：

<Server port="8005" shutdow n="9SDKJ29jksjf23sjf0LSDF92JKS9DKkjsd">

6、更改 Tomcat 的服务监听端口

一般公司的 Tomcat 都是放在内网的，因此我们针对 Tomcat 服务的监听地址都是内网地址。

修改实例：

<Connector port="8080" address="172.16.100.1" />

7、关闭war自动部署

默认 Tomcat 是开启了对war包的热部署的。为了防止被植入木马等恶意程序，因此我们要关闭自动部署。

修改实例：

<Host name="localhost"  appBase=""
            unpackWARs="false" autoDeploy="false">

 

二.Tomcat并发优化

1.调整连接器connector的并发处理能力

在Tomcat 配置文件 server.xml 中的 <Connector ... /> 配置中

1.参数说明

maxThreads  客户请求最大线程数

minSpareThreads    Tomcat初始化时创建的 socket 线程数

maxSpareThreads   Tomcat连接器的最大空闲 socket 线程数

minProcessors：最小空闲连接线程数，用于提高系统处理性能，默认值为 10

maxProcessors：最大连接线程数，即：并发处理的最大请求数，默认值为 75

acceptCount：允许的最大连接数，应大于等于 maxProcessors ，默认值为 100

enableLookups：是否反查域名，取值为： true 或 false 。为了提高处理能力，应设置为 false

redirectPort        在需要基于安全通道的场合，把客户请求转发到基于SSL 的 redirectPort 端口

acceptAccount       监听端口队列最大数，满了之后客户请求会被拒绝（不能小于maxSpareThreads  ）

connectionTimeout：网络连接超时，单位：毫秒。设置为 0 表示永不超时，这样设置有隐患的。通常可设置为30000 毫秒。

URIEncoding    URL统一编码

其中和最大连接数相关的参数为maxProcessors 和 acceptCount 。如果要加大并发连接数，应同时加大这两个参数。

web server允许的最大连接数还受制于操作系统的内核参数设置，通常 Windows 是 2000 个左右， Linux 是1000 个左右。

2.Tomcat中的配置示例

<Connector port="9027"   
                protocol="HTTP/1.1"  
                maxHttpHeaderSize="8192"  
                maxThreads="1000"  
                minSpareThreads="100"  
                maxSpareThreads="1000"  
                minProcessors="100"  
                maxProcessors="1000"  
                enableLookups="false"  
                URIEncoding="utf-8"  
                acceptCount="1000"  
                redirectPort="8443"  
                disableUploadTimeout="true"/>

3.Tomcat缓存优化

 

tomcat的maxThreads、acceptCount（最大线程数、最大排队数）

<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443"
maxThreads="800" acceptCount="1000"/> 

tomcate -->config --> server.xml

 

其中最后两个参数意义如下：

maxThreads：tomcat起动的最大线程数，即同时处理的任务个数，默认值为200

acceptCount：当tomcat起动的线程数达到最大时，接受排队的请求个数，默认值为100

 

这两个值如何起作用，请看下面三种情况

情况1：接受一个请求，此时tomcat起动的线程数没有到达maxThreads，tomcat会起动一个线程来处理此请求。

情况2：接受一个请求，此时tomcat起动的线程数已经到达maxThreads，tomcat会把此请求放入等待队列，等待空闲线程。

情况3：接受一个请求，此时tomcat起动的线程数已经到达maxThreads，等待队列中的请求个数也达到了acceptCount，此时tomcat会直接拒绝此次请求，返回connection refused

maxThreads如何配置

一般的服务器操作都包括量方面：1计算（主要消耗cpu），2等待（io、数据库等）

第一种极端情况，如果我们的操作是纯粹的计算，那么系统响应时间的主要限制就是cpu的运算能力，此时maxThreads应该尽量设的小，降低同一时间内争抢cpu的线程个数，可以提高计算效率，提高系统的整体处理能力。

第二种极端情况，如果我们的操作纯粹是IO或者数据库，那么响应时间的主要限制就变为等待外部资源，此时maxThreads应该尽量设的大，这样才能提高同时处理请求的个数，从而提高系统整体的处理能力。此情况下因为tomcat同时处理的请求量会比较大，所以需要关注一下tomcat的虚拟机内存设置和linux的open file限制。

我在测试时遇到一个问题，maxThreads我设置的比较大比如3000，当服务的线程数大到一定程度时，一般是2000出头，单次请求的响应时间就会急剧的增加，

百思不得其解这是为什么，四处寻求答案无果，最后我总结的原因可能是cpu在线程切换时消耗的时间随着线程数量的增加越来越大，

cpu把大多数时间都用来在这2000多个线程直接切换上了，当然cpu就没有时间来处理我们的程序了。

以前一直简单的认为多线程=高效率。。其实多线程本身并不能提高cpu效率，线程过多反而会降低cpu效率。

当cpu核心数<线程数时，cpu就需要在多个线程直接来回切换，以保证每个线程都会获得cpu时间，即通常我们说的并发执行。

所以maxThreads的配置绝对不是越大越好。

现实应用中，我们的操作都会包含以上两种类型（计算、等待），所以maxThreads的配置并没有一个最优值，一定要根据具体情况来配置。

最好的做法是：在不断测试的基础上，不断调整、优化，才能得到最合理的配置。

acceptCount的配置，我一般是设置的跟maxThreads一样大，这个值应该是主要根据应用的访问峰值与平均值来权衡配置的。

如果设的较小，可以保证接受的请求较快相应，但是超出的请求可能就直接被拒绝

如果设的较大，可能就会出现大量的请求超时的情况，因为我们系统的处理能力是一定的。

提示

很多做过php运维的朋友在这里会犯一个大错误，php优化服务器通常怎做法是安装cpu以及内存的情况配置连接数，连接数过万都很正常，但java不同jvm配置要非常小心，稍有差错就会崩溃。

maxThreads 配置要结合 JVM -Xmx 参数调整，也就是要考虑内存开销。

 

在线上环境中我们是采用了tomcat作为Web服务器，它的处理性能直接关系到用户体验，在平时的工作和学习中，归纳出以下七种调优经验。

1. 服务器资源

    服务器所能提供CPU、内存、硬盘的性能对处理能力有决定性影响。
    (1) 对于高并发情况下会有大量的运算，那么CPU的速度会直接影响到处理速度。
    (2) 内存在大量数据处理的情况下，将会有较大的内存容量需求，可以用-Xmx -Xms -XX:MaxPermSize等参数对内存不同功能块进行划分。我们之前就遇到过内存分配不足，导致虚拟机一直处于full GC，从而导致处理能力严重下降。
    (3) 硬盘主要问题就是读写性能，当大量文件进行读写时，磁盘极容易成为性能瓶颈。最好的办法还是利用下面提到的缓存。

2. 利用缓存和压缩

    对于静态页面最好是能够缓存起来，这样就不必每次从磁盘上读。这里我们采用了Nginx作为缓存服务器，将图片、css、js文件都进行了缓存，有效的减少了后端tomcat的访问。

    另外，为了能加快网络传输速度，开启gzip压缩也是必不可少的。但考虑到tomcat已经需要处理很多东西了，所以把这个压缩的工作就交给前端的Nginx来完成。可以参考之前写的《利用nginx加速web访问》。

    除了文本可以用gzip压缩，其实很多图片也可以用图像处理工具预先进行压缩，找到一个平衡点可以让画质损失很小而文件可以减小很多。曾经我就见过一个图片从300多kb压缩到几十kb，自己几乎看不出来区别。

3. 采用集群

    单个服务器性能总是有限的，最好的办法自然是实现横向扩展，那么组建tomcat集群是有效提升性能的手段。我们还是采用了Nginx来作为请求分流的服务器，后端多个tomcat共享session来协同工作。可以参考之前写的《利用nginx+tomcat+memcached组建web服务器负载均衡》。

4. 优化tomcat参数

    这里以tomcat7的参数配置为例，需要修改conf/server.xml文件，主要是优化连接配置，关闭客户端dns查询。

<Connector port="8080"              
protocol="org.apache.coyote.http11.Http11NioProtocol"             
connectionTimeout="20000" 
redirectPort="8443"              
maxThreads="500" 
minSpareThreads="20"             
acceptCount="100" 
disableUploadTimeout="true"            
enableLookups="false" 
URIEncoding="UTF-8" />

5. 改用APR库

    tomcat默认采用的BIO模型，在几百并发下性能会有很严重的下降。tomcat自带还有NIO的模型，另外也可以调用APR的库来实现操作系统级别控制。

<Connector port="80" protocol="HTTP/1.1"        connectionTimeout="20000"         redirectPort="8443" />

修改为：

<Connector port="80" protocol="org.apache.coyote.http11.Http11NioProtocol "   connectionTimeout="20000"     redirectPort="8443" />

    NIO模型是内置的，调用很方便，只需要将上面配置文件中protocol修改成org.apache.coyote.http11.Http11NioProtocol，重启即可生效。上面配置我已经改过了，默认的是HTTP/1.1。

    APR则需要安装第三方库，在高并发下会让性能有明显提升。具体安装办法可以参考http://www.cnblogs.com/huangjingzhou/articles/2097241.html。安装完成后重启即可生效。如使用默认protocal就是apr，但最好把将protocol修改成org.apache.coyote.http11.Http11AprProtocol，会更加明确。

    在官方找到一个表格详细说明了这三种方式的区别：

	Java Blocking Connector	Java Nio Blocking Connector	APR/native Connector
	BIO	NIO	APR
Classname	AjpProtocol	AjpNioProtocol	AjpAprProtocol
Tomcat Version	3.x onwards	7.x onwards	5.5.x onwards
Support Polling	NO	YES	YES
Polling Size	N/A	maxConnections	maxConnections
Read Request Headers	Blocking	Sim Blocking	Blocking
Read Request Body	Blocking	Sim Blocking	Blocking
Write Response	Blocking	Sim Blocking	Blocking
Wait for next Request	Blocking	Non Blocking	Non Blocking
Max Connections	maxConnections	maxConnections	maxConnections

6. 优化网络

    Joel也明确提出了优化网卡驱动可以有效提升性能，这个对于集群环境工作的时候尤为重要。由于我们采用了linux服务器，所以优化内核参数也是一个非常重要的工作。给一个参考的优化参数：

1. 修改/etc/sysctl.cnf文件，在最后追加如下内容：  

net.core.netdev_max_backlog = 32768 
net.core.somaxconn = 32768 
net.core.wmem_default = 8388608 
net.core.rmem_default = 8388608
net.core.rmem_max = 16777216
 net.core.wmem_max = 16777216 
net.ipv4.ip_local_port_range = 1024 65000 net.ipv4.route.gc_timeout = 100 
net.ipv4.tcp_fin_timeout = 30 
net.ipv4.tcp_keepalive_time = 1200 
net.ipv4.tcp_timestamps = 0 
net.ipv4.tcp_synack_retries = 2 
net.ipv4.tcp_syn_retries = 2 
net.ipv4.tcp_tw_recycle = 1 
net.ipv4.tcp_tw_reuse = 1 
net.ipv4.tcp_mem = 94500000 915000000 927000000 net.ipv4.tcp_max_orphans = 3276800 net.ipv4.tcp_max_syn_backlog = 65536

2. 保存退出，执行sysctl -p生效

7. 让测试说话

    优化系统最忌讳的就是只调优不测试，有时不适当的优化反而会让性能更低。以上所有的优化方法都要在本地进行性能测试过后再不断调整参数，这样最终才能达到最佳的优化效果。

 

补充Bio、Nio、Apr模式的测试结果：

    对于这几种模式，我用ab命令模拟1000并发测试10000词，测试结果比较意外，为了确认结果，我每种方式反复测试了10多次，并且在两个服务器上都测试了一遍。结果发现Bio和Nio性能差别非常微弱，难怪默认居然还是Bio。但是采用apr，连接建立的速度会有50%～100%的提升。直接调用操作系统层果然神速啊，这里强烈推荐apr方式！

 

Tomcat的四种基于HTTP协议的Connector性能比较

Tomcat从5.5版本开始，支持以下四种Connector的配置分别为：

---

<Connector port="8081" protocol="org.apache.coyote.http11.Http11NioProtocol"                           connectionTimeout="20000" redirectPort="8443"/>
<Connector port="8081" protocol="HTTP/1.1" connectionTimeout="20000"
               redirectPort="8443"/> 
<Connector executor="tomcatThreadPool"
               port="8081" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" />
<Connector executor="tomcatThreadPool"
               port="8081" protocol="org.apache.coyote.http11.Http11NioProtocol"
               connectionTimeout="20000"
               redirectPort="8443" />

我们姑且把上面四种Connector按照顺序命名为 NIO, HTTP, POOL, NIOP

为了不让其他因素影响测试结果，我们只对一个很简单的jsp页面进行测试，这个页面仅仅是输出一个Hello World。假设地址是 http://tomcat1/test.jsp

我们依次对四种Connector进行测试，测试的客户端在另外一台机器上用ab命令来完成，测试命令为： ab -c 900 -n 2000 http://tomcat1/test.jsp ，最终的测试结果如下表所示(单位:平均每秒处理的请求数)：

 

NIO HTTP POOL NIOP

281	65	208	365
666	66	110	398
692	65	66	263
256	63	94	459
440	67	145	363

由这五组数据不难看出，HTTP的性能是很稳定，但是也是最差的，而这种方式就是Tomcat的默认配置。NIO方式波动很大，但没有低于280 的，NIOP是在NIO的基础上加入线程池，可能是程序处理更复杂了，因此性能不见得比NIO强；而POOL方式则波动很大，测试期间和HTTP方式一样，不时有停滞。

由于linux的内核默认限制了最大打开文件数目是1024，因此此次并发数控制在900。

尽管这一个结果在实际的网站中因为各方面因素导致，可能差别没这么大，例如受限于数据库的性能等等的问题。但对我们在部署网站应用时还是具有参考价值的。

1. JVM

1.1. 使用 Server JRE 替代JDK。

服务器上不要安装JDK，请使用 Server JRE. 服务器上根本不需要编译器，代码应该在Release服务器上完成编译打包工作。

理由：一旦服务器被控制，可以防止在其服务器上编译其他恶意代码并植入到你的程序中。

 

 

 

3. Tomcat 安全配置

3.1. 安装后初始化配置

当Tomcat完成安装后你首先要做的事情如下：

首次安装完成后立即删除webapps下面的所有代码

rm -rf /srv/apache-tomcat/webapps/*

注释或删除 tomcat-users.xml 所有用户权限，看上去如下：

# cat conf/tomcat-users.xml
<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
</tomcat-users>

隐藏Tomcat版本信息

vim $CATALINA_HOME/conf/server.xml

    <Connector port="80" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443"
				maxThreads="8192"
				minSpareThreads="64"
				maxSpareThreads="128"
				acceptCount="128"
				enableLookups="false"
                server="Neo App Srv 1.0"/>



# curl -I http://localhost:8080/
HTTP/1.1 400 Bad Request
Transfer-Encoding: chunked
Date: Thu, 20 Oct 2011 09:51:55 GMT
Connection: close
Server: Neo App Srv 1.0

服务器信息已经被改为 Server: Neo App Srv 1.0

3.2. 启动用户与端口

不要使用root用户启动tomcat，Java程序与C程序不同。nginx,httpd 使用root用户启动守护80端口，子进程/线程会通过setuid(),setgid()两个函数切换到普通用户。即父进程所有者是root用户，子进程与多线程所有者是一个非root用户，这个用户没有shell，无法通过ssh与控制台登陆系统，Java 的JVM 是与系统无关的，是建立在OS之上的，你使用什么用户启动Tomcat，那麽Tomcat 就会继承该所有者的权限。

这造成了一个问题，Linux系统小于1024的端口只有root可以使用，这也是为什么Tomcat默认端口是8080。如果你想使用80端口只能使用root启动Tomcat。这有带来了很多安全问题。

解决方案是创建一个不同用户，如：

groupadd -g 80 daemon
adduser -o --home /daemon --shell /sbin/nologin --uid 80 --gid 80 -c "Web Server" daemon

注意 /sbin/nologin , 意味着该用户不能登录，同时我也没有给它指定密码，这个用户只能用于启动tomcat

chown daemon:daemon -R /srv/*
su - daemon -c "/srv/apache-tomcat/bin/startup.sh"

接下来解决80端口问题, 思路就是80去调用8080，或者映射端口。

下面是影射方案,80 跳转 8080

iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080

取消跳转
iptables -t nat -D PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080

查看规则
iptables -t nat -L

另一个就是从80请求去调用8080的方案

这个方案可以在 Tomcat 前段增加反向代理，例如：Nginx,Apache,Squid,Varnish或者F5， Array这类设备等等

3.3. 应用程序安全

关闭war自动部署 unpackWARs="false" autoDeploy="false"。防止被植入木马等恶意程序

应用程序部署与tomcat启动,不能使用同一个用户。

我的tomcat 安装在 /srv目录下，Tomcat启动用户为daemon; 应用程序放在/www目录下www所有者是www用户。这样的目的是一旦tomcat被植入web shell程序，它将不能创建或编辑/www目录下面的任何内容。

adduser --home /www -c "Web Application" www

3.4. JSESSIONID

修改 Cookie 变量 JSESSIONID， 这个cookie 是用于维持Session关系。建议你改为PHPSESSID。

tomcat-user.xm 安全

查看进程帐户应为专用非root帐号。

查看tomcat配置文件server.xml是否有设置connectionTimeout值，

符合：设置账户自动登出。

查看配置文件是否设置ip登陆范围限制

符合：配置文件中含有登陆ip限制。 不符合：没设置登陆ip限制。

检查tomcat/conf/web.xml配置文件，查看是否含有如下配置

<security-constraint>    
    <web-resource-collection>    
       <url-pattern>/*</url-pattern>    
       <http-method>PUT</http-method>    
    <http-method>DELETE</http-method>    
    <http-method>HEAD</http-method>    
    <http-method>OPTIONS</http-method>    
    <http-method>TRACE</http-method>
    </web-resource-collection>    
       <auth-constraint>    
       </auth-constraint>    
    </security-constraint>    
    <login-config>    
        <auth-method>BASIC</auth-method>