關于IIS7.0（Internet Information Services）的特性和配置

IIS 7.0的特性

        IIS 7.0是在IIS 6.0 基礎上重新開發的，開發IIS 7.0的目的在于為使用者提供一種能夠與作業系統高度內建的 Web 應用程式平台。IIS 7.0 能夠與ASP.NET 架構高度內建，并且提供了完整的 API，進而可以為平台提供完整的可擴充能力和管理接口，是以，IIS 7.0使得程式員的夢想成為現實。另外，IIS 7.0 還提供了配置委托和完整的診斷套件，診斷套件可以對需求進行跟蹤，還提供了進階日志功能，這些都滿足了管理者的要求

        IIS 7.0将 ASP.NET 與請求管道進行了內建，這也許是IIS 7.0所做出的最為重大的改變。此外，IIS 7.0的可擴充性得到了提高，IIS 7.0提供了配置委托，使用了 XML配置檔案，加入了請求跟蹤和診斷功能。因為 IIS 7.0提供了這些新的管理工具，是以，與先前版本的 IIS 相比，IIS 7.0受到了管理者的廣泛歡迎

        與先前版本的IIS 相比，IS 7.0的子產品化設計還有利于我們開發定制子產品，而且附加功能也更容易實作。進而有利于将内部開發的功能與 IIS更好地結合，還有利于将第三方資源與IIS 更好地結合，甚至有利于微軟公司開發的功能與IIS更好地結合。這是因為；無論何時，在無須修改作業系統核心功能的情況下，這些子產品和附加程式都可以作為 IIS的插件進行工作，是以，微軟公司的IIS開發團隊可以在微軟公司的标準servicepack過程之外釋出功能子產品。最終，我們可以更加迅速地獲得所需的産品

內建的請求管道

        IIS 7.0 的最大變化之一是它可以與 ASP.NET及ASP.NET程序進行緊密內建。IIS 7.0提供了統一的事件管道，該管道将現有的兩種獨立管道——即IIS管道和ASP.NET管道進行了合并，這兩種管道是IIS6.0以及先前版本的IIS提供的。ASP.NET的HTTP子產品原先僅偵聽 ASP.NET 管道的事件，現在可以監聽任何請求。為了向後相容，IIS7.0還提供了Classic 管道模式，Classic 管道模式可以模拟IIS6.0的 IIS管道，也可以模拟 IIS 6.0的ASP.NET管道

        在 IIS 6.0 身份驗證模型中，IIS 6.0 首先需要對一個HTTP 請求進行檢查以完成身份驗證，然後将請求傳遞給管道。任何已安裝的 ISAPI 過濾器都要對請求進行求值(例如，由URLScan 對請求進行處理)；然後檢查緩存，其目的在于檢查該請求是否已經存在，如果無法從緩存中處理該請求，那麼需要加上檔案的擴充名來确定對應的請求處理程式。例如，如果擴充名是.SHTM，那麼将激活伺服器方的 includes 程序，在被處理的頁面中加入附加代碼，然後，該頁面被當作一個 HTML 請求進行處理，并沿着管道進行傳送，并且将響應記錄到日志中，最後将請求頁面傳回給浏覽器

        如果請求檔案是一個ASP.NET檔案，其擴充名是.ASPX，那麼上述處理過程就更複雜 了，這個處理過程可以參見下圖。此時，該請求被發送給ASPNET_ISAPLDLL，然後開始在ASP.NET管道中進行處理。然後，再次對請求進行身份驗證，并檢查ASP.NET緩存，确定合适的 ASP.NET處理程式，然後處理請求，并對請求進行級存、記錄日志，然後，将請求傳遞給 Http.sys管道完成處理，最後将請求的頁面傳回給浏覽器

        之是以如此處理，是因為IIS6.0架構中包括了一個單獨的單體DLL，需要加載所有的元件子產品。每個ISAPI擴充也是一個單獨的DLL，與CGI程序一樣，都需要加載到記憶體中，每個請求都要通過各個 DLL進行處理。IIS6.0可以使用應用程式池，還可以單獨實作Http.sys程序，這樣就提高了總體性能，但是我們無法對coreserver操作本身進行性能調優。

        IIS7.0提供了一個單獨的統一管道，如下圖所示。ASP.NET提供的Forms身份驗證和角色管理是身份驗證和授權過程的組成部分，是以對一個請求僅驗證一次。在IIS7.0中，所有的請求都要經過 ASP.NET的 Forms身份驗證子產品進行處理，而不僅僅是那些具有.ASPX 擴充名的檔案才需要由 ASP.NET的 Forms身份驗證子產品進行處理。例如，對www.domain1.com/images/myimage.gif的請求首先要傳遞給ASP.NET的Forms身份驗證程序，如果 web.config 檔案中的某種身份驗證方式拒絕通路該檔案或檔案夾，那麼缺少權限的使用者就無法觀察或下載下傳該圖像。現在将請求傳遞給管道并退出，然後再傳遞給送出請求的浏覽器，是以無須再傳遞給ASP.NET等 ISAPI 程序。考慮到相容性問題，盡管 ISAPI處理程式退出時需要傳回一個退出編碼，但是實際上請求并沒有在ISAPI中進行處理，如果我們不需要考慮遺留代碼的相容性，我們甚至不需要加載ISAPI處理程式

        現在，程式員可能發現他們已經不再需要使用ISAPI，他們隻要ASP.NET的托管代碼(他們對此更為熟悉)就可以滿足同樣的需求。

        在 IIS 7.0管道内部，每個程序都由一個單獨的元件進行處理。需要使用這些元件的網站可以單獨加載這些元件，如果網站或應用程式不需要在管道中使用這些元件，那麼就無須加載這些元件。在應用程式級、網站級和伺服器級，這些元件都是可配置的，而且，我們可以在上述任何一個級别中委托元件的配置功能。此外，我們還可以将自定義的元件插入管道，甚至可以将管道中元件的執行順序重新進行排列——例如，當請求開始執行時，可以觸發一個日志跟蹤操作，并且當請求結束處理後，将日志跟蹤寫入一個檔案。元件的執行順序就是各個元件在配置檔案中所處的順序

