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服務器