二、支持服務

　　自IIS 6.0發布以來，它的某些新特性一直是人們關注和議論的焦點，成為眾人矚目的明星，但另一些Internet支持服務雖然不是經常有人說起，卻同樣值得關注，其中之一就是POP3服務和POP3服務Web管理器。我們無從得知微軟為何不在“應用程序服務器”組件清單中列出POP3服務，但是繼SMTP服務之后（SMTP服務隨同POP3服務一起安裝），管理員們盼望POP3服務已經很久了，他們一直在期盼著用一個簡單的POP3服務來替代龐大的Microsoft Exchange Server。

　　統一描述、發現和集成協議（Universal Description, Discovery, and Integration，即UDDI）服務是Windows 2003提供的又一種新的功能，它也與IIS有關，但默認不安裝（注意，Windows 2003 Web版不能安裝UDDI）。UDDI是一種產業標準（即不是微軟的發明），能夠通過廣告發布IIS服務器提供的Web服務――這里“廣告”一詞的含義與日常生活中的廣告不同，它是指一種讓客戶程序（通常是Web瀏覽器）獲知Web服務（通常是ASP.NET應用）各種細節的方式。UDDI仍在發展之中，但一些企業已經在內部采用UDDI，以便開發者將自己的代碼發布給其他協作開發的人。有關UDDI的更多知識，可以在下列網站找到：http://www.uddi-china.org/（中文），http://www.uddi.org（英文），http://www.uddicentral.com（英文）。

　　最后一種重要的支持服務是后臺智能傳送服務，即 Background Intelligent Transfer Service或BITS。BITS是一種后臺文件傳輸機制和隊列管理器，也稱作節流傳輸服務。BITS控制文件請求，減少帶寬消耗并改善最終用戶的體驗。針對IIS啟用BITS可保證Web服務器的服務質量，如果沒有BITS，當100個用戶同時下載一個500 MB的文件，服務器的帶寬可能就被消耗殆盡，導致其他訪問Web服務的用戶頻繁地遇到超時錯誤。如果BITS就象廣告說的那樣有效，可以料想它將是一種非常實用的服務。Windows 2003發布之后，按照計劃，BITS還將移植到Win2K上。關于BITS的更多信息，請參見http://www.microsoft.com/windows.netserver/techinfo/overview/bits.mspx。


　　三、全新的內核

　　從體系結構上看，IIS 5.0和IIS 4.0其實是一樣的：它們都是在用戶模式下運行的發布Web內容的應用程序，或者在Inetinfo進程之內以System帳戶運行，或者在Inetinfo進程之外以IWAM用戶運行。雖然在較重的負載下，IIS 5.0也有相當出色的表現；不過從IIS 6.0開始，我們對IIS底層結構的看法應該改變了。為了使IIS不僅能夠輕松地支持1000個Web網站，而且能夠支持10000個甚至更多的網站，同時還要提高Web服務器的安全性和可靠性，微軟放棄了原有的IIS內核，重新構造了一個。

　　另一個促使微軟重新構建IIS內核的原因是，微軟（以及其他廠商）認識到，Web服務器的性能和可靠性問題絕大部分是由于質量低劣的Web應用造成。IIS 5.0通過帶緩沖池的Out of Process容器減輕這類問題。在IIS 5.0中，在Out of Process池中運行的應用一旦崩潰，一般不會波及到IIS本身，因為應用程序在Inetinfo之外的進程中運行，但運行在Out of Process池之內的所有Web應用都會終止――在默認情況下，所有的應用程序都在該池之中運行。在這種情況下，排解故障很不容易，因為要確定哪一個應用程序導致了問題非常困難。IIS 6.0將監聽請求、創建和監視Web網站、運行Web服務這些不同的任務隔離了開來，這一新型體系可望解決IIS 5.0存在的問題。從理論上看，新的體系將極大地改善可用性、安全和性能；從實際情況看，根據微軟和Beta測試者的報告，新的體系令穩定性和性能有了奇跡般地提高。IIS 6.0的內核體系主要建立在三個組件之上：W3SVC，http.sys，以及W3Core。

　　■ W3SVC

　　W3SVC也許是IIS 6.0體系中最不令人注意的組件，不過這并不說明它不重要。W3SVC的任務是根據配置數據的設置創建和監視工作線程，由工作線程運行Web網站應用。在IIS 5.0中，與IIS 6.0 W3SVC組件最接近的是IIS管理服務，IIS管理服務是Inetinfo的一部分；
因此，如果Inetinfo出現問題，IIS管理服務也會出現問題，而且此時的IIS管理服務不能再重新啟動Inetinfo或其他故障的應用程序。在IIS 6.0中，W3SVC作為一個獨立的進程運行，Web應用的故障不可能波及W3SVC，因為W3SVC之內根本沒有第三方的代碼運行。W3SVC總是處于運行狀態，因此它能夠監視Web應用的健康狀況，并在必要時采取行動。由于這一策略，服務器能夠根據用戶指定的參數監視和重新啟動應用程序。

　　■ http.sys

　　IIS 6.0體系設計中最重大的變化是加入了http.sys驅動程序，http.sys驅動程序的任務是處理HTTP請求，而且它在內核模式下執行操作。不要小看這一改變，將處理HTTP請求的任務從IIS 5.0、IIS 4.0的用戶模式改變到IIS 6.0的內核模式標志著新一代IIS服務器的誕生。