IIS 7.0 的另一個變化是:

        IIS 的配置過程已經內建到ASP.NET 應用程式的配置過程中，這個變化是一個相當顯著的變化。現在我們無須再使用IIS系統資料庫設定，而原先作為IIS配置庫的 metabase 已經被基于 XML的配置檔案所取代，這個基于 XML的配置檔案中同時儲存了 IIS 設定和 ASP.NET 設定。這樣，不僅消除了 ASP.NET 應用程式和應用伺服器之間的界限，同時還提高了 IIS 的可配置性，簡化了網站和應用程式的部署過程。同時，在 web farm 中的多系統上部署應用程式也更為友善，并且改善了配置的可擴充性。IIS7.0引入了共享配置的概念，在這個概念中，多個 Web 伺服器可以使用同一個實體檔案作為各自的配置檔案，這樣，如果我們對 Web farm 的配置進行修改，那麼修改的内容可以馬上生效

        現在，IIS 7.0 使用一個名為 applicationHost.config 的檔案儲存設定，此外，針對一個獨立的 Web 網站或 Web 應用程式，IIS 7.0的配置選項也可以随着ASP.NET的設定一同儲存在web.config 檔案中，當然，IIS7.0的配置選項儲存在該檔案的system.webServer節點中

使用 applicationHost.config 配置檔案

        IIS 7.0 使用檔案 applicationHost.config 為 Web 伺服器和程序模型儲存IIS配置，現在，全局配置儲存在%windir%\system32Vinetsrv 目錄下的 applicationHost.config 檔案中，該檔案包括兩個主要的部分：

system.applicationHost——這部分内容儲存了網站、應用程式、虛拟目錄和應用程式池的配置資訊

