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

= “URL”

End sub

控制C中的文本框內容，在按鈕的ONCLICK事件中加入以下代碼：(VBScript)

sub b1_onclick

set Bframe = parent.B

e = “劉念”

‘txt1是C框架中文本框的Value值

end sub

2．新的框架結構

如上圖，我們定義了一個新的框架結構。在新的框架結構中，除了用來放置一、二級菜單的MENU1、MENU2和用來放置三級菜單及具體應用功能的Aapp之外，還增加了三個專門用來處理數據的框架（在上圖中用虛線表示）。這三個框架不需要界面，在應用執行的時候是看不見的。

淘寶Web服務器，Tengine-1.2.5 版本發佈

我們很高興的告訴大家，Tengine-1.2.5 版本正式發佈了。您可以在這裏下載：或者可以在github上檢出代碼：

本次發佈的亮點是新增加的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的網站上可以瀏覽更多信息：

Hiawatha 8.4發佈，安全的Web服務器

Hiawatha 是一個Linux/UNIX下安全的Web服務器，其設計的最主要的目的就是安全，當然它也是快速的而且易於配置。

Hiawatha 8.4 的改進內容：

MaxServerLoad option ix: invalid reverse proxy request when URL parameters are rSSL updated to version l 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 網關服務器：

Web 服務器01：

Web 服務器02：

在上述情況下，我們網關服務器（即 XR Crossroads）的IP地址是，webserver01 為，它監聽8888端口，webserver02 是，它監聽端口5555。

現在，我們需要的是均衡所有的請求，通過 XR 網關從網上接收請求然後分發它到兩個web服務器已達到負載均衡。

第1步：在網關服務器上安裝 XR Crossroads 負載均衡器

1. 不幸的是，沒有為 crossroads 提供可用的 RPM 包，我們只能從源碼安裝。

要編譯 XR，你必須在系統上安裝 C++ 編譯器和 GNU make 組件，才能避免安裝錯誤。

#yuminstallgccgcc-c++make

接下來，去他們的（）下載此壓縮包（即 ）。

或者，您可以使用 wget 去下載包然後解壓在任何位置（如：/usr/src/），進入解壓目錄，並使用 “make install” 命令安裝。

#wget#cdcrossroads-2.74/#makeinstall

安裝完成後，二進制文件安裝在 /usr/sbin 目錄下，XR 的配置文件在 /etc 下名為 “” 。

2. 最後一個條件，你需要兩個web服務器。為了方便使用，我在一台服務器中創建兩個 Python SimpleHTTPServer 實例。

要了解如何設置一個 python SimpleHTTPServer，請閲讀我們此處的文章 使用 SimpleHTTPServer 輕鬆創建兩個 web 服務器.

正如我所説的，我們要使用兩個web服務器，webserver01 通過8888端口運行在上，webserver02 通過5555端口運行在上。

XR WebServer 01

XR WebServer 02

第2步: 配置 XR Crossroads 負載均衡器

3. 所需都已經就緒。現在我們要做的就是配置 文件並通過 XR 服務器接受來自互聯網的請求分發到 web 服務器上。

現在用 vi/vim 編輯器打開文件。

#vim/etc/

並作如下修改。

true/tcp0:

配置 XR Crossroads 負載均衡器

在這裏，你可以看到在 中配置了一個非常基本的 XR 。我已經定義了 XR 服務器在哪裏，XR 的後端服務和端口及 XR 的 web 管理界面是什麼。

4. 現在，你需要通過以下命令來啟動該 XR 守護進程。

#xrctlstart#xrctlstatus

啟動 XR Crossroads

5. 好的。現在是時候來檢查該配置是否可以工作正常了。打開兩個網頁瀏覽器，輸入 XR 服務器的 IP 地址和端口，並查看輸出。

驗證 Web 服務器負載均衡

太棒了。它工作正常。是時候玩玩 XR 了。（LCTT 譯註：可以看到兩個請求分別分配到了不同服務器。）

6. 現在可以通過我們配置的網絡管理界面的端口來登錄到 XR Crossroads 儀表盤。在瀏覽器輸入你的 XR 服務器的 IP 地址和你配置在 中的管理端口。

XR Crossroads 儀表盤

看起來像上面一樣。它容易理解，用户界面友好，易於使用。它在右上角顯示每個服務器能容納多少個連接，以及關於接收該請求的附加細節。你也可以設置每個服務器承擔的負載量，最大連接數和平均負載等。

最大的好處是，即使沒有配置文件 ，你也可以做到這一點。你唯一要做的就是運行以下命令，它就會把這一切搞定。

#xr--verbose--servertcp:

上面語法的詳細説明：

-verbose 將顯示命令執行後的信息。-server 定義你在安裝包中的 XR 服務器。-backend 定義你需要平衡分配到 Web 服務器的流量。tcp 説明我們使用 TCP 服務。

欲瞭解更多詳情，有關文件及 CROSSROADS 的配置，請訪問他們的: .

XR Corssroads 使用許多方法來提高服務器性能，避免宕機，讓你的管理任務更輕鬆，更簡便。希望你喜歡此文章，並隨時在下面發表你的評論和建議，方便與我們保持聯繫。via:

如何用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 ::/home/cvspublic login$ cvs -d ::/home/cvspublic co httpd-test/flood$ cd httpd-test/flood$ cvs -d ::/home/cvspublic co apr$ cvs -d ::/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目錄下有一個樣例設置文件，可能是一個最適合初學者學習的例子，不過本文並不準備就編輯此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 0.0028 0.0183 0.0190 700 0.0033 0.0109 0.0120 100 0.0031 0.0089 0.0107 100 0.0029 0.0087 0.0096 100 : 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

#rpm -ivh

#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

#rpm -ivh //安裝php 所需的curl 和gd

#rpm -ivh //安裝php

#rpm -ivh //安裝php 的imap 支持包

#cd;eject

#mount /mnt/cdrom //將第2 張光盤放入光驅後掛裝

#cd /mnt/cdrom/red hat/rpms

#rpm -ivh //安裝php 手冊

#rpm -ivh //安裝php 的mysql 支持包

#rpm -ivh //安裝php 的pgsql 支持包

#cd;eject

在文件/usr/local/apache/conf/ 中中添加以下語句：

addtype application/x -httpd-php

addtype application/x -httpd-php-source

然後修改php 配置文件

register_globals=on

重啟apache 服務器

#httpd restart

然後寫個php 測試頁 內容如下：

<?php

phpinfo （）

?>

測試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 ：//_4_2_

#chmod a+x j2sdk-1_4_2_

#./j2sdk-1_4_2_

將所下載的j2sdk 複製到目錄/usr/local/下面以/j2sdk 為目錄

2. 安裝tomcat

#cd /usr/local/

#wget http：//

#tar zxf

將下載的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：//

#tar zxf

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應用安全留下隱患。針對這種情況下，採取強制措施，會更加的安全。採取強制安裝時，不會徵詢用户的意見。只要管理人員認為這個補丁重要，那麼客户端在重新啟動後或者在線時就會強制安裝補丁。如果需要重新啟動的話，也會先通知客户端然後在一定的時間內重新啟動，以完成補丁的安裝工作。