　　在Win 2K和NT 4.0中，IIS在用戶模式下運行。運行在用戶模式下的應用程序不直接與硬件通信，它們直接調用的是一些標準過程，這些標準過程或者將數據傳入內核模式的組件（例如網卡驅動程序，圖形子系統），或者調用內核模式組件的函數，以此完成保存文件、設置IP地址、將HTML文件發送到網絡之類的任務。

　　用戶模式和內核模式之間的轉換是一項開銷很大的操作，服務器首先從內核模式的TCP/IP棧將傳入的HTTP請求傳遞給用戶模式的Winsock，由Winsock將請求傳遞給IIS。從內核模式到用戶模式的切換很快發生，但不可避免地給處理過程帶來瞬間的延遲。當負載較大時，這種延遲不斷累加，同時由于這種轉換是必不可少的，所以管理員根本沒有辦法優化處理過程。

　　IIS 6.0的https.sys內核模式驅動程序極大地減少了用戶模式和內核模式之間的切換次數。http.sys監聽著HTTP請求，決定由哪一個用戶模式的進程來處理該請求，或者是否由驅動程序本身返回用戶請求的內容。

　　IIS 6.0在用戶模式下運行，完全依賴內核模式的http.sys作為接收用戶請求的服務器引擎。因此，http.sys必須能夠在任何時候作出相應，必須具有極高的可靠性。用戶代碼可能導致進程出錯，所以微軟把http.sys設計成不執行任何用戶代碼，這樣，即使應用程序出現了故障，也不會影響到IIS 6.0本身，IIS 6.0仍能夠照常監聽HTTP請求。

　　如果要從內核模式的緩沖區返回靜態的應答，一個高速的、內核模式的、不允許運行應用程序代碼的HTTP處理器是十分理想的，它減少了切換到用戶模式的昂貴開銷，能夠從內核模式的緩沖區快速返回應答。IIS 6.0的http.sys就管理著這樣一個緩沖區，而且使用了高度優化的啟發式緩沖區算法來確定哪些內容要放入緩沖區，例如，http.sys可能只緩沖那些出現了一次以上請求的內容。

　　由于http.sys直接從應答緩沖區提取靜態內容，不必再切換到用戶模式，所以與IIS 5.0的性能相比，IIS 6.0的整體性能有了顯著提升。根據微軟的資料顯示，WebBench基準測試表明IIS 6.0返回靜態內容的速度要比IIS 5.0快150％。即使以IIS 5.0的隔離模式運行IIS 6.0服務器（這時，IIS 6.0的體系結構與IIS 5.0的相似），同樣也能從http.sys驅動程序的應答緩沖區和其他改進之處獲益。

　　另外，微軟在http.sys驅動程序中采用了許多優化的算法，使其能夠將請求直接轉發到適當的工作進程。在IIS 4.0和IIS 5.0中，必須通過多個步驟才能確定進程的哪一個實例擁有了應當接收當前請求的Web應用，但在IIS 6.0中，http.sys注冊了所有IIS 6.0應用，賦予每一個進程一個句柄，IIS內部利用這些句柄來標識注冊的應用程序要用到的一個或多個名稱空間。因此，當http.sys接收到一個HTTP請求，它能夠很快地將請求從內核模式的http.sys傳遞到正確的用戶模式的Web應用。

　　http.sys驅動程序還要執行其他一些任務，其中包括：

　　⑴ 將傳入的URL與各種長度、格式方面的規則進行比較。

　　⑵ 管理傳入請求的隊列。

　?、?擔負著記錄IIS Web網站日志信息的任務（從而提高了記錄日志的性能）。

　?、?實施帶寬限制策略以及支持TCP/IP級的管理。

　?、?實現客戶證書請求服務（但不支持安全套接字層――SSL）。

　　由于http.sys是一個操作系統的驅動程序，而不是一個IIS組件，因此該驅動程序的配置在注冊表而不是IIS配置數據中進行。當前，還有許多http.sys的注冊表設置項目尚無正式的說明文檔，它可能意味著微軟不鼓勵用戶修改這些設置，因為這些設置項目將來可能會有變化。http.sys驅動程序的注冊表設置項目位于
HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/HTTP下面，在這里可添加各種注冊鍵（默認配置中不包含這些注冊鍵），諸如：

　?、?EnableNonUTF8：如果加入EnableNonUTF8子鍵，并將它的值設置成0，http.sys只接受UTF-8編碼的URL。UTF-8的全稱是Universal Character Set（UCS）Transformation Format 8，這是一種字符集標準，標準全文在http://www.ietf.org/rfc/rfc2279.txt，它允許使用多國語言的字符集。默認情況下，EnableNonUTF8的值是1，表示IIS接受UTF-8、ANSI、雙字節字符集（DBCS）編碼的URL。

　?、?PercentUAllowed：當這個子鍵設置成1時（默認值），http.sys認可那些部分字符用％uNNNN表示的URL，其中NNNN是一組表示實際字符的數字。當PercentUAllowed設置成0時，IIS 6.0將拒絕那些部分字符用這種方式表示的URL。

　　％uNNNN是一種不太常用的Unicode符號，不要將它與常見的UTF-8表示形式混淆。在UTF-8表示形式中，％20表示一個空格，例如http://www.iisanswers.com/new article.htm相當于http://www.iisanswers.com/new％20article.htm，兩者之間的轉換由IE瀏覽器自動完成，不管EnableNonUTF8和PercentUAllowed設置成了什么值，IIS 6.0都會接受。

