[ASP.NET]談談IIS與ASP.NET管道

做爲一個Asp.Net平臺開發者,很是有必要了解IIS和Asp.Net是如何結合,執行咱們的託管代碼,以及Asp.Net管道事件的.

 

本節目錄

• IIS 5.X
• IIS 6
• IIS 7+
• 集成模式
• Asp.Net管道
• HttpModule
• HttpHandle

 

IIS 5.x

InetInfo.exe與W3SVC服務

IIS 5.x運行在進程InetInfo.exe中，在該進程中一個最重要的服務就是名爲World Wide Web Publishing Service（簡稱W3SVC）的Windows Service。

W3SVC的主要功能包括HTTP請求的監聽、工做進程的管理以及配置管理（經過從Metabase中加載相關配置信息）等。

 

請求資源(根據擴展名區分靜態和動態資源)

靜態文件，直接返回文件內容。

動態資源，經過擴展名從IIS的腳本影射（Script Map）找到相應的ISAPI Dll。

 

ISAPI

ISAPI是Internet服務器API（Internet Server Application Programming Interface）的縮寫.是IIS和其餘應用的紐帶.

ISAPI包括ISAPI Extension和ISAPI Filter

 

ISAPI Extension

不用種類的動態資源,會有不一樣的ISAPI擴展.

如Asp.Net(.aspx .asmx .svc等)則爲aspnet_isapi.dll。在目錄「%windir%\Microsoft.NET\Framework\{version no}\」中找到該dll。

 

ISAPI Filter

Filter則能夠在HTTP請求真正被處理以前查看、修改、轉發或者拒絕請求，好比IIS能夠利用ISAPI篩選進行請求的驗證（Authentication）。

 

請求Asp.Net

若是咱們請求的是一個基於ASP.NET的資源:

1. 加載aspnet_isapi.dll
2. 建立工做進程（第一次請求）
3. 加載CLR(第一次請求)
4. 建立AppDomain(某個web應用的第一次請求)
5. 執行ISAPIRuntime.

說明：

1. 對於IIS 5.x來講，該工做進程爲aspnet_wp.exe。
2. aspnet_isapi.dll與工做進程之間經過命名管道（Named Pipes）進程通訊，以得到最好的性能。
3. 對於寄宿於IIS 5.x的全部Web 應用都運行在同一個工做進程的不一樣AppDomain中。

 

IIS 6

IIS5的不足

1. aspnet_isapi與工做進程之間是跨進程通訊。
2. 全部的web應用都是在同一個工做進程中。

 

IIS6解決辦法

1. 將aspnet_ispai.dll加載到工做進程中。
2. 創建應用程序池，一個應用程序池對應一個工做進程。

 

另外在IIS6中，建立新的http監聽器：HTTP協議棧（HTTP Protocol Stack，HTTP.SYS）

• 持續監聽：因爲HTTP.SYS是一個網絡驅動程序，始終處於運行狀態，對於用戶的HTTP請求，可以及時做出反應；
• 更好的穩定性：HTTP.SYS運行在操做系統內核模式下，並不執行任何用戶代碼，因此其自己不會受到Web應用、工做進程和IIS進程的影響；
• 內核模式下數據緩存：若是某個資源被頻繁請求，HTTP.SYS會把響應的內容進行緩存，緩存的內容能夠直接響應後續的請求。因爲這是基於內核模式的緩存，不存在內核模式和用戶模式的切換，響應速度將獲得極大的改進。

 

 

請求Asp.Net

與IIS5.X不一樣的是:

1.W3SVC服務根據請求建立工做進程

2.aspnet_isapi.dll是在工做進程的初始化過程當中被加載。

  

 

說明：

1. W3SVC服務已經從iis進程中脫離出來。http.sys接受到請求，將直接分發給w3svc服務
2. 在IIS6中工做進程名爲w3wp.exe
3. 工做進程的這種建立方式被稱爲請求式建立

 

IIS 7+

W3SVC服務

在IIS6中的W3SVC服務的功能

• HTTP請求接收：接收HTTP.SYS監聽到的HTTP請求；
• 配置管理：從元數據庫（Metabase）中加載配置信息對相關組件進行配置；
• 進程管理：建立、回收、監控工做進程。

在IIS7中W3SVC只負責第一個功能,剩餘功能交給WAS服務管理

 

WAS服務

IIS7引入Windows進程激活服務（Windows Process Activation Service，WAS）：同時處理HTTP和非HTTP請求。

 

在WAS中，定義了一個重要的接口：監聽器適配器接口（Listener Adapter Interface）抽象出不一樣協議監聽器監聽到的請求。

WAS將監聽W3SVC服務的http請求以及WCF服務的TCP、Named Pipes、MSMQ3種請求.

 

說明

WCF提供的這3種監聽器和監聽適配器定義在程序集SMHost.exe中，你能夠經過下面的目錄找到該程序集：%windir%\Microsoft.NET\Framework\v3.0\Windows Communication Foundation。

SMHost.exe提供了4個重要的Windows Service：

• NetTcpPortSharing：爲WCF提供TCP端口共享，關於端口共享；
• NetTcpActivator：爲WAS提供基於TCP的激活請求，包含TCP監聽器和對應的監聽適配器；
• NetPipeActivator：爲WAS提供基於命名管道的激活請求，包含命名管道監聽器和對應的監聽適配器；
• NetMsmqActivator：爲WAS提供基於MSMQ的激活請求，包含MSMQ監聽器和對應的監聽適配器。

 

集成模式

傳統模式的缺點

• 相同操做的重複執行：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。

 

集成模式

實際上IIS7集成模式，就是讓用戶能夠經過編寫託管代碼的module，把託管代碼插入到IIS內核代碼中來解析，方便你們精確控制任意請求，帶來更好的擴展性。

