IIS7架構原理

IIS7架構簡介：

1：Windows進程激活服務（WAS），使網站使用HTTP和HTTPS以外的其他協議。

　　Windows 進程激活服務通過刪除對 HTTP 的依賴關系，可統一 Internet 信息服務 (IIS) 進程模型。通過使用非 HTTP 協議，以前只可用於 HTTP 應用程序的 IIS 的所有功能現在都可用於運行 Windows Communication Foundation (WCF) 服務的應用程序。IIS 7.0 還使用 Windows 進程激活服務通過 HTTP 實現基於消息的激活。

2：Web服務器引擎，它可以通過添加或刪除模塊定制。

3: 集成的IIS和AS​​P.NET請求處理管線。

 

IIS 7.0 的 ASP.NET 應用程序生命周期 托管管道模式：經典模式(Classic) 集成模式(Integrated)

首先聲明兩個概念：ASP.NET應用程序生命周期、 ASP.NET頁生命周期(http://msdn.microsoft.com/zh-cn/library/ms178472(v=vs.100).aspx)

“管道模式”針對ASP.NET應用程序生命周期而言，區分為 經典模式和集成模式。

 

IIS7.0集成管道是一種統一的請求處理管道，它同時支持本機代碼和托管代碼模塊。實現IHttpModule接口的托管代碼模塊可訪問該請求管道中的所有事件。例如，托管代碼模塊可用於 ASP.NET 網頁（.aspx 文件）和 HTML 頁（.htm 或 .html 文件）的 ASP.NET Forms 身份驗證。 

權威參考：http://msdn.microsoft.com/zh-cn/library/bb470252(v=VS.100).aspx

 

在IIS6.0中，有兩個請求處理管道：1.用於本機代碼ISAPI篩選器和擴展組件；2.用於托管代碼應用程序組件。在IIS7.0 中，ASP.NET運行時與Web服務器集成，有了一個針對所有請求的統一請求處理管道。

權威參考： http://msdn.microsoft.com/zh-cn/library/ms178473(v=vs.100).aspx

IIS5、IIS6原理：

 

IIS 5.x與ASP.NET

IIS 5.x運行在IIS進程InetInfo.exe中，在該進程中一個最重要的服務就是名為World Wide Web Publishing Service（簡稱W3SVC）的Windows Service。W3SVC的主要功能包括HTTP請求的監聽、工作進程的管理以及配置管理（通過從Metabase中加載相關配置信息）等。

當檢測到某個HTTP Request后，先根據擴展名判斷請求的是否是靜態資源（比如.html,.img,.txt,.xml等），如果是則直接將文件內容以HTTP Response的形式返回。如果是動態資源（比如.aspx,asp,php等等），則通過擴展名從IIS的腳本影射（Script Map）找到相應的ISAPI Dll。

 

ISAPI是Internet服務器API（Internet Server Application Programming Interface）的縮寫，是一套本地的Win32 API，具有較高的執行性能,是IIS和Web應用或者平台之間的紐帶。比如ASP ISAPI橋接IIS與ASP，而ASP.NET ISAPI則連接着IIS與ASP.NET。ISPAI定義在一個Dll中，ASP.NET ISAPI對應的Dll為Aspnet_isapi.dll,你可以在目錄“%windir%\Microsoft.NET\Framework\{version no}\”中找到該Dll。

ISAPI支持ISAPI擴展和ISAPI篩選，前者是真正處理HTTP請求的接口，后者則可以在HTTP請求真正被處理之前查看、修改、轉發或者拒絕請求，比如IIS可以利用ISAPI篩選進行請求的驗證（Authentication）。

如果請求ASP.NET的資源類型，Aspnet_isapi.dll會被加載，ASP.NET ISAPI擴展會創建ASP.NET的工作進程（如果該進程尚未啟動），對於IIS 5.x來說，該工作進程為aspnet_wp.exe。IIS進程與工作進程之間通過命名管道進程通信，以獲得最好的性能。

在工作進程初始化過程中，.NET 運行時（CLR）被加載，從而構建了一個托管的環境。對於某個Web應用的初次請求，CLR會為其創建一個AppDomain。在此AppDomain中，HTTP Runtime被加載並用以創建相應的應用。對於寄宿於IIS 5.x的所有Web 應用都運行在同一個進程（工作進程Aspnet_wp.exe）的不同AppDomain中。

 

IIS 6與ASP.NET

通過上面的介紹，我們可以看出IIS 5.x至少存在着如下兩個方面的不足：

• ISAPI Dll被加載到InetInfo.exe進程中，它和工作進程之間是一種典型的跨進程通信方式，盡管采用性能最好的命名管道，但是仍然會帶來性能的瓶頸；

• 所有的ASP.NET應用，運行在相同的進程（aspnet_wp.exe）中的不同的應用程序域（AppDomain）中，基於應用程序域的隔離級別不能從根本上解決一個應用程序對另一個程序的影響，在更多的時候，我們需要不同的Web應用運行在不同的進程中。

在IIS 6.0中，為了解決第一個問題，ISAPI.dll被直接加載到工作進程中。為了解決第2個問題，引入了應用程序池（Application Pool）的機制。我們可以為一個或者多個Web應用創建應用程序池，每一個應用程序池對應一個獨立的工作進程，從而為運行在不同應用程序池中的Web應用提供基於進程的隔離級別。IIS 6.0的工作進程名稱為w3wp.exe。

IIS 6.0創建了一個新的HTTP監聽器：HTTP協議棧（HTTP Protocol Stack，HTTP.SYS）。HTTP.SYS運行在Windows的內核模式（Kernel Mode）下，作為驅動程序而存在。它是Windows 2003的TCP/IP網絡子系統的一部分，從結構上，它屬於TCP之上的一個網絡驅動程序。嚴格地說，HTTP.SYS已經不屬於IIS的范疇了，所以HTTP.SYS的配置信息並不保存在IIS的元數據庫（Metabase），而是定義在注冊表中。HTTP.SYS的注冊表項位於下面的路徑中：HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/HTTP。HTTP.SYS能夠帶來如下的好處：

• 持續監聽：由於HTTP.SYS是一個網絡驅動程序，始終處於運行狀態，對於用戶的HTTP請求，能夠及時作出反應；

• 更好的穩定性：HTTP.SYS運行在操作系統內核模式下，並不執行任何用戶代碼，所以其本身不會受到Web應用、工作進程和IIS進程的影響；

• 內核模式下數據緩存：如果某個資源被頻繁請求，HTTP.SYS會把響應的內容進行內核模式的緩存(不存在內核模式和用戶模式的切換，響應速度將得到極大的改進)，緩存的內容可以直接響應后續的請求。

圖2體現了IIS的結構和處理HTTP請求的流程。從中可以看出，與IIS 5.x不同，W3SVC從InetInfo.exe進程脫離出來（對於IIS6.0來說，InetInfo.exe基本上可以看作單純的IIS管理進程），運行在另一個進程SvcHost.exe中。不過W3SVC的基本功能並沒有發生變化，只是在功能的實現上作了相應的改進。與IIS 5.x一樣，元數據庫（Metabase）依然存在於InetInfo.exe進程中。

 

當HTTP.SYS監聽到用戶的HTTP請求后，將其分發給W3SVC。W3SVC解析出請求的URL，並根據從Metabase獲取的URL與Web應用之間的映射關系得到目標應用，並進一步得到目標應用運行的應用程序池或者工作進程。如果工作進程不存在（尚未創建或者被回收），則為該請求創建新的工作進程，工作進程的這種創建方式被稱為請求式創建。在工作進程的初始化過程中，相應的ISAPI.dll被加載，對於ASP.NET應用來說，被加載的ISAPI.dll為Aspnet_ispai.dll。ASP.NET ISAPI再負責進行CLR的加載、AppDomain創建、Web Application的初始化等。

In IIS 6.0, W3SVC the following main areas in IIS:

• HTTP管理和配置（從IIS元數據讀取配置信息並配置協議棧HTTP.sys，）

• 進程管理（管理應用程序池和工作進程，啟動、停止、回收，工作進程健康狀態監視，失敗檢測）

• 進程監控

   

 

IIS 7.0與ASP.NET

權威參考：http://www.iis.net/learn/get-started/introduction-to-iis/introduction-to-iis-architecture

IIS 7.0對請求的監聽和分發機制上又進行了革新性的改進，主要體現在對於Windows進程激活服務（Windows Process Activation Service，WAS）的引入，將原來（IIS 6.0）W3SVC承載的部分功能分流給了WAS。對於IIS 6.0來說，W3SVC主要承載着三大功能：

• HTTP請求接收：接收HTTP.SYS監聽到的HTTP請求；

• 配置管理：從元數據庫（Metabase）中加載配置信息對相關組件進行配置；

• 進程管理：創建、回收、監控工作進程。

In IIS, the WWW service no longer manages worker processes. Instead, the WWW Service is the listener adapter for the HTTP listener, HTTP.sys. As the listener adapter, the WWW Service is primarily responsible for configuring HTTP.sys, updating HTTP.sys when configuration changes, and notifying WAS when a request enters the request queue.

Additionally, the WWW Service continues to collect the counters for Web sites. Because performance counters remain part of the WWW Service, they are HTTP specific and do not apply to WAS.

 

在IIS 7.0，后兩組功能被移入WAS中，接收HTTP請求的任務依然落在W3SVC頭上。

WAS的引入為IIS 7.0一項前所未有的特性：同時處理HTTP和非HTTP請求。在WAS中，通過一個重要的接口：監聽器適配器接口（Listener Adapter Interface）抽象出不同協議監聽器監聽到的請求。至於IIS下的監聽器，除了基於網絡驅動的HTTP.SYS提供HTTP請求監聽功能外，WCF提供了3種類型的監聽器：TCP監聽器、命名管道（Named Pipes）監聽器和MSMQ監聽器。對應3種監聽適配器（Adapter）提供監聽器與監聽器適配器接口之間的適配。從這個意義上講，IIS 7.0中的W3SVC更多地為HTTP.SYS起着監聽適配器的功能。WCF提供的這3種監聽器和監聽適配器定義在程序集SMSvcHost.exe中，你可以通過下面的目錄找到該程序集：%windir%\Microsoft.NET\Framework\v3.0\Windows Communication Foundatio。

WCF提供的這3種監聽器和監聽適配器最終以Windows Service的形式體現，雖然它們定義在一個程序集中，我們依然通過服務工作管理器（SCM，Service Control Manager）對其進行單獨的啟動、終止和配置。SMSvcHost.exe提供了4個重要的Windows Service：

• NetTcpPortSharing：為WCF提供TCP端口共享；

• NetTcpActivator：為WAS提供基於TCP的激活請求，包含TCP監聽器和對應的監聽適配器；

• NetPipeActivator：為WAS提供基於命名管道的激活請求，包含命名管道監聽器和對應的監聽適配器；

• NetMsmqActivator：為WAS提供基於MSMQ的激活請求，包含MSMQ監聽器和對應的監聽適配器。

 

 

ASP.NET集成

從上面對IIS 5.x和IIS 6.0的介紹中，我們不難發現這一點，IIS與ASP.NET是兩個相互獨立的管道（Pipeline），在各自管轄范圍內，它們各自具有自己的一套機制對HTTP請求進行處理。兩個管道通過ISAPI實現“聯通”：IIS是第一道屏障，當對HTTP請求進行必要的前期處理（比如身份驗證等）后，通過ISAPI將請求分發給ASP.NET管道。當ASP.NET在自身管道范圍內完成對HTTP請求的處理后，處理后的結果再返回到IIS，IIS對其進行后期處理（比如日志記錄、壓縮等），最終生成HTTP響應（HTTP Response）。從另一個角度講，IIS運行在非托管的環境中，而ASP.NET管道則是托管的，從這個意義上講，ISAPI還是連接非托管環境和托管環境的紐帶。下圖反映了IIS 6.0與ASP.NET之間的橋接關系。

IIS 5.x和IIS 6.0下把兩個管道進行隔離至少帶來了下面一些局限與不足：

• 相同操作的重復執行：IIS與ASP.NET之間具有一些重復的操作，比如身份驗證；

• 動態文件與靜態文件處理的不一致：因為只有基於ASP.NET的動態文件（比如.aspx、.asmx、.svc等等）的HTTP請求才能通過ASP.NET ISAPI進入ASP.NET管道，而對於一些靜態文件（比如.html、.xml、.img等）的請求，則由IIS直接響應，那么ASP.NET管道中的一些功能將不能用於這些基於靜態文件的請求，比如，我們希望通過Forms認證應用於基於圖片文件的請求；

• IIS難以擴展：對於IIS的擴展基本上就體現在自定義ISAPI，但是對於大部分人來說，這不是一件容易的事情。因為ISAPI是基於Win32的非托管的API，並非一種面向應用的編程接口。通常我們希望的是諸如定義ASP.NET的HttpModule和HttpHandler一樣，通過托管代碼的方式來擴展IIS。

對於Windows平台下的IIS來講，ASP.NET無疑是一等公民，它們之間不應該是“井水不犯河水”的關系，而應該是“你中有我，我中有你”的關系。為此，在IIS 7.0中，實現了兩者的集成。對於集成模式下的IIS 7.0，我們獲得如下的好處。

• 允許我們通過本地代碼（Native Code）和托管代碼（Managed Code）兩種方式定義IIS Module，這些IIS Module注冊到IIS中形成一個通用的請求處理管道。由這些IIS Module組成的這個管道能夠處理所有的請求，不論請求基於怎樣的資源類型。比如，可以將FormsAuthenticationModule提供的Forms認證應用到基於.aspx，CGI和靜態文件的請求。

• 將ASP.NET提供的一些強大的功能應用到原來難以企及的地方，比如將ASP.NET的URL重寫功能置於身份驗證之前；

• 采用相同的方式去實現、配置、檢測和支持一些服務器特性（Feature），比如Module、Handler映射、錯誤定制配置（Custom Error Configuration）等。

在ASP.NET集成模式下，IIS整個請求處理管道的結構。ASP.NET提供的托管組件可以直接應用在IIS管道中。