　　這兩項設置，再加上其他可以在IIS 6.0文檔中找到的設置項目，從一個側面反映了IIS 6.0在URL解析方面的改進。在IIS 5.0中，一些重大的安全問題與Web服務器解析URL的方式有密切的關系，現在微軟終于解決了原先存在的缺陷，同時作出了一些改進，允許管理員更加明確地定義IIS 6.0解析URL的規則。在天生具有國際化特點的Internet上，多國語言并存，這些改進之處尤其具有重要意義。

　　關于Unicode的更多信息，請參見http://www.unicode.org；關于IIS 5.0缺陷的更多信息，請參見 http://www.wiretrip.net/rfp/p/doc.asp/i5/d57.htm。在Windows Server 2003 Resource Kit中可以找到一個幫助配置http.sys的工具。

　　■ W3Core

　　默認情況下，IIS 6.0在工作進程隔離模式下運行，如圖五所示。在這種模式中，對于每一個Web應用，IIS 6.0都用一個獨立的w3wp.exe的實例來運行它。w3wp.exe也稱為工作進程（Worker Process），或W3Core。




　　圖五


　　因此，工作進程隔離模式不存在進程內（In-Process）應用程序存在的問題，有效地提高了可靠性和安全性?？煽啃缘奶岣呤且驗橐粋€Web應用的故障不會影響到其他Web應用，也不會影響http.sys，每一個Web應用由W3SVC單獨地監視其健康狀況。安全性的提高是由于應用程序不再象IIS 5.0和IIS 4.0的進程內應用那
樣用System帳戶運行，默認情況下，w3wp.exe的所有實例都在一個權限有限的“網絡服務”帳戶下運行，如圖六所示，必要時，還可以將工作進程配置成用其他用戶帳戶運行。




　　圖六

　　如果緩沖區溢出攻擊成功入侵了一個Web應用，攻擊者只能訪問當時運行工作進程的帳戶有權訪問的資源，默認的網絡服務帳戶不能寫入Inetpub文件夾，執行權限也極其有限，所以象CodeRed蠕蟲之類的攻擊根本不可能得逞。

　　某些Web應用，特別是有些Internet Server API（ISAPI）篩選器，在進程外運行時可能會遇到問題。在IIS 5.0和IIS 4.0中，ISAPI篩選器總是在Inetinfo之內運行，它們的設計目標本來就不是在進程外運行，正是由于這個原因，某些篩選器在IIS 6.0的工作進程隔離模式中運行時可能會出現問題――特別地，調用SF_READ_RAW_DATA或SF_SEND_RAW_DATA的篩選器尤其明顯。為此，IIS 6.0還提供了第二種操作模式，稱為IIS 5.0隔離模式。如果ISAPI篩選器不能在工作進程隔離模式下正常運行，在IIS 5.0隔離模式下應該沒有問題。在這第二種操作模式中，應用程序仍舊能夠從IIS 6.0的許多改進中獲益，例如http.sys驅動程序帶來的性能、可靠性的提高。

　　在IIS 6.0文檔中，可以看到一種叫做“應用程序池”的新特性。一個應用程序池包含一個或者一組工作進程，而且應用程序池是可以命名的。應用程序池可以從下列角度理解：在IIS 5.0中，我們可以將應用程序保護設置為低級（IIS進程）、中級（緩沖池）、高級（隔離），這個功能雖然很有用，但如果我們想要在一個池（一個dllhost.exe的實例）中運行兩個應用程序，在另一個池（另一個dllhost.exe的實例？）中運行另外兩個應用，該怎么辦？IIS 5.0沒有提供命名dllhost.exe實例的途徑，因而也就不能將兩個特定的應用放入某個池運行。IIS 6.0的應用程序池允許指定名稱，如圖七，通過網站“屬性”對話框的“主目錄”頁，可以方便地將Web網站或目錄放入應用程序池。




　　圖七

　　四、應用程序池詳解

　　前面我們了解了IIS 6.0體系結構的關鍵組件，下面來看看有關應用程序池的一些問題。應用程序池的“屬性”對話框有四頁――回收，性能，運行狀況，標識，如圖六所示。在這些選項頁中，最引人注目的恐怕就是“回收”頁，使用該選項頁可以管理工作進程的回收。在工作進程隔離模式中，
IIS可以配置成定期重新啟動應用程序池中的工作進程，從而更好地管理那些有錯誤的工作進程。這確保了池中的應用程序運行正常，并且可以恢復丟失的系統資源。為了回收工作進程，失敗工作進程接收請求的能力將被限制，直到它處理完存儲在請求隊列中的所有剩余請求。為了排出當前請求，可以給予進程配置限制。同一命名空間組的替換工作進程在舊的工作進程停止前啟動，從而防止服務中斷。舊的進程完成其未決的請求，然后正常關閉，或者如果在達到了配置的時間限制、請求數、設置的時間計劃，或當達到指定的內存用量限制后仍沒有關閉，則明確地終止進程。默認情況下，應用程序池每隔1740分鐘（29小時）回收一次。

