apache和tomcat区别是什么?
1、服务器方面
Apache是Web服务器,Tomcat是运行在Apache上的应用服务器
Web服务器传送(serves)页面使浏览器可以浏览,Web服务器专门处理HTTP请求(request),但是应用程序服务器是通过很多协议来为应用程序提供(serves)商业逻辑(business logic)。Apache上的应用程序服务器提供的是客户端应用程序可以调用(call)的方法(methods)。它只是一个servlet(jsp也翻译成servlet)容器,可以认为是Apache的扩展,但是可以独立于apache运行。
2、支持连接方面
Apache是普通服务器,Tomcat是jsp/servlet容器
Apache本身只支持html静态普通网页。不过可以通过插件支持PHP,还可以与Tomcat连通(单向Apache连接Tomcat,就是说通过Apache可以访问Tomcat资源,反之不然),
Tomcat同时也支持HTML、JSP、ASP、PHP、CGI等,其中CGI需要一些手动调试,不过很容易的。
3、侧重点方面
Apache侧重于http server,Tomcat侧重于servlet引擎
如果以standalone方式运行,功能上Tomcat与apache等效支持JSP,但对静态网页不太理想。
扩展资料:
Apache是普通服务器,本身只支持html即普通网页,可以通过插件支持php,还可以与Tomcat连通。Apache只支持静态网页,但像Jsp动态网页就需要Tomcat来处理。
Apache是有C语言实现的,支持各种特性和模块从而来扩展核心功能;Tomcat是Java编写的,更好的支持Servlet和JSP。
对于中小企业来说建立自己的网站,对外展示自己的页面是最平常不过的事情了。目前最流行的建立WWW服务工具就要属Apache与IIS了。那么他们之间都有什么区别呢到底哪个工具才是最适合我们的呢今天就来讨论下这个问题。
一、免费与收费之争:
虽然很多用户都使用IIS建立网站,他是集成于Windows操作系统中的组件。不过要想合法使用IIS就要购买正版Windows操作系统。
反观Apache,他是完全免费的。不需要支付任何费用就可以免费下载并使用了。
结论——Apache免费,IIS收费,前者占优。
二、稳定性:
接下来要比较的就是稳定性了,WWW服务要随时运转正常,一个网站也需要一天24小时,一周七天为公众开放。所以稳定性是IIS和APACHE比较的重点。
IIS在实际使用中经常出现500错误,而且有的时候还会出现莫名其妙的假死现象。用户需要不定期的重新启动IIS服务才能保证网站的正常。
Apache在配置上比IIS要复杂,不过一经设置完毕就可以长期的工作了。大型网站都使用APACHE作为自己的WWW服务提供工具。APACHE的所有配置都保存在配置文件中,使用时完全按照配置文件中记录的信息执行。一般不会发生莫名其妙的假死情况。
小提示:在windows2003系统下使用IIS比用APACHE性能要好。
结论——APACHE稳定,IIS有时假死,前者占优。
三、扩展性:
扩展性是指WWW服务提供工具是否可以应用于多种场合,多种网络情况,多种操作系统。
IIS只能在微软公司的windows操作系统下使用,离开了windows他将一事无成。无法移植到其他类型的操作系统中。
APACHE是个多面手,他不仅仅应用于windows,对于unix,linux以及freebsd等多种操作系统来说他都可以胜任工作。而且不同操作系统的配置步骤基本类似,可移植性非常高。
结论——IIS只能在windows下运行,apache应用范围广。apache获胜。
四、安全性:
经常看到某某网站被黑客攻击或者某某网站被非法用户上传病毒的消息,对于为其他人提供服务的站点来说,安全性是最重要的。如果一个网站连自身安全都没有保证的话,谁愿意浏览和使用呢。
早期的IIS在安全性方面存在着很大的问题,如果使用默认设置的话黑客可以轻松趁虚而入。不过在IIS6中微软公司对安全方面进行了大幅改进。只要保证操作系统补丁更新及时,就可以将网站安全系数尽可能的提高。特别是IIS6与net平台相互倚靠,使安全性几乎完美。
APACHE在安全方面一直做的不错,因为很多用户都是在linux下使用apache,所以操作系统的特点使得linux下的apache具有先天的保护伞,安全性自然没得说。
结论——IIS6以前的版本有安全隐患,IIS6和APACHE一样安全可靠。IIS6与APACHE打个平手。
五、开放性:
所谓开放性就是指是否开放了程序的源代码,众所周知IIS是WINDOWS系统的一部分,所以他的源代码是没有开放的。而apache则不同,最早他是为了类unix系统服务的,所以完全对外开放源代码。任何人都可以分析他的代码,发现其中的漏洞,并发布补丁来弥补该漏洞。
正因为APACHE的这种开放性,也使其安全性大大提高。
结论——IIS不开放代码,APACHE开放源代码。后者获得胜利。
六、难易性:
一个工具使用的难易程度直接影响其用户的多少,特别是网页发布工具。毕竟很多公司希望有自己的网站,但又不希望聘请高薪的网络管理员来维护。因此必然找上手相对容易的工具来搭建自己的站点。
IIS开起来比较简单,很容易就可能让IIS工作,对外发布网站。不过管理员很容易出现错误配置和误操作问题。不过总体说来IIS还是非常容易学的,但要学好他恐怕是件非常困难的事。
APACHE的使用比IIS要难,需要有一定计算机及网络基础的人才可以使用。他的配置也不是图形化的,需要我们通过编辑配置文件来实现。但是单从APACHE的设置上讲,只要我们严格按照帮助文件进行参数设置的话还是没有什么难度的。
结论——IIS容易安装但难精通,APACHE安装相对困难,要想精通也不是一件容易的事。IIS略占优势。
七、编程性:
为了让网页更加丰富多采,更加美观,互动性更好,高手为我们开发了多种组件与控件,那么这些控件在IIS或APACHE下是否正常运行呢
APACHE下的Mod Rewrite功能非常强大,而IIS中的ISAPI的Rewrite需要专门开发,一般初学者是不能够实现的。APACHE可以使用Subversion WebDev以及htaccess功能,还可以使用ForceType。另外IIS对FastCGI的支持也不是很好,所以一些CGI、PHP程序运行起来速度很慢,远不如apache。
结论——不同的环境下使用不同的组件,因为选择IIS还是APACHE由工作环境所决定,这点两者不分高下。
八、支持语言方面:
由于目前建立网站和论坛的语言多种多样,例如ASP,PHP,JSP等语言。那么IIS和APACHE对他们都支持吗
IIS对ASP特别是net运行很稳定,不过对于PHP和JSP就比较麻烦了。PHP需要经过反复配置才能在windows2003上支持。APACHE则能够很好的支持上面提到的几种语言,运行ASP,PHP,JSP都没有任何问题。
结论——APACHE支持语言比较多,IIS支持PHP和JSP时有点麻烦,需要经过一定的配置。APACHE获胜。
九、待遇方面:
提到待遇方面可能很多读者会比较纳闷,怎么IIS和APACHE还存在待遇问题呢其实我们这里要讨论的是网络管理员的待遇。一个会IIS的网络管理员与一个会APACHE的网络管理员,他们的薪水是不一样的。
APACHE最大的好处就是配置参数多,如果要精通APACHE需要很高的水平。所以同等水平的网络管理员会APACHE的要比会IIS的待遇更好。
结论——钱多是获胜的唯一标准,APACHE占优。
总结:
其实今天我们在这里争论IIS好还是APACHE好是没有很大意义的,本文所进行的比较也只是给那些徘徊在网络管理员路口,不知道学习哪个工具来建立网站的读者一点参考。只有你对IIS和APACHE有了一个大概的了解之后,才能为自己的未来进行规划。
总的来说Apache的优点在于在各种开源的WWW服务提供工具中特性最全,支持最广,相对比较稳定的,而且扩展性丰富。不过正因为要考虑扩展性,性能就肯定不会太高,只能保持一个中等的水平。而IIS6在处理连接及事件性能方面还是很强大的,超过了APACHE。另外安全方面IIS6也有了质的飞跃,弥补了以往IIS漏洞漫天的缺陷。如果你的公司网络环境不负责,没有涉及太多的开发的话建议仍然使用IIS6。当然如果是建立在WWW上的开发和调试还是使用APACHE更加顺手。
httpd是Apache超文本传输协议(HTTP)服务器的主程序。被设计为一个独立运行的后台进程,它会建立一个处理请求的子进程或线程的池。通常,httpd不应该被直接调用,而应该在类Unix系统中由 apachectl 调用,在Windows NT/2000/XP/2003中作为服务运行和在Windows 95/98/ME中作为控制台程序运行。
Apache是一个历史悠久并且功能十分强大的WEB服务器,但其丰富的功能对于一个新手来说往往不知道从何下手。我个人感觉Apache的设计充分体现了模块化设计的优势,通过在动态模块加载(DSO)模式下的安装,任何子应用模块都可以通过配置文件的简单修改进行积木式的灵活配置。安装的过程可以从简单的静态html服务开始,一个模块一个模块的学习使用。从单纯的HTML静态服务(core),到复杂的动态页面服务(core + php, core + resin, core + php + mod_gzip, core + resin + mod_expire)。
本文主要从简化安装==>性能调优==>维护方便的角度,介绍了WEB服务的规划、HTTPD安装/应用模块配置、升级/维护等过程。让Apache和PHP,Resin等应用模块的独立升级,完全互不影响。
WEB应用容量规划:根据硬件配置和WEB应用的特点进行WEB服务的规划及一些简单的估算公式;
Apache安装过程:apache的通用的简化安装选项,方便以后的应用的模块化配置;
修改 HARD_SERVER_LIMIT:
vi /path/to/apache_src/src/include/httpdh
#define HARD_SERVER_LIMIT 2560 <===将原来的 HARD_SERVER_LIMIT 256 后面加个“0”
apache编译:
/configure --prefix=/home/apache --enable-shared=max --enable-module=most
可选应用模块/工具的安装:php resin mod_gzip mod_expire及各个模块之间的配合;
mod_php安装:/configure --with-apxs=/home/apache/bin/apxs --enable-track-vars --with-mysql
mod_resin安装:/configure --with-apxs=/home/apache/bin/apxs
mod_gzip安装:修改Makefile中的 apxs路径:然后make make install
工具:日志轮循工具cronolog安装:http://wwwcronologorg
升级/维护:看看通用和模块化的安装过程如何简化了日常的升级/维护工作;
按照以上的方法:系统管理员和应用管理员的职责可以清楚的分开,互相独立。
系统安装:系统管理员的职责就是安装好一台DSO模式的Apache,然后COLON即可,
应用安装:由应用管理员负责具体应用所需要的模块,比如PHP Resin等,并设置httpdconf中相关的配置。
系统升级:系统管理员:升级操作系统/升级Apache
应用升级:应用管理员:升级应用模块,PHP Resin等。
WEB应用的容量规划
Apache主要是一个内存消耗型的服务应用,我个人总结的经验公式:
apache_max_process_with_good_perfermance < (total_hardware_memory / apache_memory_per_process ) 2
apache_max_process = apache_max_process_with_good_perfermance 15
为什么会有一个apache_max_process_with_good_perfermance和apache_max_process呢?原因是在低负载下系统可以使用更多的内存用于文件系统的缓存,从而进一步提高单个请求的响应速度。在高负载下,系统的单个请求响应速度会慢不少,而超过 apache_max_process,系统会因为开始使用硬盘做虚拟内存交换空间而导致系统效率急剧下降。此外,同样的服务:2G内存的机器的 apache_max_process一般只设置到1G内存的17倍,因为Apache本身会因为进程过多导致性能下降。
例子1:
一个apache + mod_php的服务器:一个apache进程一般需要4M内存
因此在一个1G内存的机器上:apache_max_process_with_good_perfermance < (1g / 4m) 2 = 500
apache_max_process = 500 15 = 750
所以规划你的应用让服务尽量跑在500个进程以下以保持比较高的效率,并设置Apache的软上限在800个。
例子2:
一个apache + mod_resin的服务器: 一个apache进程一般需要2M内存
在一个2G内存的机器上:
apache_max_process_with_good_perfermance < (2g / 2m ) 2 = 2000
apache_max_process = 2000 15 = 3000
以上估算都是按小文件服务估算的(一个请求一般大小在20k以下)。对于文件下载类型站点,可能还会受其他因素:比如带宽等的影响。
Apache安装过程
服务器个数的硬上限HARD_SERVER_LIMIT的修改:
在Apache的源代码中缺省的最大进程数是256个,需要修改apache_13xx/src/include/httpdh
#ifndef HARD_SERVER_LIMIT
#ifdef WIN32
#define HARD_SERVER_LIMIT 1024
#elif defined(NETWARE)
#define HARD_SERVER_LIMIT 2048
#else
#define HARD_SERVER_LIMIT 2560 <===将原来的HARD_SERVER_LIMIT 256 后面加个“0”
#endif
#endif
解释:
Apache缺省的最大用户数是256个:这个配置对于服务器内存还是256M左右的时代是一个非常好的缺省设置,但随着内存成本的急剧下降,现在大型站点的服务器内存配置一般比当时要高一个数量级不止。所以256个进程的硬限制对于一台1G内存的机器来说是太浪费了,而且Apache的软上限 max_client是受限于HARD_SERVER_LIMIT的,因此如果WEB服务器内存大于256M,都应该调高Apache的 HARD_SERVER_LIMIT。根据个人的经验:2560已经可以满足大部分小于2G内存的服务器的容量规划了(Apache的软上限的规划请看后面)。
Apache的编译:以下通用的编译选项能满足以后任意模块的安装
/configure --prefix=/another_driver/apache/ --enable-shared=max --enable-module=most
比如:
/configure --prefix=/home/apache/ --enable-shared=max --enable-module=most
解释:
--prefix=/another_driver/apache/:建议将apache服务安装在另外一个驱动设备上的目的在于硬盘往往是一个系统使用寿命最低的设备,因此:将服务数据和系统完全分开,不仅能提高了数据的访问速度,更重要的,大大方便系统升级,应用备份和恢复过程。
--shared-module=max:使用动态加载方式载入子模块会带来5%的性能下降,但和带来的配置方便相比更本不算什么:比如模块升级方便,系统升级风险降低,安装过程标准化等
--enable-module=most:用most可以将一些不常用的module编译进来,比如后面讲到的mod_expire是就不在 apache的缺省常用模块中
如果不想build so, 也可以这样:
/configure \
"--with-layout=Apache" \
"--prefix=/path/to/apache" \
"--disable-module=access" \
"--disable-module=actions" \
"--disable-module=autoindex" \
"--disable-module=env" \
"--disable-module=imap" \
"--disable-module=negotiation" \
"--disable-module=setenvif" \
"--disable-module=status" \
"--disable-module=userdir" \
"--disable-module=cgi" \
"--disable-module=include" \
"--disable-module=auth" \
"--disable-module=asis"
但结果会发现,这样编译对服务性能只能有微小的提高(5%左右),但却失去了以后系统升级和模块升级的灵活性,无论是模块还是Apache本身升级都必须把Apache和PHP的SOURCE加在一起重新编译。
apache的缺省配置文件一般比较大:可以使用去掉注释的方法精简一下:然后再进入具体的培植过程能让你更快的定制出你所需要的。
grep -v "#" httpdconfdefault >httpdconf
需要修改的通用项目有以下几个:
#服务端口,缺省是8080,建议将整个Apache配置调整好后再将服务端口改到正式服务的端口
Port 8080 => 80
#服务器名:缺省没有
ServerName nameexamplecom
#最大服务进程数:根据服务容量预测设置
MaxClients 256 => 800
#缺省启动服务后的服务进程数:等服务比较平稳后,按平均负载下的httpd个数设置就可以
StartServers 5 => 200
不要修改:
以前有建议说修改:
MinSpareServers 5 => 100
MaxSpareServers 10 => 200
但从我的经验看来:缺省值已经是非常优化的了,而且让Apache自己调整子共享进程个数还是比较好的。
特别修改:
在solaris或一些比较容易出现内存泄露的应用上:
MaxRequestsPerChild 0 =>3000
应用模块和工具的安装配置:
由于使用模块动态加载的模式,所以可以方便的通过简单的配置调整来把Apache定制成你需要的:最好把不常用模块全部清除(无论处于安全还是效率)。
比如:对于静态页面服务器:就什么其他子模块都不加载,对于PHP应用就加上PHP模块,对于JAVA应用就把Resin模块加载上。而且各种模块的插拔非常简单,这样调试过程中就可以简单的通过注释掉不需要的模块,而不用重新编译。
一般说来,可以不需要的模块包括:
#LoadModule env_module libexec/mod_envso
#LoadModule negotiation_module libexec/mod_negotiationso
#LoadModule status_module libexec/mod_statusso
#server side include已经过时了
#LoadModule includes_module libexec/mod_includeso
#不需要将没有缺省index文件的目录下所有文件列出
#LoadModule autoindex_module libexec/mod_autoindexso
#尽量不使用CGI:一直是Apache安全问题最多的地方
#LoadModule cgi_module libexec/mod_cgiso
#LoadModule asis_module libexec/mod_asisso
#LoadModule imap_module libexec/mod_imapso
#LoadModule action_module libexec/mod_actionsso
#不使用安全认证可以大大提高访问速度
#LoadModule access_module libexec/mod_accessso
#LoadModule auth_module libexec/mod_authso
#LoadModule setenvif_module libexec/mod_setenvifso
最好保留的有:
#用于定制log格式
LoadModule config_log_module libexec/mod_log_configso
#用于增加文件应用的关联
LoadModule mime_module libexec/mod_mimeso
#用于缺省index文件:indexphp等
LoadModule dir_module libexec/mod_dirso
可用可不用的有:
#比如:需要在~/username/下调试php可以将
LoadModule userdir_module libexec/mod_userdirso
#比如:需要将以前的URL进行转向或者需要使用CGI script-alias
LoadModule alias_module libexec/mod_aliasso
常用的模块:
最常用的可能就是php和JAVA应用服务器的前端,此外,从性能上讲利用mod_gzip可以减少40%左右的流量,减少机器用于传输的负载,而 mod_expires可以减少10%左右的重复请求,让重复的用户对指定的页面请求结果都CACHE在本地,根本不向服务器发出请求。
建议将所有MODULE的配置都放到相应模块的配置内部:<IfModule some_modulec>some_module config </IfModule>
PHP的安装:
/path/to/php_src/configure --with-apxs=/path/to/apache/bin/apxs --with-other-modules-you-need
需要修改的配置:
AddType application/x-httpd-php php php3 any_file_in_php
resin的安装设置:
/path/to/resin/src/configure --with-apxs=/path/to/apache/bin/apxs
具体的resin设置放在另外一个文件中:比如/home/resin/conf/resinconf
<IfModule mod_cauchoc>
CauchoConfigFile /path/to/apache/conf/resinconf
</IfModule>
mod_expires的安装配置:
<IfModule mod_expiresc>
ExpiresActive on
ExpiresByType image/gif "access plus 1 month"
ExpiresByType text/css "now plus 1 month"
ExpiresDefault "now plus 1 day"
</IfModule>
注释:
所有的gif文件1个月以后过期
所有的文件缺省1天以后过期
mod_gzip的安装
http://wwwchedongcom/tech/compresshtml
日志的轮循:cronolog的安装和设置
cronolog可以非常整齐的将日志按天轮循存储
缺省编译安装到/usr/local/bin/下,只需要将配置改成:
CustomLog "|/usr/local/sbin/cronolog /home/apache/logs/%w/access_log" combined
日志将按天截断并存放在以星期为目录名的目录下:比如:log/1是周一,log/5是周五, log/0是周日
用gzip压缩每天的日志:
30 4 /usr/bin/gzip -f /home/apache/logs/`date -d yesterday +%w`/access_log
日志的定期删除:
30 5 /usr/bin/find /home/apache/logs/ -name access_loggz -mtime +3 |xargs -r /bin/rm -f
升级维护:
由于使用动态模块加载方式(DSO模式)安装Apache,Apache的HTTPD核心服务和应用模块以及应用模块之间都变的非常灵活,建议将所有独立模块的配置都放在
<IfModule mod_name>
CONFIGURATIONS
</IfModule>
里,这样配置非常容易通过屏蔽某个模块来进行功能调整:比如:
#AddModule mod_gzipc
就屏蔽了mod_gzip,而其他模块不首任何影响。
安装和维护过程:
系统安装:系统管理员的职责就是安装系统和一个按照DSO模式安装的Apache,然后COLON。
应用安装:由应用管理员负责具体应用所需要的模块并设置HTTPD。
系统升级:系统管理员:升级系统/升级Apache
应用升级:应用管理员:升级应用模块:PHP CAUCHO等
系统备份/恢复:如果Apache不在缺省的系统盘上,只需要将Apache目录备份就可以了,遇到系统分区的硬件问题直接使用预先准备好的系统COLON,再直接将Apache所在物理盘恢复就行了。
系统管理员:Apache的最简化安装 OS + Apache (httpd core only)
应用管理员:应用模块定制 纯静态页面服务
core
PHP动态页面
core+so
+php
JAVA应用
core+so
+caucho
+ssl
应用例子: wwwexamplecom
imageexamplecom
bbsexamplecom mallexamplecom
例子:Apache和PHP模块的独立升级。
如果Apache是按照以下方式安装:
/configure --prefix=/home/apache --enable-shared=max --enable-module=most
PHP是按照以下方式安装:
/configure --with-apxs=/home/apache/bin/apxs --enable-track-vars --with-mysql
以后单独升级Apache的时候,仍然是:
/configure --prefix=/home/apache --enable-shared=max --enable-module=most
make
su
#/home/apache/bin/apachectl stop
#make install
单独升级php时,仍然是:
/configure --with-apxs=/home/apache/bin/apxs --enable-track-vars --with-mysql
make
su
#/home/apache/bin/apachectl stop
#make install
#/home/apache/bin/apachectl start
基于反相代理的WEB加速:
squid和mod_proxy都可以实现反相代理加速。而基于缓存的代理加速比起原有WEB服务,速度会有数量级的提升。
小提示:
Apache安装后,缺省根目录下没有但很有用的2个文件:
Apache的发展时期很长,优点也非常多,它兴起的年代,互联网产业远远比不上现在。所以它被设计为一个重量级的。它不支持高并发的服务器。在Apache上运行数以万计的并发访问,会导致服务器消耗大量内存。操作系统对其进行进程或线程间的切换也消耗了大量的CPU资源,导致HTTP请求的平均响应速度降低。Nginx使用基于事件驱动架构,使得其可以支持数以百万级别的TCP连接,高度的模块化和自由软件许可证是的第三方模块层出不穷,同时Nginx是一个跨平台服务器,可以运行Linux,Windows,FreeBSD,Solaris,AIX,MacOS等操作系统上,这些优秀的设计可以带来极大的稳定性,因此,Nginx也成为了时下最热门的Web服务器。
0条评论