(這裏面每一個靜態文件也會通過生命週期事件,執行效率確定會有所降低.)

 

配置文件上的區別

  <!--傳統模式-->
  <system.web>
    <customErrors mode="RemoteOnly">
      <error statusCode="404" redirect="404.html"/>
      <error statusCode="500" redirect="500.html"/>
    </customErrors>
    <compilation debug="true" targetFramework="4.5" />
    <httpRuntime targetFramework="4.5" />
  </system.web>
  <!--集成模式-->
  <system.webServer>
    <httpErrors errorMode="DetailedLocalOnly">
      <clear/>
      <error path="404.html" statusCode="404"/>
      <error path="500.html" statusCode="500"/>
    </httpErrors>
  </system.webServer>

 

Asp.Net管道

 

1. 加載CLR:在工做進程中,ISAPI負責進行CLR的加載（若是.NET運行時還沒有加載）.
2. 建立AppDomain:當成功加載了運行時後，會經過AppDomainFactory爲該Web應用建立一個應用程序域（AppDomain）。
3. 執行ISAPIRuntime的int ProcessRequest(IntPtr ecb, int iWRType)方法
4. 執行HttpRuntime的PR方法　　
5. 獲取httpapplication實例,調用httpapplication的pr方法
6. 觸發httpapplication各事件.

 

擴展

1. 在HttpApplication初始化過程當中，會根據配置文件加載並初始化相應的HttpModule對象。對於HttpApplication來講，在它處理HTTP請求的不一樣的階段會觸發不一樣的事件（Event），而HttpModule的意義在於經過註冊HttpApplication的相應的事件，將所需的操做注入整個HTTP請求的處理流程。ASP.NET的不少功能，好比身份驗證、受權、緩存等，都是經過相應的HttpModule實現的。
2. 而最終完成對HTTP請求的處理實如今另外一個重要的對象中：HttpHandler。對於不一樣的資源類型，具備不一樣的HttpHandler。好比.aspx頁對應的HttpHandler爲System.Web.UI.Page，WCF的.svc文件對應的HttpHandler爲System.ServiceModel.Activation.HttpHandler。
3. 對於一個ASP.NET應用來講，HttpApplication派生於global.asax文件，咱們能夠經過建立global.asax文件對HttpApplication的請求處理行爲進行定製。global.asax採用一種很直接的方式實現了這樣的功能，這種方式既不是咱們經常使用的方法重寫（Method Overriding）或者事件註冊，而是直接採用方法名匹配。在global.asax中，咱們按照這樣的方法命名規則進行事件註冊：Application_{Event Name}。好比Application_BeginRequest方法用於處理HttpApplication的BeginRequest事件。 

 

 

 

 

 

HttpModule

從功能上講，HttpModule之於ASP.NET，就比如ISAPI Filter之於IIS同樣。IIS將接收到的請求分發給相應的ISAPI Extension以前，註冊的ISAPI Filter會先截獲該請求。

若是說HttpModule至關於IIS的ISAPI Filter的話，咱們能夠說HttpHandler則至關於IIS的ISAPI Extension，HttpHandler在ASP.NET中扮演請求的最終處理者的角色。 

當請求轉入ASP.NET管道後，最終負責處理該請求的是與請求資源類型相匹配的HttpHandler對象，可是在Handler正式工做以前，ASP.NET會先加載並初始化全部配置的HttpModule對象。HttpModule在初始化的過程當中，會將一些功能註冊到HttpApplication相應的事件中，那麼在HttpApplication整個請求處理生命週期中的某個階段，相應的事件會被觸發，經過HttpModule註冊的事件處理程序也得以執行。

全部的HttpModule都實現了IHttpModule接口.

namespace System.Web
{
  public interface IHttpModule
  {
    void Init(HttpApplication context);

    void Dispose();
  }
}

 

系統定義的HttpModule

• OutputCacheModule：實現了輸出緩存（Output Caching）的功能；
• SessionStateModule：在無狀態的HTTP協議上實現了基於會話（Session）的狀態；
• WindowsAuthenticationModule + FormsAuthenticationModule：實現了3種典型的身份認證方式：Windows認證、Forms認證；
• WCFModule:使Asp.Net擴展出WCF服務(System.ServiceModel.Activation.HttpModule)

 

自定義HttpMoudle

1. 實現IHttpMoudle
2. 修改配置文件Web.config

 

 

 

HttpHandle

對於不一樣資源類型的請求，ASP.NET會加載不一樣的Handler來處理，也就是說.aspx page與.asmx web service對應的Handler是不一樣的。

全部的HttpHandler都實現了接口IHttpHandler。

  public interface IHttpHandler
  {
    bool IsReusable { get; }

    void ProcessRequest(HttpContext context);
  }

 

系統定義的HttpHandle

WebForm的aspx文件:System.Web.UI.Page

WCF的svc文件:System.ServiceModel.Activation.HttpHandler

MVC:MVCHandler

 

自定義HttpHandle

因爲Handle是在PostMapRequestHandler前和 PostResolveRequestCache 後映射指定的Handle,

因此咱們能夠在PostResolveRequestCache事件中註冊咱們的Handle.

在PreRequestHandlerExecute 後將會調用咱們的Handle.PR方法.　　

 

 

 

擴展

HttpApplication主要有19個事件,經過個人網站任意地址+參數便可訪問全部事件。

+?pipe能夠查看這些事件觸發時間.如:http://neverc.cn?pipe

+?pe能夠附帶個人網站內容：http://neverc.cn?pe

猜猜如何實現出以上效果

 

本文地址：http://neverc.cnblogs.com/p/4807836.html

本文參考:  http://www.cnblogs.com/artech/archive/2009/06/20/1507165.html