　　W3SVC根據“運行狀況”頁的選項來判斷應用程序池運行是否正常，包括：每隔指定的時間Ping工作進程，時間按秒計，默認值30秒；啟動時間限制（工作進程必須在指定的時間內開始）；關閉時間限制（工作進程必須在指定的時間內關閉）；是否啟動快速失敗保護（如果在指定的時間段內一定數目的工作進程發生失敗，則禁用應用程序池）。另外，ISAPI應用程序（包括ASP.NET和asp.dll）可以聲明自己不再適合提供服務，要求回收。

　　默認情況下，當IIS 6.0回收一個池時，它會使用一種稱為overlapped recycle的回收技術。在這種回收模式下，失敗的工作進程仍會保持運行狀態，同時創建一個新的工作進程。IIS 6.0把新傳入的請求傳遞給新的工作進程，但不拆除老的工作進程，直至老的工作進程處理完它隊列中的請求，或者遇到超時錯誤。在此期間，TCP/IP連接不會丟失，因為有http.sys保持著連接的有效性。當失敗的工作進程超時出錯時，下一個請求傳遞給工作進程的請求是新的請求，因此原來保存在進程中的會話信息就會丟失。所有這類回收操作都自動進行，無需管理員干預，而且在大多數情況下，不會造成明顯的服務中斷現象。如有必要，可以將配置數據屬性LogEventOnRecycle的值設置為1，指示W3SVC執行回收操作時生成一條事件日志記錄。

　　對于那些不能以多個實例運行的應用程序，overlapped recycle回收技術可能引起問題。如果遇到這類問題，可以將配置數據屬性DissallowOverlappingRotation的值設置成True（1），關閉某個應用程序池回收操作時的進程“重疊”現象。另外，對于失敗的工作進程，有時我們可能不想將它拆除，仍舊保留該進程，以便檢測和尋找發生問題的根源，這時可以將配置數據屬性OrphanActionExe設置成執行文件的名字，使得工作進程成為“孤兒”時執行文件仍保持運行狀態。

　　另一個與應用程序池有關的特性是，IIS 6.0允許將應用程序池配置成一個Web園（Web Garden）。要理解Web園的概念，可以設想這樣一種情形：假設有一個IIS 5.0服務器和三個Web網站，每一個Web網站運行著相同的應用程序，如果IIS 5.0能夠自動按照圓形循環的模式將請求依次發送給這些功能上等價、實際上分離的Web網站，將負載分離到三個不同的進程，就可以構成一個小型的Web農場（Web Farm）――這就是Web園。

　　在IIS 6.0的Web園中，我們不必創建額外的Web網站，只要指定用于某個應用程序池的工作進程的數量就可以了。具體的配置步驟是：打開應用程序池的“屬性”對話框，轉到“性能”頁，在“Web園”下面的“最大工作進程數”輸入框中輸入進程數量，如圖八。當服務器的負載較小，不需要額外的工作進程時，IIS 6.0在一定的時間后（默認20分鐘，可配置）自動縮減實際的工作進程數量；如果負載變大，需要額外的工作進程，IIS 6.0再次增加工作進程數量。這一切操作都自動進行，不需要管理員干預。



　　圖八

　　兩個新的配置數據屬性――SMPAffinitze和SMPAffinitzeCPUMask――允許配置為工作進程指派的特定處理器：將SMPAffinitized屬性設置成true表示應該把分配給應用程序池的特定工作進程指派給特定的CPU，SMPProcessorAffinityMask屬性用來配置十六進制的處理器掩碼，該十六進制處理器掩碼指出應用程序池中的工作進程應該綁定到哪個CPU。

　　寫到這里，文章的篇幅似乎已經太長了。本文主要從體系結構的角度介紹IIS 6.0的新特性，并且盡力做到全面，至少要比通常見到的介紹更完善一些。文章的第二部分將涵蓋更多的IIS 6.0新特性，你會發現許多新特性正是自己長久以來盼望的。

　　前文介紹了IIS 6.0的安裝和Web服務器的新型體系結構。IIS 6.0新特性的數量多得令人驚奇，其中一些特性是如此引人注目，以至于人們的大部分注意力都被它們吸引。在這第二篇介 紹IIS 6.0的文章中，我們不僅將了解這些已成為“明星”的特性，還將關注一下IIS 6.0各種較少有人注意卻同樣重要的改進之處。

　　一、安全

　　微軟一次又一次地做著同樣一件事情――某個軟件產品出了問題，飽受人們詬病，于是趕緊發布新的版本將問題解決。例如，發布Windows NT 4.0之后，因穩定性問題而飽受批評；于是微軟發布了Windows 2000，新操作系統的穩定性頗受好評，但Win 2K服務器默認安裝的IIS 5.0卻成了巨大的安全隱患，需要下大力氣加以整治才能解決問題。IIS 6.0默認不安裝，如果按照缺省方式安裝，Web服務器只能提供靜態內容服務。因此，從這個角度看，即使以后IIS 6.0應用引擎和組件突然出現了問題，IIS 6.0還是極大地降低了安全風險。另外，Windows Server 2003還有一個新的組策略“禁止安裝IIS”，有了該組策略，我們就可以禁止Windows 2003在活動目錄（AD）森林中禁止不準備作Web服務器用的機器上安裝IIS 6.0，防止網絡上出現根本無用的、不安全的IIS 6.0服務器。不過，目前這個組策略只對Windows 2003服務器有效，不能防止Windows XP Pro和Win 2K的機器安裝IIS 5.0。

