關于IIS 6.0的故事一言難盡，如果你已經在IIS技術上有所投資，IIS 6.0無疑是一個動人的、非聽不可的話題。鑒于IIS 6.0和以前版本的差別實在太大了，只用一篇文章很難做到面面俱到，所以本文首先探討IIS 6.0的安裝、體系結構以及由于體系結構方面的差異帶 來的全新服務功能，下一篇文章接著介紹IIS 6.0的新特性——其中有些你可能還沒有聽說過，另外還有默認配置方面的一些重要變化，這些變化可能會影響到你的遷移計劃。

　　一、安裝IIS 6.0

　　首先從最基本的說起吧。IIS 6.0包含在Windows Server 2003服務器的四種版本之中：數據中心版，企業(yè)版，標準版，Web版。另外，順便再回答一個最常見的IIS 6.0問題：IIS 6.0不能在Windows XP、2000或NT上運行。

　　安裝好Windows 2003之后，馬上就可以看到Windows 2003/IIS 6.0的與眾不同之處，其中一個關鍵的變化是，除了Windows 2003 Web版之外，Windows 2003的其余版本默認不再安裝IIS。按照微軟過去的理念，安裝操作系統(tǒng)的同時IIS也自動啟動，為許多Web應用提供服務，Windows 2003的做法可謂一大突破。在Windows 2003中，安裝IIS有三種途徑：利用“管理您的服務器”向導，利用控制面板“添加或刪除程序”的“添加/刪除Windows組件”功能，或者執(zhí)行無人值守安裝。

　　第一次啟動Windows 2003系統(tǒng)時，“管理您的服務器”向導自動啟動，如圖一所示。


screen.width*0.5) {this.resized=true; this.width=screen.width*0.5;}" border=0>
　　圖一

　　選擇“添加或刪除”角色，在“配置服務器”向導中可以看到一系列可配置的服務器角色，其中就有“應用程序服務器（IIS，ASP.NET）”選項，如圖二，選中該選項之后點擊“下一步”，向導提供了是否安裝ASP.NET和Microsoft FrontPage服務器擴展的選項。可以看到，微軟在這里采用了一種新型的“安裝任何部件之前總是
征求用戶意見”的IIS安裝策略，對于微軟來說，這是一個徹底的轉變，證明微軟確實在認真對待安全問題。


screen.width*0.5) {this.resized=true; this.width=screen.width*0.5;}" border=0>
　　　圖二
　　使用控制面板中的“添加/刪除Windows組件”功能還要靈活一些。在向導中選擇“應用程序服務器”，再點擊“詳細信息”，向導顯示出一系列組件的清單，其中就有“Internet信息服務（IIS）”選項，還有一些選項是以前的“添加/刪除Windows組件”向導沒有提供的，表一概括比較了IIS 6.0和IIS 5.0 的主要組件。如果從這里安裝IIS 6.0，最后得到的Web服務器可能只支持靜態(tài)內容（除非在安裝期間選中了某些擴展組件）。選中Internet信息服務選項，再點擊“詳細信息”，可以看到IIS 6.0的子組件，如圖三所示。



screen.width*0.5) {this.resized=true; this.width=screen.width*0.5;}" border=0>

　　圖三

　也許你已經注意到了表一列出的某些新增組件選項，但你注意到IIS 6.0少了什么嗎？IIS 6.0中消失不見的最主要的一個項目是文檔。在IIS 6.0中，所有文檔都以幫助文件的形式發(fā)布，不再有IISHelp虛擬目錄。在IIS 5.0中，如果從本地訪問服務器，默認Web網站自動打開IIS的文檔，但在IIS 6.0中，如果打開“
http://localhost”，只能看到一個聲明網站正在構建之中的頁面。

　　另外，在IIS 5.0的IISHelp虛擬目錄中有一些錯誤處理頁面，這些錯誤處理頁面以ASP的方式實現。如果你要用到定制的（或者修改過的）幫助文件、錯誤處理頁面，在IIS 6.0網站上必須自己創(chuàng)建該目錄。

