二、支持服務(wù)

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

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

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


　　三、全新的內(nèi)核

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

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

　　■ W3SVC

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

　　■ http.sys

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

　　在Win 2K和NT 4.0中，IIS在用戶模式下運行。運行在用戶模式下的應(yīng)用程序不直接與硬件通信，它們直接調(diào)用的是一些標(biāo)準(zhǔn)過程，這些標(biāo)準(zhǔn)過程或者將數(shù)據(jù)傳入內(nèi)核模式的組件（例如網(wǎng)卡驅(qū)動程序，圖形子系統(tǒng)），或者調(diào)用內(nèi)核模式組件的函數(shù)，以此完成保存文件、設(shè)置IP地址、將HTML文件發(fā)送到網(wǎng)絡(luò)之類的任務(wù)。

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

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

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

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

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

　　另外，微軟在http.sys驅(qū)動程序中采用了許多優(yōu)化的算法，使其能夠?qū)⒄埱笾苯愚D(zhuǎn)發(fā)到適當(dāng)?shù)墓ぷ鬟M(jìn)程。在IIS 4.0和IIS 5.0中，必須通過多個步驟才能確定進(jìn)程的哪一個實例擁有了應(yīng)當(dāng)接收當(dāng)前請求的Web應(yīng)用，但在IIS 6.0中，http.sys注冊了所有IIS 6.0應(yīng)用，賦予每一個進(jìn)程一個句柄，IIS內(nèi)部利用這些句柄來標(biāo)識注冊的應(yīng)用程序要用到的一個或多個名稱空間。因此，當(dāng)http.sys接收到一個HTTP請求，它能夠很快地將請求從內(nèi)核模式的http.sys傳遞到正確的用戶模式的Web應(yīng)用。

　　http.sys驅(qū)動程序還要執(zhí)行其他一些任務(wù)，其中包括：

　?、?將傳入的URL與各種長度、格式方面的規(guī)則進(jìn)行比較。

　?、?管理傳入請求的隊列。

　　⑶ 擔(dān)負(fù)著記錄IIS Web網(wǎng)站日志信息的任務(wù)（從而提高了記錄日志的性能）。

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

　?、?實現(xiàn)客戶證書請求服務(wù)（但不支持安全套接字層——SSL）。

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

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

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

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

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

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

　　■ W3Core

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

　　圖五


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

　　圖六

　　如果緩沖區(qū)溢出攻擊成功入侵了一個Web應(yīng)用，攻擊者只能訪問當(dāng)時運行工作進(jìn)程的帳戶有權(quán)訪問的資源，默認(rèn)的網(wǎng)絡(luò)服務(wù)帳戶不能寫入Inetpub文件夾，執(zhí)行權(quán)限也極其有限，所以象CodeRed蠕蟲之類的攻擊根本不可能得逞。

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

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

　　圖七

　　四、應(yīng)用程序池詳解

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

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

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

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

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

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

　　圖八

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

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

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

　　一、安全

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

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


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

　　圖一

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

　　另一個安全方面的改進(jìn)之處是IIS 6.0允許指派一個加密服務(wù)提供者（Cryptographic Service Provider，CSP），能夠?qū)⒒谟布陌踩捉幼謱樱⊿SL）加速器集成到IIS 6.0，從而把加密任務(wù)從服務(wù)器的通用CPU轉(zhuǎn)移到了專門為加密操作而優(yōu)化的專用設(shè)備，有利于提高性能和可靠性。