　　當然，由于剛剛安裝好的IIS 6.0不支持動態內容，所以出現了第二個人們經常會問的問題：“為什么我的服務器不能運行ASP？”（前文提到，第一個人們經常會問的問題是：“IIS 6.0可以在Win 2K服務器上運行嗎”？答案是“不”）。要想在IIS 6.0上運行程序，必須使用IIS 6.0的一種新特性，即Web服務擴展，或Web Service Extension（這個名字似乎意味著它與XML Web服務有某種關系，實際情況并非如此。）


　　如果要為某個程序啟用Web服務擴展，首先打開IIS管理器（在“控制面板”→“管理工具”中。以前叫做Internet服務管理器或ISM），如圖一，點擊“添加一個新的Web服務擴展”，啟動向導創建一個新的規則。為規則指定一個名字，然后找到想要啟用的執行文件。另外，/system32/inetsrv下有一個iisext.vbs腳本，它也能夠配置并管理運行帶有IIS 6.0的Windows Server 2003的Web服務擴展、應用程序和單獨的文件。管理員可以使用此腳本來啟用和列出應用程序；添加和刪除應用程序依賴性；啟用、禁用和列出 Web 服務擴展；添加、刪除、啟用、禁用和列出單獨文件。




　　圖一

　　在圖一中，注意“所有未知ISAPI擴展”和“所有未知CGI擴展”這兩種Web服務擴展。默認情況下，這兩種擴展是禁用的，意味著除非明確地允許一個應用在IIS 6.0上運行，否則它就不能運行。如果一個用戶請求了某個沒有啟用的文件，IIS 6.0將向用戶返回404錯誤――文件或目錄沒有找到，同時在W3SVC日志中記錄“
404.2文件或目錄無法找到：鎖定策略禁止該請求”。在IIS 6.0中，404.2和其他子狀態代碼是W3SVC日志文件的一項可選功能，用來幫助排解故障、疑難（IIS 5.0和IIS 4.0中也有子狀態代碼，不過不會在日志文件中記錄，但可以將它們轉到定制的錯誤頁面，便于根據子狀態代碼執行特殊的處理）。IIS 6.0的子狀態代碼很有用，它們提供了描述問題的詳細信息，例如：403.20，禁止訪問：Passport登錄失??；403.18，禁止訪問：無法在當前應用程序池中執行請求的URL；404.3，文件或目錄無法找到：MIME映射策略禁止該請求；500.19，服務器錯誤：該文件的數據在配置數據庫中配置不正確。所有這些錯誤和其他錯誤都映射到定制的錯誤頁面，錯誤頁面不會把子狀態代碼發送給用戶，攻擊者無法獲知具體的錯誤信息。

　　另一個安全方面的改進之處是IIS 6.0允許指派一個加密服務提供者（Cryptographic Service Provider，CSP），能夠將基于硬件的安全套接字層（SSL）加速器集成到IIS 6.0，從而把加密任務從服務器的通用CPU轉移到了專門為加密操作而優化的專用設備，有利于提高性能和可靠性。

二、配置數據

　　在IIS 5.0和IIS 4.0中，配置數據庫采用二進制文件結構，但IIS 6.0放棄了這一做法。IIS 6.0的配置數據由兩個XML文件構成：一個是Metabase.xml，包含IIS 6.0服務器的配置信息；另一個是mbschema.xml，包含配置數據的模式定義。IIS管理器提供了一項新的功能，允許保存配置數據副本，只要右擊Web網站，然后選擇“所有任務”→“將配置保存到一個文件”，然后指定配置數據副本的文件名字和保存路徑即可。按照這種方式保存配置數據時，IIS 6.0利用系統的機器碼（Machine Key）加密配置數據的某些部分，因此，配置數據的副本只對創建該副本的機器有用。

　　不過，在“將配置保存到一個文件”對話框中，我們可以選中“用密碼對配置進行加密”選項，然后指定密碼，用密碼來保護導出的配置文件。如果提供了密碼，IIS 6.0將用密碼來替代機器碼，以后只要提供同一個密碼，就可以將配置數據導入到另一個服務器。另外，我們可以使用命令行腳本iisback.vbs（在systemroot/System32中）創建和管理遠程或本地計算機的IIS配置的備份副本，管理員可以使用此腳本工具創建其IIS配置的備份副本，從備份副本還原IIS配置以及列出和刪除備份副本。

　　有些時候，我們只要保存某個應用程序池、Web網站或虛擬目錄的配置，而不是保存全部的配置信息，這時可以按照如下步驟操作：右擊要保持配置信息的對象，選擇菜單“所有任務”→“將配置保存到一個文件”，如圖二所示，如果準備將配置數據導入到另一個服務器，必須提供加密文件的密碼。




　　圖二
　　如果右擊一個應用程序池、Web網站組或單個網站，然后選擇“新建”→“應用程序池（來自文件）”，或者“新建”→“網站”→“來自文件”，或者“新建”→“虛擬目錄（來自文件）”，就可以從保存的配置文件創建新的應用程序池、Web網站或虛擬目錄。因此，必要的時候，我們可以只創建和配置一個對象，利用“將配置保存到一個文件”功能導出對象
的配置信息，然后利用“新建”→“虛擬目錄（來自文件）”等功能將配置信息導入到多個Web網站。這就是說，我們可以先精心配置一個模板，然后用它來創建和配置新的網站。當然，出現問題時，配置信息副本還可以用來恢復網站的設置。

