IIS7.0特性有哪些

IIS7.0特性有哪些，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

IIS 7.0能夠與ASP.NET框架高度集成，并且提供了完整的API，從而可以為平臺提供完整的可擴展能力和管理接口。還提供了配置委托和完整的診斷套件，診斷套件可以對需求進行跟蹤，還提供了高級日志功能。IIS 7.0將ASP.NET與請求管道進行了集成，這也許是IIS 7.0所做出的最為重大的改變。
IIS 7.0的模塊化設計還有利于我們開發定制模塊，而且附加功能也更容易實現。從而有利于將內部開發的功能與IIS更好地結合，還有利于將第三方資源與IIS更好地結合，甚至有利于微軟公司開發的功能與IIS更好地結合。這是因為：無論何時，在無需修改操作系統核心功能的情況下，這些模塊和附加程序都可以作為IIS的插件進行工作，因此微軟公司的IIS開發團隊可以在微軟公司的標準service pack過程之外發布功能模塊。

集成的請求管道
IIS 7.0最大的變化之一是它可以與ASP.NET及ASP.NET進程進行緊密集成。IIS 7.0提供了統一的事件管道，該管道將現有的兩種獨立管道----即IIS管道和ASP.NET管道進行了合并，這兩種管道是IIS 6.0以及先前版本的IIS提供的。ASP.NET的HTTP模塊原先僅偵聽ASP.NET管道的事件，現在可以監聽任何請求。為了向后兼容，IIS 7.0還提供了Classic管道模式，Classic管道模式可以模擬IIS 6.0的IIS管道，也可以模擬IIS 6.0的ASP.NET管道。

IIS 7.0提供了一個單獨的統一管道。ASP.NET提供的Forms身份驗證和角色管理是身份驗證和授權過程的組成部分，因此對一個請求僅驗證一次。在IIS 7.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處理程序。

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

可配置性
IIS 7.0的另一個變化是：IIS的配置過程已經集成到ASP.NET應用程序的配置過程中，這個變化是一個相當顯著的變化。現在我們無須再使用IIS注冊表設置，而原先作為IIS配置庫的metabase已經被基于XML的配置文件所取代，這個基于XML的配置文件中同時保存了IIS設置和ASP.NET設置。這樣，不僅消除了ASP.NET應用程序和應用服務器之間的界限，同時還提高了IIS的可配置性，簡化了網站和應用程序的部署過程。同時，在web farm中的多系統上部署應用程序也更為方便，并且改善了配置的可擴展性。IIS 7.0引入了共享配置的概念，在這個概念中，多個web服務器可以使用同一個物理文件作為各自的配置文件，這樣如果我們對web farm的配置進行修改，那么修改的內容可以馬上生效。
現在，IIS 7.0使用一個名為applicationHost.config的文件保存設置，此外，針對一個獨立的Web網站或Web應用程序，IIS 7.0的配置選項也可以隨著ASP.NET的設置一同保存在web.config文件中，當然，IIS 7.0的配置選項保存在該文件的system.webServer一節中。

1.使用applicationHost.config配置文件

IIS 7.0使用文件applicationHost.config為Web 服務器和集成模型保存IIS配置，現在，全局配置保存在%windir%\system32\inetsrv\config 目錄下的applicationHost.config文件中，該文件包括兩個主要的部分：

（1）system.applicationHost 這部分內容保存了網站、應用程序、虛擬目錄和應用程序池的配置信息。

（2）system.webServer 這部分保存了其他設置及全局默認設置。

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

2.可擴展的配置架構

利用新的配置模型，可以很容易對 IIS 7.0配置進行擴展。現在，假定我們需要為 IIS 創建一個新的模塊。此時，需要在 applicationHost.config 文件的 <globalModules>一節指出模塊對應的 DLL 文件，然后，在 applicationHost.config 文件中或適當的 web.config 文件中聲明該模塊。為新模塊擴展配置架構與在系統的 inetsrv\config\schema 目錄中創建架構文件一樣簡單。通過在 applicationHost.config 文件的<configSections>配置節中添加一節內容，就可以完成這項工作。

組件化
IIS 7.0的可擴展性不僅表現在配置過程。因為 IIS 7.0對請求處理管道進行了修改，通過使用本機代碼和托管代碼，核心服務器本身也得到了擴展。這種擴展性來源于 IIS 核心功能的組件化。此時不需要再使用 ISAPI 過濾器來修改請求過程，我們可以將自行開發的組件直接注入到處理管道中。自行開發的組件既可以是我們自己開發的組件，也可以是第三方工具或組件，還可以是微軟公司提供的現有核心組件。所以，如果不喜歡 Windows 身份驗證過程，那么不僅可以對所有的文件使用 forms 身份驗證過程，而且還可以選擇忽略所有內置的身份驗證過程，而采用我們開發的身份驗證過程。這還意味著：如果不需要處理傳統的 ASP 文件，那么只要不再加載對應的組件就可以了。在先前的 IIS 版本中，每個組件需要當作一個單獨的 DLL 加載到內存中，現在不再需要加載無關的內容，從而減少了 IIS 7.0的開銷。

看完上述內容，你們掌握IIS7.0特性有哪些的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！