我
經常聽到 Microsoft 內部和外部的人將新的 IIS 7.0 Web 服務器稱為 Microsoft 在過去幾年中所進行的最重要的開發工作之一。考慮到 Microsoft 最近推出了一系列引人注意的技術,包括 Windows Vista,這個評語具有重要意義!
IIS 7.0 的發布時間正好是 Windows NT 4.0 中第一個 IIS 版本發布十周年的紀念日。2001 年,在四個版本之後,IIS 5.0 成為了 Internet 上最流行的 Web 服務器,儘管幾個月後它成了臭名昭著的 Code Red 和 Nimbda 蠕蟲的攻擊對象。IIS 6.0 是在 Windows Server 2003 中發布的,它對伺服器進行了重大改寫,將重點完全放在改進安全性、可靠性和效能上面。此後,IIS 6.0 已被證明是堅如磐石的 Web 服務器,自從發布後,它獲得了高可靠性和高安全性記錄,而且只有一條關鍵資訊安全諮詢(不是可遠程利用的)。
在本文中,我要利用這個機會向開發人員和管理員介紹下一代 IIS 7.0 Web 服務器之所以有如此大的差異的主要原因,並使您在使用它的很多新功能時有個良好的開始。
IIS 7.0 的遠景是要繼承 IIS 6.0 基本代碼的速度、可靠性和安全性,並將它演化成高度可擴充和可管理的 Web 服務器平台,具備足以運行未來 Web 應用程式的強大功能。最終成為最具前景的 Microsoft Web 服務器,並帶來在 IIS 曆史上最大程度的體繫結構改進。
IIS 7.0 的核心是一個完全模組化的 Web 服務器,它由 40 多項功能組成,這些功能可以組合成一個針對在應用程式拓撲中的所需角色經過最佳化的小型 Web 服務器。這些功能基於一個新的可擴充層,這個層允許開發人員以機器碼或者用 Microsoft .NET Framework 來擴充或替換伺服器的幾乎任何方面。IIS 7.0 在整個運行庫、管理和操作功能方面都提供了可擴充性,以協助您為特定需要構建端到端解決方案。在核心平台的基礎上,IIS 7.0 解決了與伺服器的可管理性和操作相關的很多問題。它採用全新的配置系統,能夠對網站進行完整委派的管理,並最終使 Web 應用程式的 xcopy 部署成為現實。新的管理 API 和診斷功能使伺服器的部署、管理和故障排除明顯變得比以前更容易、更方便。
但在下一個 Windows Server 版本(代號為“Longhorn”)即將最後發布之前,為什麼應當開始考慮 IIS 這個伺服器應用程式呢?現在開始考慮採用它之所以重要,是因為 Windows Vista 將附帶相同的全功能 IIS 7.0 程式,這些程式預計將在 Windows Server“Longhorn”中發布。這意味著您可以立即利用新的 IIS 7.0 功能構建您的個人網站,並將它承載在 Windows Vista 上。此外,當 Windows Server“Longhorn”發布時您將把生產 Web 應用程式以及 Web 服務器基礎結構部署到相同的 IIS 平台上,就這一點來說,您可以率先開始開發與測試它們。
有興趣嗎?讓我們深入討論細節。
模組化 Web 服務器
IIS 7.0 將 Web 服務器分成一個輕型伺服器核心,以及可以插入此核心中的 40 多個功能模組。這些模組(比如允許下載靜態 Web 內容的 StaticFileModule,或者支援整合的 NTLM 身分識別驗證的 WindowsAuthModule)可以單獨安裝在伺服器上,以提供您需要的具體功能。
可以在任何時候從伺服器上完全卸載這些模組(請參閱圖 1),或為不需要它們的特定應用程式而專門禁用它們。這將協助伺服器管理員快速地部署小型伺服器,同時大大減少受攻擊可能性,並通過只執行所需代碼極大地提高效能。
圖 1 只使用需要的功能 (單擊該映像獲得較小視圖)
圖 1 只使用需要的功能 (單擊該映像獲得較大視圖)
組件化體繫結構是 IIS 7.0 的關鍵屬性,它可以降低安全風險,並最大程度減少安裝Hotfix的必要。它還支援特殊化的伺服器部署,這樣的部署可以將選擇 IIS 功能和自訂群組件組合起來,針對應用程式拓撲中的特定伺服器角色對它們進行最佳化,例如,反向 Proxy和快取服務器、HTTP 協議Server Load Balancer器、或 SSL 和安全 sentinel 伺服器。
IIS 7.0 所附帶的所有伺服器功能都基於新的公用可擴充 API。作為開發人員,您可以用您自己的功能替換任何現有伺服器功能,也可以構建新的模組以添加到 IIS 7.0 功能集中。您是否希望用自訂的身分識別驗證模組替換內建身分識別驗證機制,或者提供新形式的響應壓縮?請繼續。
新的可擴充 API 是對以前的 ISAPI 可擴充模型的根本改進,使您能夠更靈活、更輕鬆增強伺服器。幾乎伺服器的每個方面(從核心伺服器直到配置、管理和診斷)都提供了可擴充性,使您可以根據自己的需要擴充和裁減伺服器。本文稍後將提供有關可擴充性的更多介紹。
經過簡化的部署和配置
以前的 IIS 版本所採用的集中化配置儲存(人們親切稱其為中繼資料庫)已經一去不複返了。IIS 7.0 具有新的委派配置系統,它基於分布式 XML 設定檔的階層。此階層由全域 applicationHost.config 檔案(該檔案包含伺服器層級的配置預設設定)以及應用程式的目錄結構中的分布式 web.config 檔案組成。這些檔案與 ASP.NET 應用程式架構用於以可移植方式儲存應用程式設定的 web.config 檔案是相同的檔案。因而可以使用乾淨和強大結構化的 XML 指令,並排地儲存 IIS 和 ASP.NET 配置。下面是樣本:
<?xml version="1.0" encoding="UTF-8"?><configuration><system.web><customErrors mode="Off" /></system.web><system.webServer><directoryBrowse enabled="true" /></system.webServer></configuration>
過去,必須在機器級的中繼資料庫存放庫中顯式配置 IIS 應用程式設定,然後應用程式才能正常工作。而使用分布式 web.config 檔案,應用程式則將必需的伺服器配置封裝在其目錄結構中。這就大大簡化了部署,從而可以將獨立的應用程式直接複製到目標伺服器的應用程式目錄中,從而以所需設定立即啟動和運行。
新的配置系統還為伺服器管理員提供了全面控制權,允許他們將某些配置選項委派給應用程式,同時由於安全或業務原因保持對其他選項的控制。這樣,託管伺服器上的應用程式可以在其應用程式中直接設定必需的配置,而不需要求助於伺服器管理員或使用外部配置面板。
在 IIS 7.0 中,配置系統是完全可擴充的。新模組可以添加它們自己的配置架構,從而使應用程式能夠與 IIS 和 ASP.NET 配置一起並排配置其功能:
<configuration><system.webServer><directoryBrowse enabled="true" /></system.webServer><myBandwidthThrottler enabled="true" /></configuration>
自訂配置部分使用了與 IIS 7.0 功能的配置相同的配置架構,從而利用了強大的類型屬性值、集合文法和分層重寫及鎖定語義。
IIS 7.0 繼續支援現有安裝代碼使用管理基礎對象 (ABO) API 向原有中繼資料庫寫入資料,或使用那些使用更進階別的 Active Directory 服務介面 (ADSI) 和 Windows Management Instrumentation (WMI) 對象的指令碼來配置 IIS。它通過提供類比 ABO API 的相容層來實現這樣的支援(所有其他原有配置 API 均基於該相容層),從而允許上述指令碼就像在以前版本的 IIS 中一樣讀取和更改配置。(有關中繼資料庫相容性的詳細資料,請參閱本文後面的“經過改進的效能”和“向後相容”兩節。)雖然新的結構化 XML 配置格式使您更容易在您喜歡的文字編輯器中處理配置,但 IIS 還是為管理員提供了很多管理工具和 API,以簡化伺服器管理,並支援自動設定和部署。
經過改進的管理
IIS 7.0 提供了一組豐富的管理功能,使得使用者可以在廣泛的方案中管理伺服器。新的圖形化 IIS 管理器管理工具取代了 InetMgr.exe MMC 嵌入式管理單元,藉助其基於任務的管理介面,使手動伺服器管理變得非常簡單(參見圖 2)。
圖 2 IIS 管理器提供了圖形化管理工具 (單擊該映像獲得較小視圖)
圖 2 IIS 管理器提供了圖形化管理工具 (單擊該映像獲得較大視圖)
IIS 管理器允許您管理大多數 IIS 7.0 功能,並監視伺服器的操作。該工具支援通過防火牆友好的 HTTP/SSL 串連進行遠端管理,並且可以選擇同時支援用於身分識別驗證的基於 Windows 的憑據和其他憑據。
此外,該工具支援委派管理,從而讓應用程式所有者能夠遠端管理其應用程式,而不必對伺服器電腦具有管理訪問權。藉助此功能,託管服務的使用者可以在其家用案頭機上運行管理工具,並遠端連線以管理其在託管伺服器上的應用程式。當然,伺服器管理員對可以將哪些管理功能委派給應用程式所有者擁有完全控制權。
最後,該管理工具是完全可擴充的,它基於配置系統可擴充性,允許將自訂管理 UI 添加到工具中。在 iis.net/default.aspx?tabid=7&subtabid=73 中可以詳細瞭解 IIS 管理器工具以及如何添加自己的管理外掛程式。
為了獲得更靈活的命令列管理,IIS 7.0 提供了 appcmd.exe 命令列工具(參見圖 3)。此工具提供了一組全面的管理功能和比 UI 更好的大量操作支援。通過這個功能強大的公用程式,可以輕鬆從命令提示字元讀取和寫入配置、訪問網站和應用程式集區狀態資訊以及執行幾乎任何其他管理工作。
圖 3 IIS 7.0 的 Appcmd.exe 命令列管理 (單擊該映像獲得較小視圖)
圖 3 IIS 7.0 的 Appcmd.exe 命令列管理 (單擊該映像獲得較大視圖)
利用 appcmd.exe,可以建立和配置網站、應用程式、應用程式集區和虛擬目錄。通過它,可以啟動和停止網站、回收應用程式集區、列出正在啟動並執行背景工作處理序、檢查當前正在執行的請求以及搜尋失敗事件請求緩衝 (FREB) 追蹤記錄檔。還可以搜尋、編輯、匯出和匯入 IIS 及 ASP.NET 配置資料。
該工具旨在使您可以靈活搜尋受支援的伺服器對象,例如,使您能夠快速找到有特定設定集的網站,或已停止的應用程式集區。執行搜尋時,可以對任何對象的屬性使用任意數量的條件,包括使用數字範圍和簡單萬用字元字串匹配。
Appcmd 還支援類似 Windows PowerShell中出現的連結操作,從而允許從單個命令列一起執行針對一組相關對象的多個操作。例如,您可以用一條命令尋找和回收承載某個網站的應用程式的所有應用程式集區。若要瞭解如何用 AppCmd 管理 IIS,請參閱 iis.net/default.aspx?tabid=2&subtabid=25&i=954&p=1。
.NET Framework 和指令碼
除了用 IIS 管理器或 appcmd.exe 命令列工具進行手動伺服器管理以外,IIS 7.0 還為編程管理提供了豐富的選項。首先,可以利用 Microsoft.Web.Administration API 通過 .NET 應用程式管理伺服器。也可以使用新的 COM API 直接管理 IIS 配置系統,或從諸如 ASP 或 Windows Script Host (WSH) 這樣的指令碼環境訪問它。還有新的 WMI 提供者,以及通過中繼資料庫相容層實現的對原有 WMI 和 ADSI 提供者的支援。
Microsoft.Web.Administration 是新的 .NET 管理 API,它使Managed 程式碼應用程式可以輕鬆地以編程方式設定 IIS 網站和應用程式、訪問重要狀態和診斷資訊以及按其他方式設定管理員。通過讓基於 .NET Framework 的應用程式輕鬆訪問 IIS 配置及狀態資訊,為編寫基於 .NET 的安裝和管理應用程式,甚至是直接從 ASP.NET 頁執行管理工作,提供了可能。
作為樣本,圖 4 顯示了一個小型 C# 程式,該程式使用 Microsoft.Web.Administration 從命令列建立網站。
Microsoft.Web.Administration 使 IIS 操作和配置任務能夠直接在您選擇的支援 .NET 語言的應用程式內部輕鬆完成。它還使您可以輕鬆訪問有關伺服器的運行庫狀態資訊,例如,正在啟動並執行背景工作處理序或當前正在執行的請求。
Microsoft.Web.Administration API 是訪問自訂 .NET 伺服器模組內部的自訂配置和 IIS 管理器工具的 UI 外掛程式的基礎。有關端到端伺服器包的樣本,包括用於增強 Web 服務器和相關配置及管理組件的映像著作權處理常式,請參閱 iis.net/default.aspx?tabid=2&subtabid=25&i=1076。
在 Windows Server“Longhorn”時間範圍內,IIS 團隊將為添加自訂管理對象或擴充現有管理對象而建立統一的可擴充模型,這些模型將使自訂管理功能通過不同管理功能(包括指令碼和 Microsoft.Web.Administration API)自動公開。當您無法添加或擴充 Windows Vista 中的管理對象時,可以使用 Microsoft.Web.Administration 和其他 API,就像現有 IIS 配置部分一樣,訪問和管理自訂配置部分。
構建 Web 服務器功能
IIS 7.0 使您能夠根據您的需要塑造伺服器,允許您添加或替換伺服器中的任何功能,以便提供您需要的功能。此功能的核心是全新的 Web 服務器可擴充 API,所有現有 IIS 7.0 HTTP 功能都建立在它之上。此 API 是公用的,這意味著您可以實現 IIS 7.0 附帶的任何功能。這對 IIS 是第一次,並且是對以前的有限 ISAPI 可擴充模型的根本改進。
新的可擴充 API 是一組直觀的 C++ 類,這些類定義了 Web 服務器物件模型,並使一個模組能夠在 IIS 上提供請求處理服務。這些類被定義在 Windows Vista SDK 中的 \inc\httpserv.h 標頭檔中。
與 ISAPI 比較,這些 API 功能更強大,而且易用性得到了極大增強。這是如何?的?首先,新的 API 具有型別安全、良好封裝的物件模型。用新的伺服器物件模型可以更輕鬆地進行開發,該模型為所有基本伺服器對象和任務提供了專門的介面。包括:
- 用 IHttpRequest 類檢查請求
- 用 IHttpResponse 類管理響應
- 從 IHttpServer 類使用有用的公用程式功能
- 用 IHttpUser 類提供身分識別驗證
- 用配置 API 訪問您的模組的自訂配置部分
這些類公開了比以前更多的伺服器功能(超過了構建 IIS 附帶的所有特性所需的功能),但仍然比鬆散的類型化 ISAPI 介面更容易使用。
開發人員還將受益於經過改進的記憶體和狀態管理員模式。大多數 IIS 7.0 伺服器 API 都使用伺服器託管記憶體來儲存它們返回的資料,而不是像 ISAPI 和大多數現有 Win32 API 那樣需要您分配和管理緩衝區。過去,這一直是 ISAPI 開發中最容易產生錯誤也是最令人厭煩的方面。新的 API 還簡化了很多複雜的請求處理任務,例如,響應緩衝、身分識別驗證和為用戶端準備響應資料。幾個月以前,我開始發表我的一系列部落格文章,以解釋新編程模型中的重大改進和模式。如果您正在考慮針對 IIS 的 C++ 開發,可通過訪問以下網址參考相關內容:mvolo.com/blogs/serverside/archive/2006/10/07/10-reasons-why-server-development-is-better-with-IIS7.aspx。
IIS 7.0 還為擴充伺服器提供了完全整合的 .NET Framework API。此外,這與自從 Windows 2000 上的 ASP.NET 1.0 發布以來 ASP.NET 提供的用於構建 ASP.NET 模組和處理常式的 API 是相同的。但兩者有區別,人們熟悉的 ASP.NET 模型允許現有 ASP.NET 模組和處理常式繼續工作在 IIS 7.0 伺服器上,但實際上它已完全不同於以前的舊技術。
在 IIS 7.0 中,ASP.NET 有兩個版本:傳統模式和整合模式。傳統模式的工作方式與它在以前版本的 IIS 中完全相同。整合模式是新的平台預設設定,它使用全新的引擎來提供與 IIS Web 服務器前所未有的整合。在整合模式下,可以用 ASP.NET API 開發 IIS 7.0 模組,這樣的模組可以直接與 Web 服務器整合,並且能夠提供用基本 C++ API 即可實現的幾乎所有服務。
這基本上是兩個方面的最佳結合:像成員資格和角色管理這樣的 .NET Framework 和 ASP.NET 2.0 應用程式服務所具有的熟悉的介面和方便性,以及以前只對基於 C 的 ISAPI 組件可用的擴充伺服器的原始能力。
除了能夠編寫新的 ASP.NET 模組(建立在整合模式的特定優勢之上)之外,只需通過在 web.config 檔案中更改少量配置選項,就可以使很多原有 ASP.NET 模組變得更為強大。
ASP.NET 整合
使用 IIS 7.0,ASP.NET 2.0 不止是建立Live App程式的優秀架構。它還成為擴充 IIS Web 服務器的平台,這使得 ASP.NET 組件成為 IIS 請求處理管道的完整成員。下面介紹它的工作原理。
在直到 6.0 版的 IIS 版本中,ASP.NET 均作為獨立的應用程式架構串連到 Web 服務器。它負責處理向它註冊的請求擴充(通常是 .aspx 和少量其他副檔名),並且它還為這些請求提供強大的功能,如表單身分識別驗證、響應輸出緩衝以及其他功能,包括由自訂 ASP.NET 模組提供的服務。因此,只有向 ASP.NET 註冊的內容類型才能受益於這些服務。包括 ASP 頁、PHP 頁、映像和 CGI 應用程式在內的其他類型則無法受益。此外,由於運行庫限制,即使對於 ASP.NET 資源,也無法在 ASP.NET 中實現某些 Web 服務器功能。例如,它不能檢查傳出 HTTP 響應標題集並在發送到用戶端之前修改它們。
當 ASP.NET 模組在 IIS 7.0 中以整合模式運行時,將與本機 C++ IIS 模組並排運行在統一請求處理管道中(參見圖 5)。這意味著現有 ASP.NET 服務(如輸出緩衝、URL 重寫和由自訂 ASP.NET 模組提供的任何其他服務)現在可以應用於任何內容類型。更好的運行庫整合還使 ASP.NET 模組能夠訪問以前停用伺服器功能,這樣,在大多數情況下,不再需要編寫本機 IIS 可擴充功能。
圖 5 在 IIS 6.0 和 IIS 7.0 中與 ASP.NET 整合 (單擊該映像獲得較小視圖)
圖 5 在 IIS 6.0 和 IIS 7.0 中與 ASP.NET 整合 (單擊該映像獲得較大視圖)
最後,在整合模式中,ASP.NET 提供了少量新 API,用於公開由於與 IIS 緊密整合而可用的其他功能。其中包括檢查所有響應標題(不管是誰產生了響應)的能力,以及將請求執行操作完全重寫到另一個 URL 的能力。
通常,現有應用程式可以利用整合模式,而不需要使用特定於整合模式的功能的新 ASP.NET 模組。只需通過更改配置,應用程式就可以執行諸如以下操作:使用 ASP.NET 表單身分識別驗證和 URL 授權通過使用者安全機制保護整個網站,或使用 ASP.NET URL 對應在應用程式中重寫 URL 等。如需查看利用整合模式阻止 Web Leech 熱連結到網站映像的樣本,請參閱實現這一點的樣本 ASP.NET 模組:mvolo.com/2006/11/10/stopping-hotlinking-with-iis-and-aspnet.aspx。該樣本很好地說明了如何通過在整合模式中使用現有第三方 ASP.NET 模組來更好地利用它們。
如需查看利用現有應用程式的整合模式的詳細步驟,請參閱我的文章:iis.net/default.aspx?tabid=2&subtabid=25&i=1081&p=1。
經過改進的安全性
IIS 7.0 建立在 IIS 6.0 基本代碼之上,由于謹慎的編碼實踐和預設安全的設計原則,這些代碼擁有已被證明的安全追蹤記錄。在此之上,IIS 7.0 引入了幾處體繫結構更改,以提供更強大的安全性,還引入了大量功能,以協助您建立安全的 Web 應用程式。
減少受攻擊的可能性是設計和部署安全系統的基本原則之一。通過將 IIS 6.0 的預設鎖定方法發展到下一層級,在預設情況下 IIS 7.0 安裝的功能更少,從而可以鎖定伺服器的更多項。通過進一步利用伺服器的模組化性質來刪除所有沒用的功能,可以將伺服器的受攻擊可能性降到最低,從而極大地降低伺服器被攻擊的風險。
如果在伺服器上的任何不用組件中發現了漏洞,不需要為了防止遭到攻擊或修補漏洞組件,立即讓伺服器停止工作。這樣可以提高應用程式的可用性,並降低Hotfix的管理成本。
除了核心安全性改進以外,IIS 7.0 還提供了大量安全功能,通過使用它們,可以進一步在伺服器上鎖定和部署安全應用程式。IIS 一直在為通過身分識別驗證保護應用程式內容提供強大支援。現在,利用 ASP.NET 整合模式,您可以使用流行的 ASP.NET 安全功能(例如,表單身分識別驗證、成員資格和登入控制)來為整個應用程式提供完整的身分識別驗證和存取控制解決方案。通常,可以在幾分鐘內完成此設定,而不必編寫任何代碼。
新的 URL 授權功能從 ASP.NET URL 授權功能發展而來,可以用於為整個應用程式配置聲明性存取控制規則。利用這些訪問規則可以根據使用者名稱和角色允許或拒絕對應用程式中對 URL 的訪問。URL 授權與 ASP.NET 2.0 成員資格和角色管理功能無縫整合在一起,可以有效地與 ASP.NET 表單身分識別驗證和登入控制一起使用,以快速啟用應用程式的使用者安全機制。
新的要求篩選功能提供了功能強大的鎖定功能,該功能的一部分可在流行的 URLScan 工具中獲得。通過拒絕包含可疑資料的請求、保護敏感資源或強制執行進攻性要求節流,可以用要求篩選功能進一步鎖定網站。
IIS 7.0 還進行了大量更改,旨在使安全設定的部署和管理更輕鬆。新的 IIS_IUSR 匿名帳戶是內建的,這意味著它不受密碼到期的影響,而且不需要在電腦之間進行密碼同步化。新的 IIS_IUSRS 組取代了 IIS_WPG 組,在運行時自動注入背景工作處理序的標識中,從而緩解了在使用自訂帳戶時向該組手動添加背景工作處理序標識的需要。
由於有了內建的 IIS_USR 帳戶和 IIS_USRS 組,用於為匿名 IIS 帳戶和組指定存取控制清單 (ACL) 的應用程式內容就可以從一個 IIS 伺服器直接被複製到另一個 IIS 伺服器,而不需要執行任何額外的步驟來保留安全設定。這就極大地簡化了跨開發-測試-生產周期的應用程式部署過程。
前面討論的分布式配置系統允許應用程式所有者直接在其應用程式內管理所需的 Web 服務器設定,而不必具備對伺服器的管理員權限。應用程式系統管理員可以在將其應用程式上傳到伺服器時,可以在其應用程式內容內部在 web.config 檔案中指定必需的配置,或使用 IIS 管理器工具遠程配置其應用程式。
IIS 管理器工具通過防火牆友好的 HTTPS 串連提供安全遠端管理功能。由於管理工具能夠通過成員資格服務來驗證應用程式系統管理員的身份(或者是 Windows 使用者,或者是自訂使用者帳戶),因此管理工具允許進行遠程應用程式管理,而不需要所有者對伺服器有任何 Windows 許可權。
作為伺服器管理員,通過配置系統中的靈活的鎖定支援,您對應用程式可以配置哪些設定擁有完全控制權。同樣,對於遠端管理其應用程式的應用程式系統管理員可以使用哪些 IIS 管理器工具功能,您也可以進行控制。
經過改進的診斷
在 Windows、IIS 7.0 和 Web 應用程式所支援的所有新功能中,Web 服務器是通常需要投入大量精力進行故障排除的非常複雜的系統。IIS 7.0 引入了大量新功能,可協助您監視伺服器的運行情況並調試應用程式的問題。
首先,IIS 7.0 允許您深入查看伺服器的即時狀態。此功能稱為運行庫狀態和控制 API,或 RSCA(讀作“reeska”),它可以公開網站和應用程式集區的活動狀態、運行中的背景工作處理序,甚至允許您查看當前正在伺服器上執行的請求。它還使您能夠控制伺服器的狀態,例如,啟動和停止網站,或回收應用程式集區。在 Windows Vista 中,可以在 IIS 管理器中、通過 appcmd.exe 命令列工具或使用 Microsoft.Web.Administration API 以編程方式訪問此資訊。
例如,可以查看當前正在執行的請求以及它們所處的伺服器階段。這可以讓您快速解決掛起的請求問題,並跟蹤是哪些指令碼正在耗費 CPU(參見圖 6)。
在調查伺服器問題或調整伺服器效能時,RSCA 功能非常便於使用,通過它既能快速看到系統中發生的情況,還能在執行故障排除時控制伺服器。在辦公室調查 Bug 時,我通常選擇使用 appcmd.exe 來查看應用程式集區的狀態、檢查背景工作處理序、啟動或停止有危害的應用程式集區,以便找到問題所在。
圖 6 在 IIS 管理器中跟蹤阻塞的指令碼 (單擊該映像獲得較小視圖)
圖 6 在 IIS 管理器中跟蹤阻塞的指令碼 (單擊該映像獲得較大視圖)
Web 應用程式中發生錯誤時,可能是由於不正確的伺服器配置、應用程式錯誤或各種環境因素導致的。狀態碼和標準錯誤訊息所提供的錯誤線索很少,它們可能使伺服器故障排除成為噩夢。IIS 7.0 提供了有關大多數錯誤的詳細的錯誤資訊,使您可以準確知道錯誤的根源、原因以及如何修複(參見圖 7)。
圖 7 錯誤詳細資料指出問題和解決方案 (單擊該映像獲得較小視圖)
圖 7 錯誤詳細資料指出問題和解決方案 (單擊該映像獲得較大視圖)
詳細的錯誤遵從類似於 ASP.NET 詳細錯誤的安全方案。預設情況下,您只有在從本機電腦瀏覽網站時才能獲得詳細資料。像以前一樣,還可以為不同的錯誤碼配置自訂錯誤頁,或重新導向到自訂 URL。詳細的錯誤頁現在也已本地化,如果安裝了相應語言的語言套件,就可以按用戶端的慣用語言提供錯誤描述。
診斷錯誤而無需調試
如果您遇到的錯誤情況是未知的,或者是由多個 Web 服務器組件的複雜疊加而導致的,則會怎麼樣?不用擔心,IIS 7.0 提供了全面的跟蹤機制,它可以為每個請求產生詳細的書面追蹤記錄,以便能夠快速跟蹤問題。
Windows Server 2003 Service Pack 1 (SP1) 中向 IIS 6.0 中添加了 Windows 事件跟蹤 (ETW) 事件,在此事件的基礎上,IIS 7.0 添加了更多資訊性事件。這些事件包含有關伺服器處理的每個階段的有用資訊,通過檢查這些資訊可以反向跟蹤請求執行過程,查明出錯位置。可以將這些事件路由到 Windows 跟蹤基礎結構,後者允許多個 Windows 組件(包括 ASP.NET 和 SQL Server)將其跟蹤資訊連結到該請求的單個邏輯執行跟蹤。
還可以將它們路由到新的失敗請求跟蹤功能(又稱為 FREB),後者會將追蹤記錄檔儲存到 XML 記錄檔中,然後可以用提供的 XSLT 樣式表查看這些檔案(參見圖 8),或以編程方式使用它們。
圖 8 查看 XML 記錄檔 (單擊該映像獲得較小視圖)
圖 8 查看 XML 記錄檔 (單擊該映像獲得較大視圖)
關於失敗請求跟蹤功能最酷的一點是您可以使它始終在伺服器上保持啟用狀態。通過它可以自動捕獲那些遇到可配置的故障狀況的請求的追蹤記錄檔,同時避免因儲存已成功完成的請求的追蹤記錄檔而導致效能降低。例如,對於導致伺服器錯誤或完成時間超過特定時間的請求,可以將它開啟。
使用失敗請求跟蹤,可以在錯誤發生時始終捕獲有價值的跟蹤資訊,即使它們是間歇性的,或難以複現的。這可以協助診斷和解決以前需要艱難調試的困難問題。
基本跟蹤基礎結構通過伺服器可擴充模型向 IIS 模組公開,從而允許所有伺服器組件(無論它們是 IIS 附帶的,還是第三方開發的)在請求處理期間發出詳細跟蹤資訊。通過 System.Diagnostics API 和 ASP.NET 頁跟蹤,IIS 7.0 跟蹤功能與 ASP.NET 跟蹤功能整合在一起,從而允許託管模組利用整合追蹤模式。若要更進一步,可以編寫自己的跟蹤模組,為處理和輸出跟蹤資訊提供新的方式。例如,您可以成為編寫模組以便將 IIS 跟蹤資訊儲存到 SQL Server 或文字檔中的第一個人。
經過改進的效能
雖然 Windows Vista 是用戶端作業系統,並不針對高輸送量的生產部署(Windows Vista 上的 IIS 受限於每次 10 個並發請求),但它的確體現了一些旨在大幅提高 Web 應用程式效能的重要體繫結構改進。通過與我們正在 Windows Server“Longhorn”時間範圍內所進行的廣泛的效能改進工作相結合,這些改進將協助 IIS 7.0 提高伺服器效能。
當然,第一項改進是組件化。伺服器的模組化性質允許管理員刪除不需要的伺服器功能,從而在請求處理期間節省記憶體和 CPU 使用量。這會導致電腦的輸送量和容量得到重大改進。在只有網站的某些部分需要特定功能的情況下,以粒度方式啟用功能的能力(針對伺服器上的每個應用程式開啟和關閉相應功能)將進一步提高應用程式的效能。
在 IIS 7.0 中,另一個值得注意的效能特性是新的 IIS 輸出緩衝。此特性為在伺服器上重複利用對高成本動態網頁面的響應提供了支援,從而緩解了對執行高成本的顯示處理和資料庫事務以便將響應返回用戶端的需要。IIS 輸出緩衝是對 ASP.NET 中現有的豐富輸出緩衝功能的速度更快的替代方案,它可以支援一組更小的緩衝功能,但能以增強效能的方式為緩衝動態內容提供足夠的靈活性。
通過將動態內容進行輸出緩衝,無論它是 ASP.NET 頁、PHP 指令碼還是 CGI 應用程式,您都可以獲得 5-10 倍的效能提升,同時大大降低對磁碟和資料庫的負載。
向後相容
IIS 7.0 應當能夠運行大多數現有應用程式,而不需要修改。考慮到在此版本中支援創新所需要的體繫結構的更改範圍,這是一項巨大成功。配置系統已經過最大更改,從集中的鬆散類型化配置儲存轉變為委派的 XML 設定檔階層。配置資訊的結構和儲存都完全不同於 IIS 6.0 中繼資料庫,並且不支援通過原有配置 API 進行訪問。
IIS 7.0 通過提供中繼資料庫的模擬層來解決此問題,模擬層在配置系統的基本資料與中繼資料庫 ABO API 所公開的介面之間執行即時轉換。這就使得在通過 ABO 或更進階別的 WMI 或 ADSI 指令碼訪問為該中繼資料庫編寫的代碼時,代碼能夠正確工作。但是,務必安裝相容性安裝組件才能獲得此功能。
雖然 IIS 7.0 為開發 IIS 組件提供了新的可擴充模型,但它仍然支援 ISAPI 組件。如果安裝 ISAPI 擴充和 ISAPI 篩選器安裝組件,就能夠像以前那樣運行您的擴充和篩選器。但是,如果正在開發新組件,則應當確保使用新的可擴充模型,以獲得更強大和經過改進的開發體驗。
與整合模式存在運行庫不相容情況的少數 ASP.NET 應用程式可能必須移動到運行於傳統模式的應用程式集區中。在這種情況下,通過將多個應用程式放在單獨的應用程式集區中,可以在相同伺服器上以兩種模式並排運行這些應用程式。如需 IIS 7.0 上的 ASP.NET 重大更改和常規 ASP.NET 相容性資訊的完整列表,請參閱 ASP.NET 相容性白皮書:iis.net/default.aspx?tabid=2&subtabid=25&i=1223。
總結
在 Windows Vista 中發布的 IIS 7.0 旨在為下一代 Web 應用程式平台提供最佳體繫結構基礎,其重點是用於 Web 服務器的正確核心體繫結構、可擴充性和管理平台。Windows Vista 使您能夠在 Windows Vista 伺服器版本發布時用於部署應用程式的相同伺服器平台上開發與測試這些應用程式。
由於 IIS 7.0 是在 Windows Vista 中發布的,因此 Web 平台和工具團隊的工作重點轉移到使 Web 服務器為生產環境做好準備以及為生產方案提高穩定和效能這些方面。但是,Windows Vista 中附帶的核心開發和管理功能將保持不變,而且,當 IIS 7.0 的伺服器版本完成時,預計將通過 Service Pack 將其改進提供給 Windows Vista。那時,您的用戶端和伺服器電腦將再次運行完全相同的 IIS 版本,這樣,您就可以繼續在運行 Windows Vista 的案頭機上開發與測試 Web 應用程式了。
若要對 IIS 7.0 建立初步認識,請參閱 Web 上提供的大量非常有用的資源,首先是 iis.net 網站,它是 IIS 團隊的新首頁。我們的新網站是包含所有 IIS 7.0 相關資訊的門戶,其中包括所有 IIS 7.0 功能的詳細文章和使用步驟。請確保使用論壇提問並與 IIS 團隊及 IIS 社區一起討論問題。
還可以在我的部落格 www.mvolo.com 上尋找 IIS 7.0 的深入介紹和內部資訊。請務必來訪,好讓我知道您喜歡的 IIS 7.0 主題,而且我將在我的部落格中儘力討論它們。
http://msdn.microsoft.com/msdnmag/issues/07/03/IIS7/default.aspx?loc=zh