　　由于IIS 6.0配置信息是可移植的，它還有另外一個好處，這就是方便了升級。假設我們升級時不能直接在Win 2K/IIS 5.0上安裝Windows 2003/IIS 6.0，必須換一臺機器，這時就要解決如何將IIS 5.0不可移植的配置數據轉移到新的IIS 6.0服務器的問題。利用IIS 6.0配置數據的可移植性，解決辦法是：首先安裝好新的Windows 2003服務器，為原來的Win 2K服務器做一個完整的備份，然后在Win 2K服務器上安裝第二個Windows 2003服務器將它升級，導出第二個Windows 2003服務器的配置數據（用密碼加密），然后將配置數據導入到新的Windows 2003服務器。新安裝的Windows 2003服務器必須作一些調整，例如允許IUSR帳戶等，但至少現在不必重新執行全部配置操作了。

　　IIS 6.0的配置數據是標準的文本文件（XML文件），所以可以用記事本之類的文本編輯器打開和編輯。如果修改了IIS 5.0或IIS 4.0的配置數據，有時必須重新啟動IIS，如果系統上網站的數量很多，可能需要不少時間，例如ISP的服務器就屬于這類情況。為了解決這個問題，IIS 6.0支持一種“運行時允許編輯”功能?！斑\行時允許編輯”功能按照如下方式啟用：在IIS管理器中，右擊服務器，選擇菜單“屬性”，然后選中“允許直接編輯配置數據庫”選項，如圖三所示。啟用了這個功能之后，如果我們用記事本打開配置數據文件，插入一個虛擬目錄的配置，然后保存并關閉配置文件，IIS 6.0幾乎立即就能根據配置文件的設置作相應的修改，根本無需重新啟動。




　　圖三

　　既然允許直接編輯配置文件，因配置文件不合法造成的服務器、應用程序故障也必然增多。為此，IIS 6.0提供了配置文件歷史版本目錄，即/system32/inetsrv/history，每次修改配置數據或重新啟動IIS 6.0，IIS 6.0都會在該目錄中保存一份原有的配置數據。
三、IIS管理器

　　每次產品重大升級，人們都會試圖從用戶界面尋找令人激動的新功能。IIS 6.0的管理器確實有了變化，不過改動之處出乎意料地少。

　　其中一個改動之處雖小，但很實用。如果在IIS管理器中右擊一個文件夾，現在可以選擇“權限”菜單打開文件夾的“安全”對話框。在這個對話
框中可以設置文件夾的NTFS授權，不必再離開IIS管理器。雖然這是一個小小的改動，也許它今年會為全世界所有的IIS管理員總共節省數千小時的工作時間。

　　右擊一個Web網站，選擇“屬性”，轉到“目錄安全性”頁，點擊“安全通信”下面的“編輯”按鈕，在這里可以找到另一個重要的改動之處――安全通信屬性頁允許配置SSL、證書信任列表（CTL）、客戶證書。在IIS 5.0和IIS 4.0中，除非在Web網站上安裝一個證書，否則不能訪問該屬性頁，這一限制令人不快，因為從技術上看，配置CTL、客戶證書并不要求服務器上安裝了證書，換句話說，在IIS 5.0中我們安裝證書的唯一用途可能就是因為用戶界面需要它。IIS 6.0改正了這一多余的要求，現在我們不必在Web服務器上安裝證書也可以訪問和使用該屬性頁了。

　　四、通配符應用程序

　　如果你熟悉IIS 5.0和IIS 4.0的ISAPI篩選器，可能也熟悉它們的缺點。ISAPI篩選器不僅編寫困難，而且由于它們在Inetinfo進程內運行，如果編寫時不小心留下了一點錯誤，很容易導致災難性的后果，出錯的代碼可能造成整個IIS崩潰。另外，ISAPI篩選器不能擁有常規ISAPI DLL擁有的功能。當然，不管怎樣，在IIS 5.0和IIS 4.0中，ISAPI篩選器仍是一種非常有用的組件，是唯一可以針對所有進入Web服務器或Web網站的請求執行操作的代碼。

　　IIS 6.0提供了一種更加靈活的新型機制來提供通常由ISAPI篩選器提供的服務，它就是ISAPI截取器（Interceptor），或者稱為通配符應用程序（Wildcard Application）。通配符應用程序的配置方式是：在IIS管理器中右擊Web網站，選擇菜單“屬性”，轉到“主目錄”頁面，點擊“應用程序設置”下面的“配置”按鈕，出現“應用程序配置”對話框，如圖四所示。在對話框的“映射”頁中，我們可以將一個或多個ISAPI DLL配置成通配符應用程序。對于每一個接收到的請求，IIS 6.0將調用這里列出的各個通配符應用程序。除了針對所有網站配置通配符應用程序，還可以針對單個網站或在目錄層次上配置通配符應用程序。由于這些ISAPI截取器是標準的ISAPI應用程序，它們具有普通ISAPI應用程序具備的所有功能，包括訪問消息正文的能力，而不僅僅象ISAPI篩選器那樣訪問消息頭。




　　圖四

　　通配符應用程序可以做到開發者要做的任何事情，諸如URL定制、驗證身份、記錄特殊的日志信息、檢測攻擊企圖、創建內容，等等。通配符應用程序結束處理后，它把請求轉交給適當的處理引擎（例如處理ASP頁面的asp.dll），由處理引擎進一步處理請求。另外，通配符應用程序還可以通過調用為ISAPI應用程序新增的ExecuteURL功能
，將請求傳遞到同一個應用程序池中的任意頁面。