　　進一步分析IIS 6.0的子組件清單，可以發(fā)現：原來在IIS 5.0和IIS 4.0中默認安裝的Internet服務管理器（ISM）已經不見了。但是，如果你點擊“萬維網服務”（IIS 6.0的子組件之一，但圖三沒有顯示出來），再點擊“詳細信息”，可以發(fā)現IIS 6.0的萬維網服務還有子組件，如圖四所示，其中包括原來的Internet服務器管理器，不過現在已經改名為“遠程管理（HTML）”；還有Windows 2003和XP版本的終端服務高級客戶端（TSAC）——現在它叫做“遠程桌面Web連接”。現在，我們不僅可以方便地添加或刪除這兩個子組件，對其他子組件也一樣，包括：ASP，Internet數據連接器，在服務器端的包含文件，WebDAV發(fā)布，當然還有萬維網服務。


screen.width*0.5) {this.resized=true; this.width=screen.width*0.5;}" border=0>　

　　圖四

　　安裝IIS 6.0的最后一種方式是無人值守安裝。和以前一樣，這仍舊是唯一一種能夠將工具和默認Web網站安裝到其他驅動器（而不是系統(tǒng)驅動器）的安裝方式。Windows 2003無人值守安裝方式大體上仍和Win 2K一樣，都是用Sysocmgr和一個應答文件實施安裝。當然，新的特性需要新的參數、選項，有關這方面的詳細說明，可以在Windows 2003 Release Candidate 2 （RC2）找到，地址是：http://www.microsoft.com/technet ... s_installingiis.asp。

　　如果將IIS 5.0或IIS 4.0服務器升級到Windows 2003，IIS 6.0不會被設置成自動啟動。也就是說，如果采用升級的方式安裝，IIS 6.0默認是禁用的，除非遇到下列情況之一：

　　⑴ 以前的IIS服務器上已經安裝了IIS Lockdown工具。

　　⑵ 存在注冊子鍵
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW3SVCRetainW3SVCStatus，且它包含一個任意的注冊鍵。例如，你可以創(chuàng)建一個名為EnableIIS6的鍵，設定它的值為DWORD類型的1。

　　⑶ 在無人值守的升級安裝中，應答文件的[InternetServer]部分存在DisableWebServiceOnUpgrade = True/False條目。


　　二、支持服務

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

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

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

　　從體系結構上看，IIS 5.0和IIS 4.0其實是一樣的：它們都是在用戶模式下運行的發(fā)布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將監(jiān)聽請求、創(chuàng)建和監(jiān)視Web網站、運行Web服務這些不同的任務隔離了開來，這一新型體系可望解決IIS 5.0存在的問題。從理論上看，新的體系將極大地改善可用性、安全和性能；從實際情況看，根據微軟和Beta測試者的報告，新的體系令穩(wěn)定性和性能有了奇跡般地提高。IIS 6.0的內核體系主要建立在三個組件之上：W3SVC，http.sys，以及W3Core。

　　■ W3SVC

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

　　■ http.sys

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

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

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

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

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

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

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

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

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

　　⑵ 管理傳入請求的隊列。

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

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

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

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

　　⑴ 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、雙字節(jié)字符集（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的規(guī)則。在天生具有國際化特點的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。


screen.width*0.5) {this.resized=true; this.width=screen.width*0.5;}" border=0 resized="true">
　　圖五


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


screen.width*0.5) {this.resized=true; this.width=screen.width*0.5;}" border=0>
　　圖六

　　如果緩沖區(qū)溢出攻擊成功入侵了一個Web應用，攻擊者只能訪問當時運行工作進程的帳戶有權訪問的資源，默認的網絡服務帳戶不能寫入Inetpub文件夾，執(zhí)行權限也極其有限，所以象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網站或目錄放入應用程序池。


screen.width*0.5) {this.resized=true; this.width=screen.width*0.5;}" border=0>
　　圖七