- 相關(guān)推薦
WEB服務(wù)器多框架的解決方案
【摘要】在INTRANET上設計基于WEB的MIS時(shí)，大批量數據錄入變成了操作上的瓶頸，并給WEB SERVER與DATABASE造極大的負擔。
為解決這個(gè)問(wèn)題，我們設計了多框架結構，將應用的功能進(jìn)行細分，然后交給各框架分別完成，這種分工協(xié)作方式可以使操作界面上的數據實(shí)現受控的部分刷新，有效地減小了網(wǎng)絡(luò )的數據傳輸量，縮短了各部分的處理時(shí)間，同時(shí)了也大大減輕了WEB SERVER與DATABASE的系統負擔。
多框架解決方案采用ASP（ActiveX Server Pages）及ADO(ActiveX Data Objects)完成與數據庫的交互工作。采用DOM技術(shù)解決和框架之間的協(xié)作問(wèn)題。
關(guān)鍵詞：多框架
*注：本文中討論的方案中WEB服務(wù)器為IIS4.0、客戶(hù)端瀏覽器為IE4.0以上版本。
一、問(wèn)題的提出
最初，我們采用ASP及ADO技術(shù)在INTRANET上設計基于WEB的MIS（下文簡(jiǎn)稱(chēng)MIS）時(shí)，沿用了以往設計WEB站點(diǎn)時(shí)的設計習慣。但隨著(zhù)設計的深入，我們發(fā)現，現有的系統結構無(wú)法承擔大批量的數據錄入工作，因此，必須重新構造系統的總體設計結構。
MIS與普通的WEB站點(diǎn)之間最大的區別在于處理信息的方式。普通WEB站點(diǎn)的主要功能是發(fā)布信息，采集信息只是它極小的一部分功能，而且這些信息采集功能也都是比較簡(jiǎn)單的。但對于MIS系統來(lái)說(shuō)，信息的采集及維護工作占有比較高的比例，在這些信息采集功能中還存在一些較為復雜及大批量的數據錄入功能，這些功能成為了系統中的設計難點(diǎn)。
二、問(wèn)題的分析
當一個(gè)系統涉及到復雜及大批量的數據錄入功能時(shí)，同時(shí)也就涉及到了響應速度及界面的問(wèn)題。在以往的C/S方式中，客戶(hù)端的錄入速度由錄入員來(lái)控制，一般情況下，當錄入員熟悉了操作方式之后，錄入速度是不受系統限制的。但在WEB方式下，頁(yè)面采用完全刷新方式，每次的交互操作至少要造成一個(gè)頁(yè)面的刷新。這種刷新的工作不僅更新了數據，也將界面上的一些固定內容重新加載了一遍。對于普通用戶(hù)來(lái)說(shuō)，這種短時(shí)間的刷新并不會(huì )造成影響；但對于長(cháng)時(shí)間進(jìn)行操作的錄入員來(lái)說(shuō)，錄入一條數據就要等待一段時(shí)間（這一段時(shí)間可能是2-3秒，也可能是十幾秒甚至幾分鐘），是絕對不能接受的。即使，網(wǎng)絡(luò )有足夠的帶寬，頁(yè)面的重載也會(huì )造成一種閃動(dòng)的效果，這種一閃一閃的刷新造成錄入員必須重新識別頁(yè)面上的各種元素，不僅也會(huì )拖慢了他們的錄入速度，還造成眼睛的快速疲勞。
三、解決方案
如果能夠“不”刷新頁(yè)面而“快速更新”頁(yè)面中的數據，問(wèn)題應該能夠解決了。而且頁(yè)面由于沒(méi)有刷新，一些必須由服務(wù)器保存的狀態(tài)信息也能夠在客戶(hù)端保存下來(lái)了，從而減輕服務(wù)器的負擔。那么如何達到這個(gè)目標呢？下面將詳細討論。
1．設計思路
首先，我們確立采用多框架建立頁(yè)面�？蚣�(Frames)其實(shí)不是什么新東西，許多站點(diǎn)上都用它來(lái)完成顯示固定標題及菜單的功能。采用框架能夠避免一些頁(yè)面的重復訪(fǎng)問(wèn)。但是如果結合使用DOM（Document objects model)，框架可以完成許多細致的工作。
按照DOM的定義，框架可以被當作一個(gè)對象。假設我們建立了一個(gè)框架，并給它取名為A，則對于建立框架的頁(yè)面來(lái)說(shuō)，A是Frames集合中的一個(gè)成員，而對于A(yíng)中的頁(yè)面來(lái)說(shuō)，A相當于window對象。因些，雖然框架之間不存在從屬關(guān)系，但可以通過(guò)它們的父頁(yè)面（對象）建立各框架之間的關(guān)系。
如右圖所示：框架之間能夠進(jìn)行相互控制與數據傳送。
1）．在框架A中用的是最常用的框架控制方式，利用＜A TARGET＝“B” HREF=”URL”＞ 控制B框架中的頁(yè)面重載。
2）．在框架B中，通過(guò)按鈕的點(diǎn)擊事件對框架C進(jìn)行控制，這里的控制是通過(guò)DOM來(lái)實(shí)現的。(假設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．新的框架結構
如上圖，我們定義了一個(gè)新的框架結構。在新的框架結構中，除了用來(lái)放置一、二級菜單的MENU1、MENU2和用來(lái)放置三級菜單及具體應用功能的Aapp之外，還增加了三個(gè)專(zhuān)門(mén)用來(lái)處理數據的框架（在上圖中用虛線(xiàn)表示）。這三個(gè)框架不需要界面，在應用執行的時(shí)候是看不見(jiàn)的。
淘寶Web服務(wù)器，Tengine-1.2.5 版本發(fā)布
我們很高興的告訴大家，Tengine-1.2.5 版本正式發(fā)布了。您可以在這里下載：http://tengine.taobao.org/download/tengine-1.2.4.tar.gz或者可以在github上檢出代碼：https://github.com/taobao/tengine
本次發(fā)布的亮點(diǎn)是新增加的upstream_check模塊，可以用來(lái)對后端服務(wù)器進(jìn)行主動(dòng)健康檢查，以自動(dòng)的下線(xiàn)失效的服務(wù)器。當您使用Tengine作為負載均衡（反向代理）時(shí)，這個(gè)功能非常有用。
其他的更新包括：
* Feature：允許syslog輸出日志時(shí)指定程序的標識（program identifier）；* Change：合并nginx-1.0.14至nginx-1.0.15之間的修改；* Change：將accept_mutex_delay的默認值從500毫秒更改為100毫秒以提高性能；* Bugfix：修復syslog的一個(gè)在后端服務(wù)器連接不上導致端錯誤的bug；* Bugfix：修復access_log可能和buffer參數沖突的bug；
Tengine是由淘寶網(wǎng)發(fā)起的Web服務(wù)器項目。它在Nginx的基礎上，針對大訪(fǎng)問(wèn)量網(wǎng)站的需求，添加了很多高級功能和特性。Tengine的 性能和穩定性已經(jīng)在大型的網(wǎng)站如淘寶網(wǎng)，天貓商城等得到了很好的檢驗。它的最終目標是打造一個(gè)高效、穩定、安全、易用的Web平臺。
從2011年12月開(kāi)始，Tengine成為一個(gè)開(kāi)源項目。
以下沿引項目主頁(yè)上的特性介紹：
繼承Nginx-1.0.14的所有特性，100%兼容Nginx的配置；輸入過(guò)濾器機制支持。通過(guò)使用這種機制Web應用防火墻的編寫(xiě)更為方便；組合多個(gè)CSS、JavaScript文件的訪(fǎng)問(wèn)請求變成一個(gè)請求；支持管道（pipe）和syslog（本地和遠端）形式的日志以及日志抽樣；自動(dòng)根據CPU數目設置進(jìn)程個(gè)數和綁定CPU親緣性；監控系統的負載和資源占用從而對系統進(jìn)行保護；顯示對運維人員更友好的出錯信息，便于定位出錯機器；更強大的防攻擊（訪(fǎng)問(wèn)速度限制）模塊；backtrace模塊，程序崩潰的時(shí)候可以顯示出錯的調用棧；更方便的命令行參數，如列出編譯的模塊列表、支持的指令等；可以根據訪(fǎng)問(wèn)文件類(lèi)型設置過(guò)期時(shí)間；
在Tengine的網(wǎng)站上可以瀏覽更多信息：http://tengine.taobao.org
Hiawatha 8.4發(fā)布，安全的Web服務(wù)器
Hiawatha 是一個(gè)Linux/UNIX下安全的Web服務(wù)器，其設計的最主要的目的就是安全，當然它也是快速的而且易于配置。
Hiawatha 8.4 的改進(jìn)內容：
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服務(wù)器架設 “XR”（Crossroads） 負載均衡器
Crossroads 是一個(gè)獨立的服務(wù)，它是一個(gè)用于Linux和TCP服務(wù)的開(kāi)源負載均衡和故障轉移實(shí)用程序。它可用于HTTP，HTTPS，SSH，SMTP 和 DNS 等，它也是一個(gè)多線(xiàn)程的工具，在提供負載均衡服務(wù)時(shí)，它可以只使用一塊內存空間以此來(lái)提高性能。
首先來(lái)看看 XR 是如何工作的。我們可以將 XR 放到網(wǎng)絡(luò )客戶(hù)端和服務(wù)器之間，它可以將客戶(hù)端的請求分配到服務(wù)器上以平衡負載。
如果一臺服務(wù)器宕機，XR 會(huì )轉發(fā)客戶(hù)端請求到另一個(gè)服務(wù)器，所以客戶(hù)感覺(jué)不到停頓�？纯聪旅娴膱D來(lái)了解什么樣的情況下，我們要使用 XR 處理。
延伸閱讀：
安裝 XR Crossroads 負載均衡器
這里有兩個(gè) Web 服務(wù)器，一個(gè)網(wǎng)關(guān)服務(wù)器，我們將在網(wǎng)關(guān)服務(wù)器上安裝和設置 XR 以接收客戶(hù)端請求，并分發(fā)到服務(wù)器。
XR Crossroads 網(wǎng)關(guān)服務(wù)器：172.16.1.204
Web 服務(wù)器01：172.16.1.222
Web 服務(wù)器02：192.168.1.161
在上述情況下，我們網(wǎng)關(guān)服務(wù)器（即 XR Crossroads）的IP地址是172.16.1.222，webserver01 為172.16.1.222，它監聽(tīng)8888端口，webserver02 是192.168.1.161，它監聽(tīng)端口5555。
現在，我們需要的是均衡所有的請求，通過(guò) XR 網(wǎng)關(guān)從網(wǎng)上接收請求然后分發(fā)它到兩個(gè)web服務(wù)器已達到負載均衡。
第1步：在網(wǎng)關(guān)服務(wù)器上安裝 XR Crossroads 負載均衡器
1. 不幸的是，沒(méi)有為 crossroads 提供可用的 RPM 包，我們只能從源碼安裝。
要編譯 XR，你必須在系統上安裝 C++ 編譯器和 GNU make 組件，才能避免安裝錯誤。
#yuminstallgccgcc-c++make
接下來(lái)，去他們的（https://crossroads.e-tunity.com）下載此壓縮包（即 crossroads-stable.tar.gz）。
或者，您可以使用 wget 去下載包然后解壓在任何位置（如：/usr/src/），進(jìn)入解壓目錄，并使用 “make install” 命令安裝。
#wgethttps://crossroads.e-tunity.com/downloads/crossroads-stable.tar.gz#tar-xvfcrossroads-stable.tar.gz#cdcrossroads-2.74/#makeinstall
安裝完成后，二進(jìn)制文件安裝在 /usr/sbin 目錄下，XR 的配置文件在 /etc 下名為 “xrctl.xml” 。
2. 最后一個(gè)條件，你需要兩個(gè)web服務(wù)器。為了方便使用，我在一臺服務(wù)器中創(chuàng )建兩個(gè) Python SimpleHTTPServer 實(shí)例。
要了解如何設置一個(gè) python SimpleHTTPServer，請閱讀我們此處的文章 使用 SimpleHTTPServer 輕松創(chuàng )建兩個(gè) web 服務(wù)器.
正如我所說(shuō)的，我們要使用兩個(gè)web服務(wù)器，webserver01 通過(guò)8888端口運行在172.16.1.222上，webserver02 通過(guò)5555端口運行在192.168.1.161上。
XR WebServer 01
XR WebServer 02
第2步: 配置 XR Crossroads 負載均衡器
3. 所需都已經(jīng)就緒�，F在我們要做的就是配置xrctl.xml 文件并通過(guò) XR 服務(wù)器接受來(lái)自互聯(lián)網(wǎng)的請求分發(fā)到 web 服務(wù)器上。
現在用 vi/vim 編輯器打開(kāi)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 中配置了一個(gè)非�；镜� XR 。我已經(jīng)定義了 XR 服務(wù)器在哪里，XR 的后端服務(wù)和端口及 XR 的 web 管理界面是什么。
4. 現在，你需要通過(guò)以下命令來(lái)啟動(dòng)該 XR 守護進(jìn)程。
#xrctlstart#xrctlstatus
啟動(dòng) XR Crossroads
5. 好的�，F在是時(shí)候來(lái)檢查該配置是否可以工作正常了。打開(kāi)兩個(gè)網(wǎng)頁(yè)瀏覽器，輸入 XR 服務(wù)器的 IP 地址和端口，并查看輸出。
驗證 Web 服務(wù)器負載均衡
太棒了。它工作正常。是時(shí)候玩玩 XR 了。（LCTT 譯注：可以看到兩個(gè)請求分別分配到了不同服務(wù)器。）
6. 現在可以通過(guò)我們配置的網(wǎng)絡(luò )管理界面的端口來(lái)登錄到 XR Crossroads 儀表盤(pán)。在瀏覽器輸入你的 XR 服務(wù)器的 IP 地址和你配置在 xrctl.xml 中的管理端口。
http://172.16.1.204:8010
XR Crossroads 儀表盤(pán)
看起來(lái)像上面一樣。它容易理解，用戶(hù)界面友好，易于使用。它在右上角顯示每個(gè)服務(wù)器能容納多少個(gè)連接，以及關(guān)于接收該請求的附加細節。你也可以設置每個(gè)服務(wù)器承擔的負載量，最大連接數和平均負載等。
最大的好處是，即使沒(méi)有配置文件 xrctl.xml，你也可以做到這一點(diǎn)。你唯一要做的就是運行以下命令，它就會(huì )把這一切搞定。
#xr--verbose--servertcp:172.16.1.204:8080--backend172.16.1.222:8888--backend192.168.1.161:5555
上面語(yǔ)法的詳細說(shuō)明：
-verbose 將顯示命令執行后的信息。-server 定義你在安裝包中的 XR 服務(wù)器。-backend 定義你需要平衡分配到 Web 服務(wù)器的流量。tcp 說(shuō)明我們使用 TCP 服務(wù)。
欲了解更多詳情，有關(guān)文件及 CROSSROADS 的配置，請訪(fǎng)問(wèn)他們的: https://crossroads.e-tunity.com/.
XR Corssroads 使用許多方法來(lái)提高服務(wù)器性能，避免宕機，讓你的管理任務(wù)更輕松，更簡(jiǎn)便。希望你喜歡此文章，并隨時(shí)在下面發(fā)表你的評論和建議，方便與我們保持聯(lián)系。via:https://linux.cn/article-5867-1.html
如何用Flood測試Web服務(wù)器響應時(shí)間
服務(wù)器投入使用后，你最關(guān)心的事莫過(guò)于服務(wù)器的性能了。你可以用一些手動(dòng)的方法進(jìn)行測試，但手動(dòng)方法有很多局限性。先不論手工測試方法所投入的時(shí)間和精力問(wèn)題，用手工方法測試的一大不足就是它不容易揭示出你的站點(diǎn)的真正問(wèn)題所在，是服務(wù)器設置的問(wèn)題還是因為一些動(dòng)態(tài)組件又或是網(wǎng)絡(luò )基礎設施造成的問(wèn)題？幸運的Apache HTTP工程包含了一個(gè)名為HTTPD-Test的子工程，正如這個(gè)名稱(chēng)所揭示的，這是一個(gè)Apache的通用測試工具包，這個(gè)包里包含了大量的不同工 具，而本文將主要介紹其中一個(gè)名為洪水（Flood）的工具，它之所以如此命名，是因為它利用向服務(wù)器發(fā)出洪水般的大量請求測試服務(wù)器的響應時(shí)間。Flood使用一個(gè)XML文件來(lái)進(jìn)行必要的測試設置，包括測試中使用的URL和POST數據和準備測試的服務(wù)器組，然后Flood開(kāi)始測量以下一系統操作的時(shí)間：打開(kāi)一個(gè)到服務(wù)器的socket向socket寫(xiě)入對服務(wù)器的請求讀出服務(wù)器的響應關(guān)閉socket當測試結束，管理員就可以了解到是否存在A(yíng)pache服務(wù)器（或其它HTTP服務(wù)器）的設置問(wèn)題，服務(wù)器的實(shí)際負荷，硬件的性能表現和是否存在著(zhù)網(wǎng)絡(luò )基礎設置瓶頸。安裝Flood你可以在A(yíng)pache網(wǎng)站下載httpd-test和apr/apr-util軟件包，后者是當從Apache的CVS服務(wù)器上直接build時(shí)所需要的。你必需先進(jìn)行登錄（密碼是"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通 過(guò)一個(gè)XML格式的設置文件來(lái)定義測試中使用的各種參數，我們不妨通過(guò)一個(gè)形象的比喻也說(shuō)明一下Flood的工作過(guò)程和需要設置的各個(gè)方面。首 先，Flood使用一個(gè)模型（profile）來(lái)定義一組給定的URL如何被訪(fǎng)問(wèn)，具體的訪(fǎng)問(wèn)由一個(gè)或多個(gè)農夫(farmer)來(lái)進(jìn)行，而這些農夫又屬于 一個(gè)或多個(gè)農場(chǎng)(farm)，我們來(lái)看一下下面這個(gè)示意圖：如圖所示，現在我們使用一個(gè)農場(chǎng)，這個(gè)農場(chǎng)有兩組農夫，其中農夫組Joe使用訪(fǎng)問(wèn)模型A與一個(gè)包含五個(gè)地址的URL列表，農夫組B使用訪(fǎng)問(wèn)模型B與一個(gè)包含 三個(gè)URL的地址列表，這些家夫直接向WEB服務(wù)器請求列表中的地址。Flood使用線(xiàn)程來(lái)創(chuàng )建各個(gè)農夫，然后比較各個(gè)農夫收集到的數據并存入一個(gè)單獨的 文件以便之后做進(jìn)一步的處理。XML文件包括了這個(gè)測試需要定義的四個(gè)方面：URL列表，訪(fǎng)問(wèn)模型，農夫和農場(chǎng)。URL列表也即一組即將被訪(fǎng)問(wèn)的地址的列表，這些URL地址可以被簡(jiǎn)單的引用進(jìn)一步定義特定的請求方法（GET，POST，HEAD）。訪(fǎng)問(wèn)模型定義測試使用哪一個(gè)地址列表，它們如何被訪(fǎng)問(wèn)，使用哪一種Socket，收集的信息如何被報告。農夫負責實(shí)際的請求過(guò)程，對農夫唯一的可設置選項是使用哪一個(gè)訪(fǎng)問(wèn)模型和對一個(gè)訪(fǎng)問(wèn)模型的調用次數。每個(gè)農夫獨立的執行自己的訪(fǎng)問(wèn)模型，但一個(gè)訪(fǎng)問(wèn)模型可以執行多次，因此最后的請求過(guò)程可能是這樣：地址一、地址二、地址一、地址二、……。對 家場(chǎng)的定義涉及到創(chuàng )建農夫的數目和時(shí)間，通過(guò)增加一個(gè)家場(chǎng)創(chuàng )建農夫的數目，可以增加并發(fā)請求的數目。并通一些附加的設置，你可以設置一些初始數目的農夫， 然后每隔特定的時(shí)間增加一定的農夫數量。例如，你可以開(kāi)始創(chuàng )建兩個(gè)農夫，然后每5秒鐘增加一個(gè)農夫，直到農夫數目達到20時(shí)停止增加。這可以在一個(gè)給定的 期間形成一個(gè)最大20的并發(fā)訪(fǎng)問(wèn)升級過(guò)程，然后又逐步將并發(fā)請求數降到0。另外也可以模擬這種訪(fǎng)問(wèn)情況，一定數目的訪(fǎng)問(wèn)者長(cháng)時(shí)期的訪(fǎng)問(wèn)一系列頁(yè)面，并操持 最大并發(fā)請求數在5-6之間。注意：到寫(xiě)這篇文章的時(shí)候為止，目前的Flood僅支持一個(gè)農場(chǎng)，而且它的名子必須是"Bingo"，不過(guò)，通過(guò)為一個(gè)農場(chǎng)定義多個(gè)農夫，你可以取得同樣的基本效果。通過(guò)調節農夫，農場(chǎng)和URL列表的參數，你可以控制總請求數，并發(fā)請求數，測試時(shí)間（基于URL列表，重復次數和農夫的數量可以決定這一點(diǎn)），以及這些請求在整個(gè)測試期間的分布，這就允許你針對不同的條件訂制你的測試。在使用Flood進(jìn)行測試設置時(shí)你應該記住的三個(gè)基本點(diǎn)是：地址列表定義了農夫們將訪(fǎng)問(wèn)的地址每個(gè)農夫的重復數目定義了一個(gè)用戶(hù)訪(fǎng)問(wèn)你的站點(diǎn)的次數。一個(gè)農場(chǎng)的農夫數目定義了并發(fā)訪(fǎng)問(wèn)用戶(hù)的數目。在Flood發(fā)行包里的examples目錄下有一個(gè)樣例設置文件，round-robin.xml可能是一個(gè)最適合初學(xué)者學(xué)習的例子，不過(guò)本文并不準備就編輯此XML文件的規則或處理產(chǎn)生的數據文件做進(jìn)一步的解說(shuō)。這里，我們主要想講一下如何針對不同類(lèi)型的WEB服務(wù)器來(lái)調整測試的參數。為了便于理解后面的內容，這里我們先看一下使用examples目錄下的analyze-relative測試腳本得到的一個(gè)結果。在這個(gè)例子中，測試對象是一臺內部服務(wù)器。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在這里你可以看到測試中進(jìn)行連接（connect），請求（write/request），回應（read /response），關(guān)閉連接（close）的平均時(shí)間。你也可以對服務(wù)器每稱(chēng)處理的請求數目有個(gè)基本的印象。對于新聞類(lèi)站點(diǎn)的測試對于如New York Times、Slashdot之類(lèi)的新聞?wù)军c(diǎn)以及一些BLOG之類(lèi)，它們都有一個(gè)主要的首頁(yè)，首頁(yè)上有著(zhù)眾多到欄目頁(yè)和內容頁(yè)的連接，對某條信息感興趣的讀者可以點(diǎn)進(jìn)去仔細閱讀。通常情況下，這類(lèi)站點(diǎn)的首頁(yè)訪(fǎng)問(wèn)量相對固定而對于其它頁(yè)面，訪(fǎng)問(wèn)量的變化就會(huì )更大一些。如果它推出了RSS/RDF訂閱服務(wù)，那么就會(huì )出現一定量的直接到內 容頁(yè)的流量而不經(jīng)過(guò)首頁(yè)。大部分的此類(lèi)站點(diǎn)都使用了某種內容的動(dòng)態(tài)化技術(shù)，而Flood是測試這類(lèi)動(dòng)態(tài)站點(diǎn)的一個(gè)不錯方法，特別你可以將之與一些靜態(tài)站的 響應相對比。你可以用以下的參數設置模擬對一個(gè)新聞類(lèi)型的網(wǎng)站的訪(fǎng)問(wèn)：Farmer Set AFarmer Set BFarmer Set CURL ListHomepage OnlyHomepage 3 stories3 story pagesRepeat Count133Count1002020Start Count555Start Delay155NotesHome page onlyHomepage StoriesStories only (RSS)測試在線(xiàn)商店站點(diǎn)在線(xiàn)商店，在線(xiàn)商品目錄或其它一些更具交互性的網(wǎng)站則有不同的使用模型。雖然仍會(huì )有一部分人到達你的首頁(yè)，一些人會(huì )直接進(jìn)入你站內的某一個(gè)頁(yè)面，大多數用戶(hù)會(huì )在你的站里找來(lái)找去，他們可能會(huì )在一個(gè)產(chǎn)品頁(yè)上瀏覽大量的產(chǎn)品，進(jìn)行一些搜索或者點(diǎn)擊進(jìn)入一些相關(guān)的產(chǎn)品頁(yè)面。因此，你應該用更大數量的地址列表測試這類(lèi)站點(diǎn)，更大的重復次數（以模擬大量的用戶(hù)）和相對新聞類(lèi)站點(diǎn)比較低的并發(fā)訪(fǎng)問(wèn)數目：Farmer SetURL List10-15 pagesRepeat Count5Count50Start Count5Start Delay5測試 "Slashdot" 效應有時(shí)，你必須測試你的系統能否應付某個(gè)特定時(shí)刻大量用戶(hù)同時(shí)訪(fǎng)問(wèn)你的網(wǎng)站的情況。很多網(wǎng)站已經(jīng)遇到過(guò)這個(gè)問(wèn)題，一次重大事件中對于Slashdot網(wǎng)站的幾個(gè)頁(yè)面的引用就引發(fā)了對這個(gè)頁(yè)面的巨量并發(fā)請求。典型的情況下這些請求僅針對一個(gè)特殊的頁(yè)面，我們可以通過(guò)在Flood中創(chuàng )建成百上千的家夫來(lái)并發(fā)請求服務(wù)器上的特定頁(yè)面來(lái)模擬這種情況，通過(guò)設置高重復率和延遲系統來(lái)模擬一定時(shí)間內大量用戶(hù)的連續訪(fǎng)問(wèn)。Farmer SetURL List1 pageRepeat Count50Count250Start Count100Start Delay1測試技巧為了讓以上各類(lèi)測試都工作得很好，你應該記住以下幾點(diǎn)：最重要的是，不要直接在WEB服務(wù)器上用Flood進(jìn)行測試，如果你這樣做你僅僅是在測試一臺機器打開(kāi)一個(gè)網(wǎng)絡(luò )連接與自己通訊的能力，一定要在另一臺機器上進(jìn)行測試。要對自己機器的一些技術(shù)限制有所了解，這包括你機器容許的最大線(xiàn)程數和最大網(wǎng)絡(luò )連接數，如果你試圖創(chuàng )建超過(guò)這個(gè)限制的農夫將會(huì )帶來(lái)讓人難以理解的測試結果。Flood是一個(gè)客戶(hù)端解決方案，因此對于在多臺機器上進(jìn)行測試沒(méi)有任何限制。事實(shí)上我們推薦你這樣做，因為這是一個(gè)在想進(jìn)行飽和性測試時(shí)避免你的客戶(hù)機系統的技術(shù)限制的好方法。Flood測試由于是在客戶(hù)機上運行，它的表現也要依賴(lài)于客戶(hù)的性能，如果客戶(hù)機系統處于繁忙的狀態(tài)，Flood進(jìn)程會(huì )與其它客戶(hù)進(jìn)程一樣被阻塞，因此，最好使用一臺專(zhuān)用的客戶(hù)機進(jìn)行測試，如果客戶(hù)機上還運行著(zhù)其它任務(wù)，在開(kāi)始測試之前最好關(guān)掉它們。
Apache Web 服務(wù)器
Apache 的安裝
Red Hat Linux 9 自帶了Apache2.0，以下是Apache 的安裝步驟：
#rpm -qa|grep httpd
#mount /mnt/cdrom //將第 1 張光盤(pán)放入光驅后掛裝
#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
在安裝時(shí)，Apache 采用了一系列的缺省值，系統啟動(dòng)后，WWW 服務(wù)器已經(jīng)運行。將
裝上linux+apache 的主機聯(lián)入internet 后，把自己的主頁(yè)存到/home/httpd 目錄下即可。
5.2 Apache+PHP
安裝php
#mount /mnt/cdrom //將第 1 張光盤(pán)放入光驅后掛裝
#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 張光盤(pán)放入光驅后掛裝
#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 中中添加以下語(yǔ)句：
addtype application/x -httpd-php .php
addtype application/x -httpd-php-source .phps
然后修改php 配置文件php.ini
register_globals=on
重啟apache 服務(wù)器
#httpd restart
然后寫(xiě)個(gè)php 測試頁(yè)info.php 內容如下：
<?php
phpinfo （）
?>
測試php：打開(kāi)瀏覽器，在地址欄上輸入192.168.0.254/info.php
如果能看到php 的信息，則說(shuō)明apache+php 安裝成功。
5.3 Apache+jsp
整合JDK 和TOMCAT 環(huán)境
環(huán)境：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. 設置環(huán)境變量
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服務(wù)器故障的奇怪原因排查
伴隨著(zhù)對信息化要求的不斷提升，相信多數單位都會(huì )架設自己的Web服務(wù)器，來(lái)在Internet網(wǎng)絡(luò )中發(fā)布信息、宣傳自我。為了保證任何一位上網(wǎng)用戶(hù)都能順暢地訪(fǎng)問(wèn)到Web服務(wù)器中的內容，網(wǎng)絡(luò )管理員在正式發(fā)布Web信息之前往往需要設置一下IIS服務(wù)器，以便確保單位的Web網(wǎng)站可以始終如一地穩定運行。然而很多時(shí)候，我們都會(huì )遇到Web服務(wù)器訪(fǎng)問(wèn)失敗的故障現象，面對Web服務(wù)器故障，我們往往會(huì )表現得手忙腳亂，根本不知道該從何處著(zhù)手，來(lái)解決這些Web服務(wù)器故障。其實(shí)，造成Web服務(wù)器故障的因素有很多，我們需要對此進(jìn)行逐一排查，才能高效解決對應的Web服務(wù)器故障現象。
Web服務(wù)器故障現象
為了充分展示單位的形象，擴大單位的知名度，單位領(lǐng)導要求網(wǎng)絡(luò )管理員，立即拿出方案，組建有個(gè)性化特色的Web站點(diǎn)，不僅確保單位內部的員工可以通過(guò)內網(wǎng)正常訪(fǎng)問(wèn)Web站點(diǎn)，同時(shí)還要保證外網(wǎng)用戶(hù)也能快速地訪(fǎng)問(wèn)到本單位的站點(diǎn)內容。依照領(lǐng)導指示精神，網(wǎng)絡(luò )管理員立即行動(dòng)，挑選了一臺運行性能非常高效的計算機作為服務(wù)器系統，并在其中安裝、配置了Windows Server 2003系統，同時(shí)利用該系統自帶的IIS組件架設了Web服務(wù)器;為了提高Web站點(diǎn)的訪(fǎng)問(wèn)速度，網(wǎng)絡(luò )管理員特地將Web站點(diǎn)所在的計算機直接連到單位千兆核心交換機上，同時(shí)將目標主機的IP地址設置成與單位普通員工所用計算機處于相同網(wǎng)段的地址。剛開(kāi)始的時(shí)候，無(wú)論是內網(wǎng)用戶(hù)，還是外網(wǎng)用戶(hù)，所有用戶(hù)都能正常地訪(fǎng)問(wèn)單位的Web站點(diǎn)。
可是，沒(méi)有多長(cháng)時(shí)間，單位內網(wǎng)用戶(hù)在訪(fǎng)問(wèn)Web站點(diǎn)時(shí)，就遇到了訪(fǎng)問(wèn)失敗的Web服務(wù)器故障，具體表現為無(wú)論從哪一臺客戶(hù)端系統出發(fā)，使用內網(wǎng)地址訪(fǎng)問(wèn)單位的目標站點(diǎn)時(shí)，系統屏幕上都會(huì )彈出身份驗證對話(huà)框，要求單位員工必須輸入訪(fǎng)問(wèn)賬號與密碼，可是當網(wǎng)絡(luò )管理員嘗試以Web站點(diǎn)的系統管理員身份進(jìn)行登錄操作時(shí)，發(fā)現始終登錄不進(jìn)去;更讓人感覺(jué)到不可理解的是，網(wǎng)絡(luò )管理員趕到Web服務(wù)器現場(chǎng)，查看其安全配置時(shí)，發(fā)現目標Web站點(diǎn)根本就沒(méi)有啟用登錄驗證設置，那身份驗證對話(huà)框究竟是怎么彈出來(lái)的呢?
Web服務(wù)器故障排查
由于造成這類(lèi)Web服務(wù)器故障的因素比較多，我們必須要對各種可能因素進(jìn)行依次排查，才能找到具體的Web服務(wù)器故障原因，并對癥下藥采取針對性措施來(lái)快速解決故障現象：
Web服務(wù)器故障排查過(guò)程1、檢查安全登錄設置
考慮到在訪(fǎng)問(wèn)目標Web站點(diǎn)的時(shí)候，系統彈出了身份驗證對話(huà)框，這就意味著(zhù)目標Web站點(diǎn)可能在安全登錄方面沒(méi)有配置正確，造成了用戶(hù)訪(fǎng)問(wèn)Web內容時(shí)必須要輸入訪(fǎng)問(wèn)賬號。依照這樣的分析思路，網(wǎng)絡(luò )管理員準備先檢查一下Web服務(wù)器的安全登錄配置參數，看看其中的設置是否正確;想到做到，網(wǎng)絡(luò )管理員立即來(lái)到目標Web主機現場(chǎng)，以特權賬號登錄其中，并依次單擊“開(kāi)始”/“設置”/“控制面板”選項，從彈出的系統控制面板窗口中，找到“管理工具”功能圖標，并用鼠標雙擊該圖標選項，進(jìn)入對應系統的管理工具列表窗口;接著(zhù)再用鼠標雙擊IIS功能圖標，彈出對應系統的IIS主控臺窗口，從該窗口的左側列表區域，找到目標Web站點(diǎn)所在的計算機名稱(chēng)，并用鼠標右鍵單擊該計算機名稱(chēng)，從彈出的右鍵菜單中執行“屬性”命令，彈出目標Web主機的屬性設置窗口;在該屬性設置窗口中點(diǎn)選“目錄安全性”選項卡，打開(kāi)目錄安全性選項設置頁(yè)面;下面，在該設置頁(yè)面的“身份驗證和訪(fǎng)問(wèn)控制”設置項右邊，單擊“編輯”按鈕，進(jìn)入身份驗證和訪(fǎng)問(wèn)控制設置對話(huà)框，網(wǎng)絡(luò )管理員發(fā)現其中的“匿名訪(fǎng)問(wèn)”、“集成Windows驗證”等選項都處于選中狀態(tài)，于是他嘗試著(zhù)將這些參數選項取消選中，之后重新從內網(wǎng)的一臺計算機中進(jìn)行Web訪(fǎng)問(wèn)，可是相同的故障現象仍然存在;于是，網(wǎng)絡(luò )管理員再次選中了“匿名訪(fǎng)問(wèn)”、“集成Windows驗證”等選項，可是讓他感覺(jué)非常失望的是，上面兩個(gè)選項無(wú)論是選中還是沒(méi)有選中，好像故障現象都存在，這就說(shuō)明目標Web主機的安全登錄設置與上面的故障現象并沒(méi)有什么關(guān)系。
Web服務(wù)器安全的4個(gè)解決方案
Web服務(wù)器安全現在是很?chē)乐氐膯?wèn)題了，各種針對WEB服務(wù)器攻擊的方式層出不窮，如何應對成了重要的問(wèn)題，下面筆者給出4個(gè)解決方案，希望能幫助到你：
一、圈地運動(dòng)，已經(jīng)無(wú)法滿(mǎn)足安全的需求
在傳統解決方案中，有一個(gè)比較顯著(zhù)的特點(diǎn)，即搞圈地運動(dòng)。如針對郵件，有一套郵件安全方案;針對FTP，有一個(gè)FTP安全解決方案。傳統安全解決方案，將IT領(lǐng)域根據其應用的不同，認為的劃分成一塊塊領(lǐng)域，然后再設計對應的安全措施。如果只針對一種攻擊行為，這種安全解決方案，固然有效。但是在混合式攻擊面前，這種圈地性質(zhì)的解決方案，弊端就非常明顯了。因為攻擊者從一個(gè)方向攻擊不成，還可以從另一個(gè)方向攻擊。這種單獨的安全解決方案，無(wú)法做到面面俱到。為此企業(yè)Web應用的安全，不能夠再依靠防火墻等解決方案來(lái)做圈地式的保護運動(dòng)�；旌瞎魰�(huì )借助病毒、木馬、惡意軟件、肉雞等攻擊方法，對系統、應用程序等漏洞，發(fā)起攻擊。從而在比較大的范圍內發(fā)起攻擊。
筆者建議，在應對混合攻擊方面，要有一個(gè)比較全面的規劃，而不是各種解決方案各自為戰。在實(shí)際工作中，我們可以選擇一種解決方案為主，然后其它解決方案為輔，設計一個(gè)從上到下的全面的防護措施。如針對Web應用，筆者就推薦企業(yè)，可以以Web防火墻為主、然后結合郵件安全策略、FTP安全策略、SSL加密機制等手段，組成一個(gè)比較綜合的安全防護網(wǎng)。
二、漏洞，攻擊的源頭
混合攻擊，其實(shí)是多種已知攻擊手段的組合。而現在已知的攻擊行為，90%以上是針對系統以及應用程序的漏洞展開(kāi)的。俗話(huà)說(shuō)，蒼蠅不叮無(wú)縫的蛋。在實(shí)際工作中，我們只要保證蛋沒(méi)有縫，那么蒼蠅也就沒(méi)這么好叮了。
故筆者建議，針對各種混合攻擊行為，最好的預防措施之一就是對系統以及應用程序打上對應的補丁。不過(guò)需要注意的是，這個(gè)補丁不光光是針對服務(wù)器，而且還包括用戶(hù)的客戶(hù)端。因為有時(shí)候攻擊者非常狡猾，如果服務(wù)器攻不下的話(huà)，他們可能會(huì )先對客戶(hù)端做文章。先把客戶(hù)端拿下，做為他們肉雞，然后再對服務(wù)器發(fā)起攻擊。大部分時(shí)候，從內部發(fā)起攻擊，要比外部發(fā)起攻擊更加容易。畢竟堡壘更容易從內部攻破。但是有時(shí)候客戶(hù)端的數量非常的多，對每臺客戶(hù)端進(jìn)行補丁的管理比較困難。
在這里筆者推薦使用統一的補丁管理解決方案，如微軟的補丁維護方案。其原理比較簡(jiǎn)單。先是用一臺補丁服務(wù)器，從微軟的下載最新的補丁。然后各個(gè)客戶(hù)端(包括用戶(hù)終端和服務(wù)器)，每次啟動(dòng)時(shí)從服務(wù)器上下載最新的補丁，并進(jìn)行自動(dòng)或者手工的安裝。如果企業(yè)的安全級別比較高，筆者這里建議采用強制安裝。有時(shí)候補丁安裝會(huì )比較麻煩，如安裝完之后還需要重新啟動(dòng)。為此一些用戶(hù)會(huì )偷懶，當服務(wù)器提示需要安裝補丁時(shí)，他們會(huì )當作耳邊風(fēng)。不打補丁，從而給企業(yè)的Web應用安全留下隱患。針對這種情況下，采取強制措施，會(huì )更加的安全。采取強制安裝時(shí)，不會(huì )征詢(xún)用戶(hù)的意見(jiàn)。只要管理人員認為這個(gè)補丁重要，那么客戶(hù)端在重新啟動(dòng)后或者在線(xiàn)時(shí)就會(huì )強制安裝補丁。如果需要重新啟動(dòng)的話(huà)，也會(huì )先通知客戶(hù)端然后在一定的時(shí)間內重新啟動(dòng)，以完成補丁的安裝工作。
【W(wǎng)EB服務(wù)器多框架的解決方案】相關(guān)文章：
有關(guān)web服務(wù)器硬件配置的進(jìn)階知識08-20
Web Workers加速移動(dòng)Web應用07-01
web瀏覽創(chuàng )作效果精選08-01
Web開(kāi)發(fā)的教程圖解06-05
Web 2.0技術(shù)的內容08-13
集成spring與Web容器教程10-21
基于web的綜合測評與分析05-20
Web服務(wù)中的異常處理09-17