　　新增的ISAPI通配符應用程序為創造性的應用程序設計大開方便之門。例如，IIS 6.0的URL授權功能就是作為一個ISAPI通配符應用程序（urlauth.dll）實現。URL授權功能允許IIS 6.0根據一系列的規則授予對某個URL的訪問權，例如用戶是否為某個組的成員、地理位置，以及其他在數據庫或AD中與用戶有關的信息。有關ISAPI通配符應用程序和URL授權的更多信息，請參見IIS 6.0的幫助文檔。
五、日志功能

　　服務器的日志功能很少成為首要的關注對象，但卻是日復一日的服務器管理和監視工作不可或缺的助手。IIS 6.0在日志功能方面有許多重大的改進，但遺憾的是，W3SVC日志事件仍不能以本地時間記錄。

　　在IIS 6.0中，記錄日志的功能已經改為由http.sys實現，http.sys在內核模式下運行。這一改進加快了日志寫入速度，同時避免了多個工作進程爭用同一日志文件。某些特殊的情況下，http.sys會遇到錯誤，這時它應該但卻不能將日志信息寫入Web網站的日志，例如，工作進程正在被回收，禁止http.sys處理用戶請求，或者用戶試圖連接到服務器，但請求中只提供了IIS所需信息的一部分。如果出現這類情況，http.sys將把事件寫入一個新的日志文件httperr.log。

　　在排解故障、優化IIS 6.0的過程中，httperr.log日志文件是十分重要的。默認情況下，httperr.log文件保存在/system32/logfiles目錄，但可以修改，修改方法是找到HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/HTTP/Parameters注冊子鍵，在它下面添加一個名為ErrorLoggingDir的字符串值，在ErrorLoggingDir中設置保存日志文件的完整路徑。在httperr.log日志文件中可以找到的信息包括：所有的503（服務不可用）錯誤，空閑連接超時，解析URL時出現的各種錯誤，最后10個提交給失敗的應用程序池的請求。

　　IIS 6.0還擁有一種稱為二進制日志的功能，啟用這個功能后，IIS 6.0將把Web網站的所有日志信息寫入一個二進制格式的日志文件，日志文件的擴展名是.ibl。要啟用二進制日志功能，只要把配置文件的W3SVCC/CentralBinaryLoggingEnabled條目設置成ture（1）即可。對于ISP來說，這個功能應該非常有用。ISP的每臺機器上可能有1000甚至更多的Web網站，如果每個Web網站每天生成一個日志文件，日志文件的總數很快會達到一個天文數字。微軟最近發布的Log Parser 2.0工具能夠讀取二進制日志文件并生成報告，這個工具可以從http://download.microsoft.com/download/iis50/utility/2.0/nt5xp/en-us/setup.exe下載。Log Parser 2.0還能夠讀取前面介紹的httperr.log文件并生成報告。

　　從很久以前開始，IIS就允許指定本地服務器上保存日志文件的目錄了。不過，雖然IIS 5.0和IIS 4.0的IIS管理器允許在指定日志文件路徑的時候輸入一個遠程服務器的通用命名規范（UNC）的路徑，但Web服務器實際上不會把日志保存到遠程服務器。只有IIS 6.0才真正支持日志文件路徑的UNC路徑名。

　　六、網站ID

　　對于IIS服務器來說，唯一標識一個網站的不是網站的名稱，而是網站的ID數值。當我們在IIS 5.0和IIS 4.0中創建一個新的網站，Web服務器將下一個可用的數字順序號指定給網站（即，Web服務器給默認站點指定的數字是1，下一個網站是2，接下來是2、3、4，等等），這個數
字就是網站的唯一ID。如果要訪問一個網站的日志文件，首先必須知道該網站的ID，因為日志文件保存在/W3SVC/<網站的ID編號>目錄。如果Web服務器上運行著一個以上的網站，僅僅依靠日志文件的路徑名稱根本無法判斷哪一個日志目錄屬于哪一個網站。另外，無論是在編寫管理腳本時，還是在修改配置數據文件時，網站ID都是必不可少的，例如，在IIS配置數據文件中指定ADSI（活動目錄服務接口，Active Directory Service Interface）路徑時往往要指定正確的網站ID。

　　盡管如此，在IIS 5.0和IIS 4.0中，從IIS管理器無法直接找到網站的ID編號。為此，IIS 6.0的管理器在網站清單中增加了一個新的“標識符”列，該列的內容就是網站的ID編號。不過，即使IIS 6.0 Web服務器上只有二三個網站，網站的ID也可能很大，例如387660891（因此該網站的日志文件路徑是/W3SVC/387660891），不必奇怪，IIS 6.0不再按照順序指定網站的ID了――它根據網站的名字計算出網站的ID。

　　如果你編寫了一些腳本程序輔助管理，這些腳本要求使用原有的網站ID順序生成方式，可以禁用IIS 6.0新式的ID生成方式，具體的操作步驟是：找到HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/InetMgr/Parameters注冊子鍵，創建一個REG_DWORD值IncrementalSiteIDCreation，將它設置為2（注意，默認情況下，該鍵不存在）。
七、異步CGI處理

