WEB服务器多框架的解决方案
【摘要】在INTRANET上设计基于WEB的MIS时，大批量数据录入变成了操作上的瓶颈，并给WEB SERVER与DATABASE造极大的负担。
为解决这个问题，我们设计了多框架结构，将应用的功能进行细分，然后交给各框架分别完成，这种分工协作方式可以使操作界面上的数据实现受控的部分刷新，有效地减小了网络的数据传输量，缩短了各部分的处理时间，同时了也大大减轻了WEB SERVER与DATABASE的系统负担。
多框架解决方案采用ASP（ActiveX Server Pages）及ADO(ActiveX Data Objects)完成与数据库的交互工作。采用DOM技术解决和框架之间的协作问题。
关键词：多框架
*注：本文中讨论的方案中WEB服务器为IIS4.0、客户端浏览器为IE4.0以上版本。
一、问题的提出
最初，我们采用ASP及ADO技术在INTRANET上设计基于WEB的MIS（下文简称MIS）时，沿用了以往设计WEB站点时的设计习惯。但随着设计的深入，我们发现，现有的系统结构无法承担大批量的数据录入工作，因此，必须重新构造系统的总体设计结构。
MIS与普通的WEB站点之间最大的区别在于处理信息的方式。普通WEB站点的主要功能是发布信息，采集信息只是它极小的一部分功能，而且这些信息采集功能也都是比较简单的。但对于MIS系统来说，信息的采集及维护工作占有比较高的比例，在这些信息采集功能中还存在一些较为复杂及大批量的数据录入功能，这些功能成为了系统中的设计难点。
二、问题的分析
当一个系统涉及到复杂及大批量的数据录入功能时，同时也就涉及到了响应速度及界面的问题。在以往的C/S方式中，客户端的录入速度由录入员来控制，一般情况下，当录入员熟悉了操作方式之后，录入速度是不受系统限制的。但在WEB方式下，页面采用完全刷新方式，每次的交互操作至少要造成一个页面的刷新。这种刷新的工作不仅更新了数据，也将界面上的一些固定内容重新加载了一遍。对于普通用户来说，这种短时间的刷新并不会造成影响；但对于长时间进行操作的录入员来说，录入一条数据就要等待一段时间（这一段时间可能是2-3秒，也可能是十几秒甚至几分钟），是绝对不能接受的。即使，网络有足够的带宽，页面的重载也会造成一种闪动的效果，这种一闪一闪的刷新造成录入员必须重新识别页面上的各种元素，不仅也会拖慢了他们的录入速度，还造成眼睛的快速疲劳。
三、解决方案
如果能够“不”刷新页面而“快速更新”页面中的数据，问题应该能够解决了。而且页面由于没有刷新，一些必须由服务器保存的状态信息也能够在客户端保存下来了，从而减轻服务器的负担。那么如何达到这个目标呢？下面将详细讨论。
1．设计思路
首先，我们确立采用多框架建立页面。框架(Frames)其实不是什么新东西，许多站点上都用它来完成显示固定标题及菜单的功能。采用框架能够避免一些页面的重复访问。但是如果结合使用DOM（Document objects model)，框架可以完成许多细致的工作。
按照DOM的定义，框架可以被当作一个对象。假设我们建立了一个框架，并给它取名为A，则对于建立框架的页面来说，A是Frames集合中的一个成员，而对于A中的页面来说，A相当于window对象。因些，虽然框架之间不存在从属关系，但可以通过它们的父页面（对象）建立各框架之间的关系。
如右图所示：框架之间能够进行相互控制与数据传送。
1）．在框架A中用的是最常用的框架控制方式，利用＜A TARGET＝“B” HREF=”URL”＞ 控制B框架中的页面重载。
2）．在框架B中，通过按钮的点击事件对框架C进行控制，这里的控制是通过DOM来实现的。(假设B中按钮Name值为“B1”)
控制C中的URL，在按钮的ONCLICK事件中加入以下代码：(VBScript)
sub b1_onclick
set Bframe = parent.B
Bframe.location.href = “URL”
End sub
控制C中的文本框内容，在按钮的ONCLICK事件中加入以下代码：(VBScript)
sub b1_onclick
set Bframe = parent.B
Brame.document.all.txt1.value = “刘念”
‘txt1是C框架中文本框的Value值
end sub
2．新的框架结构
如上图，我们定义了一个新的框架结构。在新的框架结构中，除了用来放置一、二级菜单的MENU1、MENU2和用来放置三级菜单及具体应用功能的Aapp之外，还增加了三个专门用来处理数据的框架（在上图中用虚线表示）。这三个框架不需要界面，在应用执行的时候是看不见的。
淘宝Web服务器，Tengine-1.2.5 版本发布
我们很高兴的告诉大家，Tengine-1.2.5 版本正式发布了。您可以在这里下载：http://tengine.taobao.org/download/tengine-1.2.4.tar.gz或者可以在github上检出代码：https://github.com/taobao/tengine
本次发布的亮点是新增加的upstream_check模块，可以用来对后端服务器进行主动健康检查，以自动的下线失效的服务器。当您使用Tengine作为负载均衡（反向代理）时，这个功能非常有用。
其他的更新包括：
* Feature：允许syslog输出日志时指定程序的标识（program identifier）；* Change：合并nginx-1.0.14至nginx-1.0.15之间的修改；* Change：将accept_mutex_delay的默认值从500毫秒更改为100毫秒以提高性能；* Bugfix：修复syslog的一个在后端服务器连接不上导致端错误的bug；* Bugfix：修复access_log可能和buffer参数冲突的bug；
Tengine是由淘宝网发起的Web服务器项目。它在Nginx的基础上，针对大访问量网站的需求，添加了很多高级功能和特性。Tengine的 性能和稳定性已经在大型的网站如淘宝网，天猫商城等得到了很好的检验。它的最终目标是打造一个高效、稳定、安全、易用的Web平台。
从2011年12月开始，Tengine成为一个开源项目。
以下沿引项目主页上的特性介绍：
继承Nginx-1.0.14的所有特性，100%兼容Nginx的配置；输入过滤器机制支持。通过使用这种机制Web应用防火墙的编写更为方便；组合多个CSS、JavaScript文件的访问请求变成一个请求；支持管道（pipe）和syslog（本地和远端）形式的日志以及日志抽样；自动根据CPU数目设置进程个数和绑定CPU亲缘性；监控系统的负载和资源占用从而对系统进行保护；显示对运维人员更友好的出错信息，便于定位出错机器；更强大的防攻击（访问速度限制）模块；backtrace模块，程序崩溃的时候可以显示出错的调用栈；更方便的命令行参数，如列出编译的模块列表、支持的指令等；可以根据访问文件类型设置过期时间；
在Tengine的网站上可以浏览更多信息：http://tengine.taobao.org
Hiawatha 8.4发布，安全的Web服务器
Hiawatha 是一个Linux/UNIX下安全的Web服务器，其设计的最主要的目的就是安全，当然它也是快速的而且易于配置。
Hiawatha 8.4 的改进内容：
MaxServerLoad option added.Bugfix: invalid reverse proxy request when URL parameters are present.PolarSSL updated to version 1.1.4.Small bugfixes and improvements.
RHEL/CentOS上为Web服务器架设 “XR”（Crossroads） 负载均衡器
Crossroads 是一个独立的服务，它是一个用于Linux和TCP服务的开源负载均衡和故障转移实用程序。它可用于HTTP，HTTPS，SSH，SMTP 和 DNS 等，它也是一个多线程的工具，在提供负载均衡服务时，它可以只使用一块内存空间以此来提高性能。
首先来看看 XR 是如何工作的。我们可以将 XR 放到网络客户端和服务器之间，它可以将客户端的请求分配到服务器上以平衡负载。
如果一台服务器宕机，XR 会转发客户端请求到另一个服务器，所以客户感觉不到停顿。看看下面的图来了解什么样的情况下，我们要使用 XR 处理。
延伸阅读：
安装 XR Crossroads 负载均衡器
这里有两个 Web 服务器，一个网关服务器，我们将在网关服务器上安装和设置 XR 以接收客户端请求，并分发到服务器。
XR Crossroads 网关服务器：172.16.1.204
Web 服务器01：172.16.1.222
Web 服务器02：192.168.1.161
在上述情况下，我们网关服务器（即 XR Crossroads）的IP地址是172.16.1.222，webserver01 为172.16.1.222，它监听8888端口，webserver02 是192.168.1.161，它监听端口5555。
现在，我们需要的是均衡所有的请求，通过 XR 网关从网上接收请求然后分发它到两个web服务器已达到负载均衡。
第1步：在网关服务器上安装 XR Crossroads 负载均衡器
1. 不幸的是，没有为 crossroads 提供可用的 RPM 包，我们只能从源码安装。
要编译 XR，你必须在系统上安装 C++ 编译器和 GNU make 组件，才能避免安装错误。
#yuminstallgccgcc-c++make
接下来，去他们的（https://crossroads.e-tunity.com）下载此压缩包（即 crossroads-stable.tar.gz）。
或者，您可以使用 wget 去下载包然后解压在任何位置（如：/usr/src/），进入解压目录，并使用 “make install” 命令安装。
#wgethttps://crossroads.e-tunity.com/downloads/crossroads-stable.tar.gz#tar-xvfcrossroads-stable.tar.gz#cdcrossroads-2.74/#makeinstall
安装完成后，二进制文件安装在 /usr/sbin 目录下，XR 的配置文件在 /etc 下名为 “xrctl.xml” 。
2. 最后一个条件，你需要两个web服务器。为了方便使用，我在一台服务器中创建两个 Python SimpleHTTPServer 实例。
要了解如何设置一个 python SimpleHTTPServer，请阅读我们此处的文章 使用 SimpleHTTPServer 轻松创建两个 web 服务器.
正如我所说的，我们要使用两个web服务器，webserver01 通过8888端口运行在172.16.1.222上，webserver02 通过5555端口运行在192.168.1.161上。
XR WebServer 01
XR WebServer 02
第2步: 配置 XR Crossroads 负载均衡器
3. 所需都已经就绪。现在我们要做的就是配置xrctl.xml 文件并通过 XR 服务器接受来自互联网的请求分发到 web 服务器上。
现在用 vi/vim 编辑器打开xrctl.xml文件。
#vim/etc/xrctl.xml
并作如下修改。
true/tmpTecmint172.16.1.204:8080tcp0:8010yes0000172.16.1.222:8888192.168.1.161:5555
配置 XR Crossroads 负载均衡器
在这里，你可以看到在 xrctl.xml 中配置了一个非常基本的 XR 。我已经定义了 XR 服务器在哪里，XR 的后端服务和端口及 XR 的 web 管理界面是什么。
4. 现在，你需要通过以下命令来启动该 XR 守护进程。
#xrctlstart#xrctlstatus
启动 XR Crossroads
5. 好的。现在是时候来检查该配置是否可以工作正常了。打开两个网页浏览器，输入 XR 服务器的 IP 地址和端口，并查看输出。
验证 Web 服务器负载均衡
太棒了。它工作正常。是时候玩玩 XR 了。（LCTT 译注：可以看到两个请求分别分配到了不同服务器。）
6. 现在可以通过我们配置的网络管理界面的端口来登录到 XR Crossroads 仪表盘。在浏览器输入你的 XR 服务器的 IP 地址和你配置在 xrctl.xml 中的管理端口。
http://172.16.1.204:8010
XR Crossroads 仪表盘
看起来像上面一样。它容易理解，用户界面友好，易于使用。它在右上角显示每个服务器能容纳多少个连接，以及关于接收该请求的附加细节。你也可以设置每个服务器承担的负载量，最大连接数和平均负载等。
最大的好处是，即使没有配置文件 xrctl.xml，你也可以做到这一点。你唯一要做的就是运行以下命令，它就会把这一切搞定。
#xr--verbose--servertcp:172.16.1.204:8080--backend172.16.1.222:8888--backend192.168.1.161:5555
上面语法的详细说明：
-verbose 将显示命令执行后的信息。-server 定义你在安装包中的 XR 服务器。-backend 定义你需要平衡分配到 Web 服务器的流量。tcp 说明我们使用 TCP 服务。
欲了解更多详情，有关文件及 CROSSROADS 的配置，请访问他们的: https://crossroads.e-tunity.com/.
XR Corssroads 使用许多方法来提高服务器性能，避免宕机，让你的管理任务更轻松，更简便。希望你喜欢此文章，并随时在下面发表你的评论和建议，方便与我们保持联系。via:https://linux.cn/article-5867-1.html
如何用Flood测试Web服务器响应时间
服务器投入使用后，你最关心的事莫过于服务器的性能了。你可以用一些手动的方法进行测试，但手动方法有很多局限性。先不论手工测试方法所投入的时间和精力问题，用手工方法测试的一大不足就是它不容易揭示出你的站点的真正问题所在，是服务器设置的问题还是因为一些动态组件又或是网络基础设施造成的问题？幸运的Apache HTTP工程包含了一个名为HTTPD-Test的子工程，正如这个名称所揭示的，这是一个Apache的通用测试工具包，这个包里包含了大量的不同工 具，而本文将主要介绍其中一个名为洪水（Flood）的工具，它之所以如此命名，是因为它利用向服务器发出洪水般的大量请求测试服务器的响应时间。Flood使用一个XML文件来进行必要的测试设置，包括测试中使用的URL和POST数据和准备测试的服务器组，然后Flood开始测量以下一系统操作的时间：打开一个到服务器的socket向socket写入对服务器的请求读出服务器的响应关闭socket当测试结束，管理员就可以了解到是否存在Apache服务器（或其它HTTP服务器）的设置问题，服务器的实际负荷，硬件的性能表现和是否存在着网络基础设置瓶颈。安装Flood你可以在Apache网站下载httpd-test和apr/apr-util软件包，后者是当从Apache的CVS服务器上直接build时所需要的.。你必需先进行登录（密码是"anoncvs"）$ cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic login$ cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic co httpd-test/flood$ cd httpd-test/flood$ cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic co apr$ cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic co apr-util如果你取得了源码，你可以用下面的命令安装：$ buildconf$ configure$ make all现在，安装完成了。设置FloodFlood通 过一个XML格式的设置文件来定义测试中使用的各种参数，我们不妨通过一个形象的比喻也说明一下Flood的工作过程和需要设置的各个方面。首 先，Flood使用一个模型（profile）来定义一组给定的URL如何被访问，具体的访问由一个或多个农夫(farmer)来进行，而这些农夫又属于 一个或多个农场(farm)，我们来看一下下面这个示意图：如图所示，现在我们使用一个农场，这个农场有两组农夫，其中农夫组Joe使用访问模型A与一个包含五个地址的URL列表，农夫组B使用访问模型B与一个包含 三个URL的地址列表，这些家夫直接向WEB服务器请求列表中的地址。Flood使用线程来创建各个农夫，然后比较各个农夫收集到的数据并存入一个单独的 文件以便之后做进一步的处理。XML文件包括了这个测试需要定义的四个方面：URL列表，访问模型，农夫和农场。URL列表也即一组即将被访问的地址的列表，这些URL地址可以被简单的引用进一步定义特定的请求方法（GET，POST，HEAD）。访问模型定义测试使用哪一个地址列表，它们如何被访问，使用哪一种Socket，收集的信息如何被报告。农夫负责实际的请求过程，对农夫唯一的可设置选项是使用哪一个访问模型和对一个访问模型的调用次数。每个农夫独立的执行自己的访问模型，但一个访问模型可以执行多次，因此最后的请求过程可能是这样：地址一、地址二、地址一、地址二、……。对 家场的定义涉及到创建农夫的数目和时间，通过增加一个家场创建农夫的数目，可以增加并发请求的数目。并通一些附加的设置，你可以设置一些初始数目的农夫， 然后每隔特定的时间增加一定的农夫数量。例如，你可以开始创建两个农夫，然后每5秒钟增加一个农夫，直到农夫数目达到20时停止增加。这可以在一个给定的 期间形成一个最大20的并发访问升级过程，然后又逐步将并发请求数降到0。另外也可以模拟这种访问情况，一定数目的访问者长时期的访问一系列页面，并操持 最大并发请求数在5-6之间。注意：到写这篇文章的时候为止，目前的Flood仅支持一个农场，而且它的名子必须是"Bingo"，不过，通过为一个农场定义多个农夫，你可以取得同样的基本效果。通过调节农夫，农场和URL列表的参数，你可以控制总请求数，并发请求数，测试时间（基于URL列表，重复次数和农夫的数量可以决定这一点），以及这些请求在整个测试期间的分布，这就允许你针对不同的条件订制你的测试。在使用Flood进行测试设置时你应该记住的三个基本点是：地址列表定义了农夫们将访问的地址每个农夫的重复数目定义了一个用户访问你的站点的次数。一个农场的农夫数目定义了并发访问用户的数目。在Flood发行包里的examples目录下有一个样例设置文件，round-robin.xml可能是一个最适合初学者学习的例子，不过本文并不准备就编辑此XML文件的规则或处理产生的数据文件做进一步的解说。这里，我们主要想讲一下如何针对不同类型的WEB服务器来调整测试的参数。为了便于理解后面的内容，这里我们先看一下使用examples目录下的analyze-relative测试脚本得到的一个结果。在这个例子中，测试对象是一台内部服务器。Slowest pages on average (worst 5):Average times (sec)connect write read close hits URL0.0022 0.0034 0.0268 0.0280 100 http://test.mcslp.pri/java.html0.0020 0.0028 0.0183 0.0190 700 http://www.mcslp.pri/0.0019 0.0033 0.0109 0.0120 100 http://test.mcslp.pri/random.html0.0022 0.0031 0.0089 0.0107 100 http://test.mcslp.pri/testr.html0.0019 0.0029 0.0087 0.0096 100 http://test.mcslp.pri/Requests: 1200 Time: 0.14 Req/Sec: 9454.08在这里你可以看到测试中进行连接（connect），请求（write/request），回应（read /response），关闭连接（close）的平均时间。你也可以对服务器每称处理的请求数目有个基本的印象。对于新闻类站点的测试对于如New York Times、Slashdot之类的新闻站点以及一些BLOG之类，它们都有一个主要的首页，首页上有着众多到栏目页和内容页的连接，对某条信息感兴趣的读者可以点进去仔细阅读。通常情况下，这类站点的首页访问量相对固定而对于其它页面，访问量的变化就会更大一些。如果它推出了RSS/RDF订阅服务，那么就会出现一定量的直接到内 容页的流量而不经过首页。大部分的此类站点都使用了某种内容的动态化技术，而Flood是测试这类动态站点的一个不错方法，特别你可以将之与一些静态站的 响应相对比。你可以用以下的参数设置模拟对一个新闻类型的网站的访问：Farmer Set AFarmer Set BFarmer Set CURL ListHomepage OnlyHomepage 3 stories3 story pagesRepeat Count133Count1002020Start Count555Start Delay155NotesHome page onlyHomepage StoriesStories only (RSS)测试在线商店站点在线商店，在线商品目录或其它一些更具交互性的网站则有不同的使用模型。虽然仍会有一部分人到达你的首页，一些人会直接进入你站内的某一个页面，大多数用户会在你的站里找来找去，他们可能会在一个产品页上浏览大量的产品，进行一些搜索或者点击进入一些相关的产品页面。因此，你应该用更大数量的地址列表测试这类站点，更大的重复次数（以模拟大量的用户）和相对新闻类站点比较低的并发访问数目：Farmer SetURL List10-15 pagesRepeat Count5Count50Start Count5Start Delay5测试 "Slashdot" 效应有时，你必须测试你的系统能否应付某个特定时刻大量用户同时访问你的网站的情况。很多网站已经遇到过这个问题，一次重大事件中对于Slashdot网站的几个页面的引用就引发了对这个页面的巨量并发请求。典型的情况下这些请求仅针对一个特殊的页面，我们可以通过在Flood中创建成百上千的家夫来并发请求服务器上的特定页面来模拟这种情况，通过设置高重复率和延迟系统来模拟一定时间内大量用户的连续访问。Farmer SetURL List1 pageRepeat Count50Count250Start Count100Start Delay1测试技巧为了让以上各类测试都工作得很好，你应该记住以下几点：最重要的是，不要直接在WEB服务器上用Flood进行测试，如果你这样做你仅仅是在测试一台机器打开一个网络连接与自己通讯的能力，一定要在另一台机器上进行测试。要对自己机器的一些技术限制有所了解，这包括你机器容许的最大线程数和最大网络连接数，如果你试图创建超过这个限制的农夫将会带来让人难以理解的测试结果。Flood是一个客户端解决方案，因此对于在多台机器上进行测试没有任何限制。事实上我们推荐你这样做，因为这是一个在想进行饱和性测试时避免你的客户机系统的技术限制的好方法。Flood测试由于是在客户机上运行，它的表现也要依赖于客户的性能，如果客户机系统处于繁忙的状态，Flood进程会与其它客户进程一样被阻塞，因此，最好使用一台专用的客户机进行测试，如果客户机上还运行着其它任务，在开始测试之前最好关掉它们。
Apache Web 服务器
Apache 的安装
Red Hat Linux 9 自带了Apache2.0，以下是Apache 的安装步骤：
#rpm -qa|grep httpd
#mount /mnt/cdrom //将第 1 张光盘放入光驱后挂装
#cd /mnt/cdrom/red hat/rpms
#rpm -ivh httpd-2.0.40.21.i386.rpm
#rpm -ivh httpd-manual-2.0.40-21.i386.rpm
#cd;eject
在安装时，Apache 采用了一系列的缺省值，系统启动后，WWW 服务器已经运行。将
装上linux+apache 的主机联入internet 后，把自己的主页存到/home/httpd 目录下即可。
5.2 Apache+PHP
安装php
#mount /mnt/cdrom //将第 1 张光盘放入光驱后挂装
#cd /mnt/cdrom/red hat/rpms
#rpm -ivh curl-7.9.8-5.i386.rpm
#rpm -ivh gd-1.8.4-11.i386.rpm //安装php 所需的curl 和gd
#rpm -ivh php-4.2.2-17.i386.rpm //安装php
#rpm -ivh php-imap-4.2.2-17.i386.rpm //安装php 的imap 支持包
#cd;eject
#mount /mnt/cdrom //将第2 张光盘放入光驱后挂装
#cd /mnt/cdrom/red hat/rpms
#rpm -ivh php-manual-4.2.2-17.i386.rpm //安装php 手册
#rpm -ivh php-mysql-4.2.2-17.i386.rpm //安装php 的mysql 支持包
#rpm -ivh php-pgsql-4.2.2-17.i386.rpm //安装php 的pgsql 支持包
#cd;eject
在文件/usr/local/apache/conf/httpd.conf 中中添加以下语句：
addtype application/x -httpd-php .php
addtype application/x -httpd-php-source .phps
然后修改php 配置文件php.ini
register_globals=on
重启apache 服务器
#httpd restart
然后写个php 测试页info.php 内容如下：
<?php
phpinfo （）
?>
测试php：打开浏览器，在地址栏上输入192.168.0.254/info.php
如果能看到php 的信息，则说明apache+php 安装成功。
5.3 Apache+jsp
整合JDK 和TOMCAT 环境
环境：Red Hat Linux 9 apache 2.0 php4
需要软件：（在/usr/local 下安装） apache 安装路径为/usr/local/apache
1. 安装jdk 1.4.2
#cd /usr/local/
#wget ftp ：//202.96.64.158/pub/j2sdk-1_4_2_03-linux-i586.bin
#chmod a+x j2sdk-1_4_2_03-linux-i586.bin
#./j2sdk-1_4_2_03-linux-i586.bin
将所下载的j2sdk 复制到目录/usr/local/下面以/j2sdk 为目录
2. 安装tomcat
#cd /usr/local/
#wget http：//apache.linuxforum.net/dist/jakarta/tomcat-4/v4.1.29/bin/
jakarta-tomcat-4.1.29.tar.gz
#tar zxf jakarta-tomcat-4.1.29.tar.gz
将下载的tomcat 解压后复制到/usr/local/下以/tomcat 为目录
3. 为jdk 和tomcat 建立链接
ln -s j2sdk jdk
ln -s tomcat tomcat
4. 设置环境变量
vi /etc/profile 在最后加入以下内容，并在系统中运行一下
PATH=$PATH：/usr/local/j2sdk/bin：/usr/local/j2sdk/jre/bin
JAVA_HOME=/usr/local/j2sdk
export JAVA_HOME
CLASSPATH="./：/usr/local/j2sdk/lib：/usr/local/j2sdk/jre/lib"
export CLASSPATH
CATALINA_HOME=/usr/local/tomcat
export CATALINA_HOME
5. 编译安装 Connector
#cd /usr/local
#wget http：//apache.linuxforum.net/dist/jakarta/tomcat-4/v4.1.29/src/
jakarta-tomcat-connectors-4.1.29-src.tar.gz
#tar zxf jakarta-tomcat-connectors-4.1.29-src.tar.gz
Web服务器故障的奇怪原因排查
伴随着对信息化要求的不断提升，相信多数单位都会架设自己的Web服务器，来在Internet网络中发布信息、宣传自我。为了保证任何一位上网用户都能顺畅地访问到Web服务器中的内容，网络管理员在正式发布Web信息之前往往需要设置一下IIS服务器，以便确保单位的Web网站可以始终如一地稳定运行。然而很多时候，我们都会遇到Web服务器访问失败的故障现象，面对Web服务器故障，我们往往会表现得手忙脚乱，根本不知道该从何处着手，来解决这些Web服务器故障。其实，造成Web服务器故障的因素有很多，我们需要对此进行逐一排查，才能高效解决对应的Web服务器故障现象。
Web服务器故障现象
为了充分展示单位的形象，扩大单位的知名度，单位领导要求网络管理员，立即拿出方案，组建有个性化特色的Web站点，不仅确保单位内部的员工可以通过内网正常访问Web站点，同时还要保证外网用户也能快速地访问到本单位的站点内容。依照领导指示精神，网络管理员立即行动，挑选了一台运行性能非常高效的计算机作为服务器系统，并在其中安装、配置了Windows Server 2003系统，同时利用该系统自带的IIS组件架设了Web服务器;为了提高Web站点的访问速度，网络管理员特地将Web站点所在的计算机直接连到单位千兆核心交换机上，同时将目标主机的IP地址设置成与单位普通员工所用计算机处于相同网段的地址。刚开始的时候，无论是内网用户，还是外网用户，所有用户都能正常地访问单位的Web站点。
可是，没有多长时间，单位内网用户在访问Web站点时，就遇到了访问失败的Web服务器故障，具体表现为无论从哪一台客户端系统出发，使用内网地址访问单位的目标站点时，系统屏幕上都会弹出身份验证对话框，要求单位员工必须输入访问账号与密码，可是当网络管理员尝试以Web站点的系统管理员身份进行登录操作时，发现始终登录不进去;更让人感觉到不可理解的是，网络管理员赶到Web服务器现场，查看其安全配置时，发现目标Web站点根本就没有启用登录验证设置，那身份验证对话框究竟是怎么弹出来的呢?
Web服务器故障排查
由于造成这类Web服务器故障的因素比较多，我们必须要对各种可能因素进行依次排查，才能找到具体的Web服务器故障原因，并对症下药采取针对性措施来快速解决故障现象：
Web服务器故障排查过程1、检查安全登录设置
考虑到在访问目标Web站点的时候，系统弹出了身份验证对话框，这就意味着目标Web站点可能在安全登录方面没有配置正确，造成了用户访问Web内容时必须要输入访问账号。依照这样的分析思路，网络管理员准备先检查一下Web服务器的安全登录配置参数，看看其中的设置是否正确;想到做到，网络管理员立即来到目标Web主机现场，以特权账号登录其中，并依次单击“开始”/“设置”/“控制面板”选项，从弹出的系统控制面板窗口中，找到“管理工具”功能图标，并用鼠标双击该图标选项，进入对应系统的管理工具列表窗口;接着再用鼠标双击IIS功能图标，弹出对应系统的IIS主控台窗口，从该窗口的左侧列表区域，找到目标Web站点所在的计算机名称，并用鼠标右键单击该计算机名称，从弹出的右键菜单中执行“属性”命令，弹出目标Web主机的属性设置窗口;在该属性设置窗口中点选“目录安全性”选项卡，打开目录安全性选项设置页面;下面，在该设置页面的“身份验证和访问控制”设置项右边，单击“编辑”按钮，进入身份验证和访问控制设置对话框，网络管理员发现其中的“匿名访问”、“集成Windows验证”等选项都处于选中状态，于是他尝试着将这些参数选项取消选中，之后重新从内网的一台计算机中进行Web访问，可是相同的故障现象仍然存在;于是，网络管理员再次选中了“匿名访问”、“集成Windows验证”等选项，可是让他感觉非常失望的是，上面两个选项无论是选中还是没有选中，好像故障现象都存在，这就说明目标Web主机的安全登录设置与上面的故障现象并没有什么关系。
Web服务器安全的4个解决方案
Web服务器安全现在是很严重的问题了，各种针对WEB服务器攻击的方式层出不穷，如何应对成了重要的问题，下面笔者给出4个解决方案，希望能帮助到你：
一、圈地运动，已经无法满足安全的需求
在传统解决方案中，有一个比较显著的特点，即搞圈地运动。如针对邮件，有一套邮件安全方案;针对FTP，有一个FTP安全解决方案。传统安全解决方案，将IT领域根据其应用的不同，认为的划分成一块块领域，然后再设计对应的安全措施。如果只针对一种攻击行为，这种安全解决方案，固然有效。但是在混合式攻击面前，这种圈地性质的解决方案，弊端就非常明显了。因为攻击者从一个方向攻击不成，还可以从另一个方向攻击。这种单独的安全解决方案，无法做到面面俱到。为此企业Web应用的安全，不能够再依靠防火墙等解决方案来做圈地式的保护运动。混合攻击会借助病毒、木马、恶意软件、肉鸡等攻击方法，对系统、应用程序等漏洞，发起攻击。从而在比较大的范围内发起攻击。
笔者建议，在应对混合攻击方面，要有一个比较全面的规划，而不是各种解决方案各自为战。在实际工作中，我们可以选择一种解决方案为主，然后其它解决方案为辅，设计一个从上到下的全面的防护措施。如针对Web应用，笔者就推荐企业，可以以Web防火墙为主、然后结合邮件安全策略、FTP安全策略、SSL加密机制等手段，组成一个比较综合的安全防护网。
二、漏洞，攻击的源头
混合攻击，其实是多种已知攻击手段的组合。而现在已知的攻击行为，90%以上是针对系统以及应用程序的漏洞展开的。俗话说，苍蝇不叮无缝的蛋。在实际工作中，我们只要保证蛋没有缝，那么苍蝇也就没这么好叮了。
故笔者建议，针对各种混合攻击行为，最好的预防措施之一就是对系统以及应用程序打上对应的补丁。不过需要注意的是，这个补丁不光光是针对服务器，而且还包括用户的客户端。因为有时候攻击者非常狡猾，如果服务器攻不下的话，他们可能会先对客户端做文章。先把客户端拿下，做为他们肉鸡，然后再对服务器发起攻击。大部分时候，从内部发起攻击，要比外部发起攻击更加容易。毕竟堡垒更容易从内部攻破。但是有时候客户端的数量非常的多，对每台客户端进行补丁的管理比较困难。
在这里笔者推荐使用统一的补丁管理解决方案，如微软的补丁维护方案。其原理比较简单。先是用一台补丁服务器，从微软的下载最新的补丁。然后各个客户端(包括用户终端和服务器)，每次启动时从服务器上下载最新的补丁，并进行自动或者手工的安装。如果企业的安全级别比较高，笔者这里建议采用强制安装。有时候补丁安装会比较麻烦，如安装完之后还需要重新启动。为此一些用户会偷懒，当服务器提示需要安装补丁时，他们会当作耳边风。不打补丁，从而给企业的Web应用安全留下隐患。针对这种情况下，采取强制措施，会更加的安全。采取强制安装时，不会征询用户的意见。只要管理人员认为这个补丁重要，那么客户端在重新启动后或者在线时就会强制安装补丁。如果需要重新启动的话，也会先通知客户端然后在一定的时间内重新启动，以完成补丁的安装工作。
【WEB服务器多框架的解决方案】相关文章：
3.安装Web服务器