system.webServer——這部分儲存了其他設定及全局預設設定

        對 URL 位置所進行的配置既可以儲存在applicationHost.config 檔案中，也可以儲存在web.config 檔案中。這樣，管理者可以設定伺服器上的預設位置，而開發人員可以在必要的情況下重新定義這些設定。這些設定可以由 web.config 檔案在根級和應用程式級進行繼承。在對設定進行委托時，這一點非常重要，因為IIS 管理者可以允許開發人員在應用程式級以很細的粒度對設定進行控制，同時，IIS管理者還能夠在網站級對設定進行控制

        IIS安裝結束後，可以使用applicationHost.config 檔案來修改IIS伺服器或網站的特性。例如，如果在一個IIS 網站中選擇使用Windows身份驗證，那麼可以使用IIS Manager來添加 Windows身份驗證，這個過程與先前版本的IIS類似。也可以在applicationHost.config檔案中使用以下代碼對一個名為 MyWebSite的網站進行設定，進而完成同樣的工作：

<location path="MyWebSite">
  <system.webServer>
    <security>
      <authentication>
        <windowshuthentication/>
      </authentication>
    </security>
  </system.vebBerver>
</location>
           

與此類似，為一個網站添加 ASP也非常簡單：

<system.webBerver>
	<asp/>
</system.webServer>
           

配置應用程式池同樣也非常簡單：

<system.applicationHost>
  <applicationPoo1s>
    <applicationPoo1Defaults>
      <processModel userName="SitelAppPoolUser" password="Passw0rd"/>
    </appl1cationPoo1Defaults>
     </add name="SitelAppPoo1"/>
 </appl1cationPools>
</system.applicatfonHost>
           

        IIS 7.0采用這種新型配置方式具有兩大優勢。第一個優勢是在無須使用配置系統資料庫的情況下，就可以使用 XCopy 方式部署網站或應用程式，與使用導入/導出 metabase設定的方式相比，這将使得跨 Wcb farm 部署變得相當容易。同時，這種配置方式還提高了在遠端伺服器上部署的速度，而且，當Web網站應用程式包含了特定的配置時，這種配置方式還可以為自定義的Web網站應用程式提供簡潔的客戶安裝手段

        這種新配置方式的第二個優勢是：開發人員可以為其所開發的應用程式修改配置檔案，确定必要的IIS配置需求。這個修改操作可以進行委托，這樣，必須使用的HIS配置就不會被意外修改。此外，設定具有層次結構，是以，伺服器設定級聯到網站和應用程式級，這樣就可以暫時不修改低級的設定。這樣，習慣于使用配置檔案來配置應用程式的開發人員就無須再學習IIS的管理，而管理者可以讓開發人員自行配置其開發的應用程式，同時，管理者仍然掌控着整個系統

可擴充的配置架構

        利用新的配置模型，可以很容易對IIS 7.0配置進行擴充。現在，假定我們需要為IIS建立一個新的子產品。此時，需要在 applicationHost.config 檔案的

<globalModules>

節點指出子產品對應的DLL檔案，然後，在applicationHost.config檔案中或适當的web.config檔案中聲明該子產品。為新子產品擴充配置架構與在系統的 inetsrv\config\schema 目錄中建立架構檔案一樣簡單。通過在applicationHost.config檔案的

<configSections>

配置節中添加節點内容，就可以完成這項工作

例如，可以在

<globalModules>

節點中添加以下内容：

<globalModules>
	<add name="MyNexModule”image="c:\modules\MyNewModule.dl1”/>
	...
</globalModules>
           

然後,将以下内容添加到使用該子產品的網站的applicationHost.config檔案(或web.config檔案)中的

<modules>

節點内：

<modules>
	<add name="MyNewModule/>
	...
</modules>
           

然後，需要為新子產品在 inetsrvlconfigschema 檔案夾中建立一個新的架構檔案MyNewModule.xml:

<configSchema>
  <sectionSchema name="MyNewModule">
    <attribute name="enabled" type="bool" defaultVaiue="false" />
    <attribute name="message" type="string" defaultValue="Hello World!" />
  </sectionSchema>
</configSchema>
           

最後，需要在 applicationHost.config 檔案中注冊該節内容，如下所示：

<configSections>
	<section name="MyNexModule" />
	...
</configSections>
           

通過使用上述方法對配置檔案進行簡單修改，就已經成功地為 IIS 添加了一個自定義

子產品MyNewModule，該子產品具有自定義的架構