　　IIS 5.0和IIS 4.0以同步方式運行CGI（Common Gateway Interface，通用網關接口）進程，這實際上意味著每次只有一個線程能夠訪問一個CGI進程，所以IIS 5.0和IIS 4.0對CGI支持的可伸縮性不佳。IIS 6.0能夠異步運行CGI進程，所以如果一個線程調用了一個CGI應用程序，它不必再等待CGI進程處理完畢和返回信息。異步CGI改善了IIS服務器運行CGI Web應用程序的性能，使得IIS能夠運行更多執行關鍵任務的基于CGI的應用程序。

　　當Web服務器接收到包含CGI程序名和程序所需參數的URL時，CGI程序開始執行。如果將CGI程序編譯為可執行 （.exe）文件，則必須提供包含程序執行權限的目錄，以便用戶可以運行程序。如果CGI程序以腳本形式（例如Perl腳本）編寫，則既可為目錄提供執行權限，也可為其提供腳本權限。另外，如果要使用腳本權限，必須將腳本解釋程序標記為腳本引擎。

　　必須注意的是，默認情況下，IIS_WPG組不具備啟動CGI進程的權限。如果創建了新帳戶并將其添加到IIS_WPG組，還必須授予此帳戶兩種啟動CGI進程的用戶權限，即“調整進程的內存配額”和“替換進程級令牌”。

　　八、帶寬限制

　　在IIS 5.0和IIS 4.0中，Web網站屬性對話框的“性能”頁允許啟用帶寬限制功能，指定允許網站占用的最大帶寬。不過，這個功能不一定起作用，因為IIS 5.0和IIS 4.0不能直接操作服務器的網卡。

　　IIS 6.0則不同，第一次啟用帶寬限制功能時，Windows 2003自動安裝QoS數據包計劃程序供IIS服務器調用。QoS數據包計劃程序使得服務器能夠控制服務質量（即QoS），因此安裝期間Windows 2003將臨時地停止所有網絡服務。配置好QoS數據包計劃程序后，IIS才真正有了擔負起控制網站帶寬限制所需的驅動程序――對于ISP來說，這無疑是一個好消息。允許設置的最小帶寬限制值是1024 Byte/秒。不要忘了檢查一下網卡是否在Windows 2003硬件兼容清單（HCL）中，因為只有最新的網卡才支持QoS功能。

　　要配置QoS數據包計劃程序，首先必須創建一個組策略控制臺。點擊“開始”→“運行”，輸入“mmc”，然后點擊“確定”。在控制臺窗口中，選擇菜單“文件”→“添加/刪除管理單元”，點擊“添加”，在“添加獨立管理單元”對話框中，選擇“組策略對象編輯器”，然后依次點擊“添加”、“完成”、“關閉”、“確定”?，F在依次擴展控制臺中的“本
地計算機策略”、“計算機配置”、“管理模板”、“網絡”，顯示出“QoS數據包計劃程序”，如圖五所示。




　　圖五

　　啟用帶寬限制之前，請使用系統監視器檢查“網絡接口”對象中的總字節數/秒或當前帶寬計數器。如果希望比較傳入和傳出流量，請檢查發送的字節數/秒和接收的字節數/秒，再比較“網絡接口”對象的值和網絡連接的總帶寬。對于“正常”的負載，服務器使用的帶寬不應超過其全部可用帶寬的50%。如果服務器有較大的高峰負載，請將正常負載保持在50%以下，剩下的帶寬可在高峰期使用。

　　帶寬限制可以是針對全局WWW服務的（即對所有網站都有效），也可以是針對單個網站的。設置全局WWW服務最大帶寬不會替代已為服務器上的單個網站設定的最大帶寬。單個站點根據已設置的最大值來限制帶寬，而全局設置限制所有其他未限制帶寬的網站。另外，全局WWW服務帶寬限制設置不會影響FTP站點或FTP服務。

　　九、默認設置的變化

　　在IIS 6.0中，許多配置項目的默認值已經與IIS 5.0或IIS 4.0的不同。例如，默認的連接超時時間已經從900秒減少到120秒，另外，EnableParentPaths設置默認關閉。還有其他一些新的設置項目也會影響服務器的性能和行為，包括：

　?、?如果某種文件類型沒有在MimeMap配置屬性中映射，所有對該類文件的請求將被拒絕。

　?、?默認情況下，所有工作進程會在1740分鐘后自動回收，回收期間會話信息可能丟失。

　?、?運行CGI應用程序的用戶上下文必須是一個IIS_WPG組的成員。

　?、?Windows 2003不安裝Collaboration Data Objects for Windows NT Server（CDONTS）。微軟建議開發者改用CDO for Windows 2000（CDOSYS）對象。

　?、?ASP請求默認限制在204800字節之下，每一個域限制在100 KB之下。IIS 5.0和IIS 4.0沒有這方面的限制。

　　⑹ 默認情況下，http.sys僅接受標題小于16 KB的請求。

　　本文關于IIS 6.0的介紹就到這里結束，雖然文章很長，但還是不可能做到面面俱到，例如，還沒有提及受到廣泛關注的Passport驗證和摘要驗證方面的改進，本文的重點放在一些具有突破性意義的IIS 6.0新特性以及幾種較少有人提及的功能，以此證明IIS 6.0改進的廣泛性、深入性。從許多方面來看，IIS 6.0的風頭甚至蓋過了Windows 2003――而且許多人認為，IIS 6.0確實有資格占據舞臺的中央。