IIS 5.x與ASP.NET

我們先來看看IIS 5.x是如何處理基于ASP.NET資源（比如.aspx,.asmx等）請求的，整個過程基本上可以通過圖1體現(xiàn)。

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

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

?

?圖1 IIS 5.x與ASP.NET?

ISAPI是Internet服務(wù)器API（Internet Server Application Programming Interface）的縮寫，是一套本地的（Native）Win32 API，具有較高的執(zhí)行性能,是IIS和其他動態(tài)Web應(yīng)用或者平臺之間的紐帶。比如ASP ISAPI橋接IIS與ASP，而ASP.NET ISAPI則連接著IIS與ASP.NET。ISPAI定義在一個Dll中，ASP.NET ISAPI對應(yīng)的Dll為Aspnet_isapi.dll,你可以在目錄“%windir%Microsoft.NETFramework{version no}”中找到該Dll。

ISAPI支持ISAPI擴(kuò)展（ISAPI Extension）和ISAPI篩選（ISAPI Filter），前者是真正處理HTTP請求的接口，后者則可以在HTTP請求真正被處理之前查看、修改、轉(zhuǎn)發(fā)或者拒絕請求，比如IIS可以利用ISAPI篩選進(jìn)行請求的驗(yàn)證（Authentication）。

如果我們請求的是一個基于ASP.NET的資源類型，比如：.aspx Web Page、 .asmx Web Service或者.svc WCF Service等，Aspnet_isapi.dll會被加載，ASP.NET ISAPI擴(kuò)展會創(chuàng)建ASP.NET的工作進(jìn)程（如果該進(jìn)程尚未啟動），對于IIS 5.x來說，該工作進(jìn)程為aspnet.exe。IIS進(jìn)程與工作進(jìn)程之間通過命名管道（Named Pipes）進(jìn)程通信，以獲得最好的性能。

在工作進(jìn)程初始化過程中，.NET 運(yùn)行時（CLR）被加載，從而構(gòu)建了一個托管的環(huán)境。對于某個Web應(yīng)用的初次請求，CLR會為其創(chuàng)建一個AppDomain。在此AppDomain中，HTTP運(yùn)行時（HTTP Runtime）被加載并用以創(chuàng)建相應(yīng)的應(yīng)用。對于寄宿于IIS 5.x的所有Web 應(yīng)用都運(yùn)行在同一個進(jìn)程（工作進(jìn)程Aspnet_wp.exe）的不同AppDomain中。

IIS 6與ASP.NET

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

• ISAPI Dll被加載到InetInfo.exe進(jìn)程中，它和工作進(jìn)程之間是一種典型的跨進(jìn)程通信方式，盡管采用性能最好的命名管道，但是仍然會帶來性能的瓶頸；
• 所有的ASP.NET應(yīng)用，運(yùn)行在相同的進(jìn)程（aspnet_wp.exe）中的不同的應(yīng)用程序域（AppDomain）中，基于應(yīng)用程序域的隔離級別不能從根本上解決一個應(yīng)用程序?qū)α硪粋€程序的影響，在更多的時候，我們需要不同的Web應(yīng)用運(yùn)行在不同的進(jìn)程中。

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

當(dāng)然，除了上面兩點(diǎn)改進(jìn)之外，IIS 6.0還有其他一些值得稱道的地方，其中最重要的一點(diǎn)就是創(chuàng)建了一個新的HTTP監(jiān)聽器：HTTP協(xié)議棧（HTTP Protocol Stack，HTTP.SYS）。HTTP.SYS運(yùn)行在Windows的內(nèi)核模式（Kernel Mode）下，作為驅(qū)動程序而存在。它是Windows 2003的TCP/IP網(wǎng)絡(luò)子系統(tǒng)的一部分，從結(jié)構(gòu)上，它屬于TCP之上的一個網(wǎng)絡(luò)驅(qū)動程序。嚴(yán)格地說，HTTP.SYS已經(jīng)不屬于IIS的范疇了，所以HTTP.SYS的配置信息并不保存在IIS的元數(shù)據(jù)庫（Metabase），而是定義在注冊表中。HTTP.SYS的注冊表項(xiàng)位于下面的路徑中：HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/HTTP。HTTP.SYS能夠帶來如下的好處：

• 持續(xù)監(jiān)聽：由于HTTP.SYS是一個網(wǎng)絡(luò)驅(qū)動程序，始終處于運(yùn)行狀態(tài)，對于用戶的HTTP請求，能夠及時作出反應(yīng)；
• 更好的穩(wěn)定性：HTTP.SYS運(yùn)行在操作系統(tǒng)內(nèi)核模式下，并不執(zhí)行任何用戶代碼，所以其本身不會受到Web應(yīng)用、工作進(jìn)程和IIS進(jìn)程的影響；
• 內(nèi)核模式下數(shù)據(jù)緩存：如果某個資源被頻繁請求，HTTP.SYS會把響應(yīng)的內(nèi)容進(jìn)行緩存，緩存的內(nèi)容可以直接響應(yīng)后續(xù)的請求。由于這是基于內(nèi)核模式的緩存，不存在內(nèi)核模式和用戶模式的切換，響應(yīng)速度將得到極大的改進(jìn)。

圖2體現(xiàn)了IIS的結(jié)構(gòu)和處理HTTP請求的流程。從中可以看出，與IIS 5.x不同，W3SVC從InetInfo.exe進(jìn)程脫離出來（對于IIS6.0來說，InetInfo.exe基本上可以看作單純的IIS管理進(jìn)程），運(yùn)行在另一個進(jìn)程SvcHost.exe中。不過W3SVC的基本功能并沒有發(fā)生變化，只是在功能的實(shí)現(xiàn)上作了相應(yīng)的改進(jìn)。與IIS 5.x一樣，元數(shù)據(jù)庫（Metabase）依然存在于InetInfo.exe進(jìn)程中。

?

?圖2 IIS 6與ASP.NET

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

IIS 7.0與ASP.NET

IIS 7.0對請求的監(jiān)聽和分發(fā)機(jī)制上又進(jìn)行了革新性的改進(jìn)，主要體現(xiàn)在對于Windows進(jìn)程激活服務(wù)（Windows Process Activation Service，WAS）的引入，將原來（IIS 6.0）W3SVC承載的部分功能分流給了WAS。具體來說，通過上面的介紹，我們知道對于IIS 6.0來說，W3SVC主要承載著三大功能：

• HTTP請求接收：接收HTTP.SYS監(jiān)聽到的HTTP請求；
• 配置管理：從元數(shù)據(jù)庫（Metabase）中加載配置信息對相關(guān)組件進(jìn)行配置；
• 進(jìn)程管理：創(chuàng)建、回收、監(jiān)控工作進(jìn)程。

在IIS 7.0，后兩組功能被移入WAS中，接收HTTP請求的任務(wù)依然落在W3SVC頭上。WAS的引入為IIS 7.0一項(xiàng)前所未有的特性：同時處理HTTP和非HTTP請求。在WAS中，通過一個重要的接口：監(jiān)聽器適配器接口（Listener Adapter Interface）抽象出不同協(xié)議監(jiān)聽器監(jiān)聽到的請求。至于IIS下的監(jiān)聽器，除了基于網(wǎng)絡(luò)驅(qū)動的HTTP.SYS提供HTTP請求監(jiān)聽功能外，WCF提供了3種類型的監(jiān)聽器：TCP監(jiān)聽器、命名管道（Named Pipes）監(jiān)聽器和MSMQ監(jiān)聽器，分別提供了基于TCP、命名管道和MSMQ傳輸協(xié)議的監(jiān)聽功能。與此3種監(jiān)聽器相對的，是3種監(jiān)聽器適配器（Adapter）提供監(jiān)聽器與監(jiān)聽器適配器接口之間的適配。從這個意義上講，IIS 7.0中的W3SVC更多地為HTTP.SYS起著監(jiān)聽適配器的功能。WCF提供的這3種監(jiān)聽器和監(jiān)聽適配器定義在程序集SMHost.exe中，你可以通過下面的目錄找到該程序集：%windir%Microsoft.NETFrameworkv3.0Windows Communication Foundatio。

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

• NetTcpPortSharing：為WCF提供TCP端口共享，關(guān)于端口共享；
• NetTcpActivator：為WAS提供基于TCP的激活請求，包含TCP監(jiān)聽器和對應(yīng)的監(jiān)聽適配器；
• NetPipeActivator：為WAS提供基于命名管道的激活請求，包含命名管道監(jiān)聽器和對應(yīng)的監(jiān)聽適配器；
• NetMsmqActivator：為WAS提供基于MSMQ的激活請求，包含MSMQ監(jiān)聽器和對應(yīng)的監(jiān)聽適配器。

圖3為上述的4個Windows Service在服務(wù)控制管理器（SCM）中的呈現(xiàn)。

?

圖3 定義在SMHost.exe中的Windows Service

圖4揭示了IIS 7.0的整體構(gòu)架以及整個請求處理流程。無論是從W3SVC接收到的HTTP請求，還是通過WCF提供的監(jiān)聽適配器接收到的請求，最終都會傳遞到WAS。如果相應(yīng)的工作進(jìn)程（或者應(yīng)用程序池）尚未創(chuàng)建，其創(chuàng)建之；否則將請求分發(fā)給對應(yīng)的工作進(jìn)程進(jìn)行后續(xù)的處理。WAS在進(jìn)行請求處理過程中，通過內(nèi)置的配置管理模塊加載相關(guān)的配置信息對相關(guān)的組建進(jìn)行配置，與IIS 5.x和IIS 6.0基于Metabase的配置信息存儲不同的是，IIS 7.0大都將配置信息存放于XML形式的配置文件中。基本的配置存放在applicationHost.cofig中。

? 圖4 IIS 7與ASP.NET

?

ASP.NET集成

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

?

圖5 基于IIS 6.0與ASP.NET雙管道設(shè)計

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

• 相同操作的重復(fù)執(zhí)行：IIS與ASP.NET之間具有一些重復(fù)的操作，比如身份驗(yàn)證；
• 動態(tài)文件與靜態(tài)文件處理的不一致：因?yàn)橹挥谢贏SP.NET的動態(tài)文件（比如.aspx、.asmx、.svc等等）的HTTP請求才能通過ASP.NET ISAPI進(jìn)入ASP.NET管道，而對于一些靜態(tài)文件（比如.html、.xml、.img等）的請求，則由IIS直接響應(yīng)，那么ASP.NET管道中的一些功能將不能用于這些基于靜態(tài)文件的請求，比如，我們希望通過Forms認(rèn)證應(yīng)用于基于圖片文件的請求；
• IIS難以擴(kuò)展：對于IIS的擴(kuò)展基本上就體現(xiàn)在自定義ISAPI，但是對于大部分人來說，這不是一件容易的事情。因?yàn)镮SAPI是基于Win32的非托管的API，并非一種面向應(yīng)用的編程接口。通常我們希望的是諸如定義ASP.NET的HttpModule和HttpHandler一樣，通過托管代碼的方式來擴(kuò)展IIS。

對于Windows平臺下的IIS來講，ASP.NET無疑是一等公民，它們之間不應(yīng)該是“井水不犯河水”的關(guān)系，而應(yīng)該是“你中有我，我中有你”的關(guān)系。為此，在IIS 7.0中，實(shí)現(xiàn)了兩者的集成。對于集成模式下的IIS 7.0，我們獲得如下的好處。

• 允許我們通過本地代碼（Native Code）和托管代碼（Managed Code）兩種方式定義IIS Module，這些IIS Module注冊到IIS中形成一個通用的請求處理管道。由這些IIS Module組成的這個管道能夠處理所有的請求，不論請求基于怎樣的資源類型。比如，可以將FormsAuthenticationModule提供的Forms認(rèn)證應(yīng)用到基于.aspx，CGI和靜態(tài)文件的請求。
• 將ASP.NET提供的一些強(qiáng)大的功能應(yīng)用到原來難以企及的地方，比如將ASP.NET的URL重寫功能置于身份驗(yàn)證之前；
• 采用相同的方式去實(shí)現(xiàn)、配置、檢測和支持一些服務(wù)器特性（Feature），比如Module、Handler映射、錯誤定制配置（Custom Error Configuration）等。

?圖6 基于IIS 7.0與ASP.NET集成管道設(shè)計

圖6演示了在ASP.NET集成模式下，IIS整個請求處理管道的結(jié)構(gòu)。我們可以看到，原來ASP.NET提供的托管組件可以直接應(yīng)用在IIS管道中。

ASP.NET管道

以IIS 6.0為例，在工作進(jìn)程w3wp.exe中，利用Aspnet_ispai.dll加載.NET運(yùn)行時（如果.NET運(yùn)行時尚未加載）。IIS 6引入了應(yīng)用程序池的概念，一個工作進(jìn)程對應(yīng)著一個應(yīng)用程序池。一個應(yīng)用程序池可以承載一個或者多個Web應(yīng)用，每個Web應(yīng)用映射到一個IIS虛擬目錄。與IIS 5.x一樣，每一個Web應(yīng)用運(yùn)行在各自的應(yīng)用程序域中。

如果HTTP.SYS接收到的HTTP請求是對該Web應(yīng)用的第一次訪問，當(dāng)成功加載了運(yùn)行時后，會通過AppDomainFactory為該Web應(yīng)用創(chuàng)建一個應(yīng)用程序域（AppDomain）。隨后，一個特殊的運(yùn)行時IsapiRuntime被加載。IsapiRuntime定義在程序集System.Web中，對應(yīng)的命名空間為System.Web.Hosting。IsapiRuntime會接管該HTTP請求。

IsapiRuntime會首先創(chuàng)建一個IsapiWorkerRequest對象，用于封裝當(dāng)前的HTTP請求，并將該IsapiWorkerRequest對象傳遞給ASP.NET運(yùn)行時：HttpRuntime，從此時起，HTTP請求正式進(jìn)入了ASP.NET管道。根據(jù)IsapiWorkerRequest對象，HttpRuntime會創(chuàng)建用于表示當(dāng)前HTTP請求的上下文（Context）對象：HttpContext。

隨著HttpContext被成功創(chuàng)建，HttpRuntime會利用HttpApplicationFactory創(chuàng)建新的或者獲取現(xiàn)有的HttpApplication對象。實(shí)際上，ASP.NET維護(hù)著一個HttpApplication對象池，HttpApplicationFactory從池中選取可用的HttpApplication用戶處理HTTP請求，處理完畢后將其釋放到對象池中。HttpApplicationFactory負(fù)責(zé)處理當(dāng)前的HTTP請求。

在HttpApplication初始化過程中，會根據(jù)配置文件加載并初始化相應(yīng)的HttpModule對象。對于HttpApplication來說，在它處理HTTP請求的不同的階段會觸發(fā)不同的事件（Event），而HttpModule的意義在于通過注冊HttpApplication的相應(yīng)的事件，將所需的操作注入整個HTTP請求的處理流程。ASP.NET的很多功能，比如身份驗(yàn)證、授權(quán)、緩存等，都是通過相應(yīng)的HttpModule實(shí)現(xiàn)的。

而最終完成對HTTP請求的處理實(shí)現(xiàn)在另一個重要的對象中：HttpHandler。對于不同的資源類型，具有不同的HttpHandler。比如.aspx頁對應(yīng)的HttpHandler為System.Web.UI.Page，WCF的.svc文件對應(yīng)的HttpHandler為System.ServiceModel.Activation.HttpHandler。上面整個處理流程如圖7所示。

?

圖7 ASP.NET 處理管道

HttpApplication

HttpApplication是整個ASP.NET基礎(chǔ)架構(gòu)的核心，它負(fù)責(zé)處理分發(fā)給它的HTTP請求。由于一個HttpApplication對象在某個時刻只能處理一個請求，只有完成對某個請求的處理后，HttpApplication才能用于后續(xù)的請求的處理。所以，ASP.NET采用對象池的機(jī)制來創(chuàng)建或者獲取HttpApplication對象。具體來講，當(dāng)?shù)谝粋€請求抵達(dá)的時候，ASP.NET會一次創(chuàng)建多個HttpApplication對象，并將其置于池中，選擇其中一個對象來處理該請求。當(dāng)處理完畢，HttpApplication不會被回收，而是釋放到池中。對于后續(xù)的請求，空閑的HttpApplication對象會從池中取出，如果池中所有的HttpApplication對象都處于繁忙的狀態(tài)，ASP.NET會創(chuàng)建新的HttpApplication對象。

HttpApplication處理請求的整個生命周期是一個相對復(fù)雜的過程，在該過程的不同階段會觸發(fā)相應(yīng)的事件。我們可以注冊相應(yīng)的事件，將我們的處理邏輯注入到HttpApplication處理請求的某個階段。我們接下來介紹的HttpModule就是通過HttpApplication事件注冊的機(jī)制實(shí)現(xiàn)相應(yīng)的功能的。表1按照實(shí)現(xiàn)的先后順利列出了HttpApplication在處理每一個請求時觸發(fā)的事件名稱。

表1

名稱	描述
BeginRequest	HTTP管道開始處理請求時，會觸發(fā)BeginRequest事件
AuthenticateRequest，PostAuthenticateRequest	ASP.NET先后觸發(fā)這兩個事件,使安全模塊對請求進(jìn)行身份驗(yàn)證
AuthorizeRequest，PostAuthorizeRequest	ASP.NET先后觸發(fā)這兩個事件,使安全模塊對請求進(jìn)程授權(quán)
ResolveRequestCache，PostResolveRequestCache	ASP.NET先后觸發(fā)這兩個事件，以使緩存模塊利用緩存的直接對請求直接進(jìn)程響應(yīng)（緩存模塊可以將響應(yīng)內(nèi)容進(jìn)程緩存，對于后續(xù)的請求，直接將緩存的內(nèi)容返回，從而提高響應(yīng)能力）。
PostMapRequestHandler	對于訪問不同的資源類型，ASP.NET具有不同的HttpHandler對其進(jìn)程處理。對于每個請求，ASP.NET會通過擴(kuò)展名選擇匹配相應(yīng)的HttpHandler類型，成功匹配后，該實(shí)現(xiàn)被觸發(fā)
AcquireRequestState，PostAcquireRequestState	ASP.NET先后觸發(fā)這兩個事件，使?fàn)顟B(tài)管理模塊獲取基于當(dāng)前請求相應(yīng)的狀態(tài)，比如SessionState
PreRequestHandlerExecute，PostRequestHandlerExecute	ASP.NET最終通過一請求資源類型相對應(yīng)的HttpHandler實(shí)現(xiàn)對請求的處理，在實(shí)行HttpHandler前后，這兩個實(shí)現(xiàn)被先后觸發(fā)
ReleaseRequestState，PostReleaseRequestState	ASP.NET先后觸發(fā)這兩個事件，使?fàn)顟B(tài)管理模塊釋放基于當(dāng)前請求相應(yīng)的狀態(tài)
UpdateRequestCache，PostUpdateRequestCache	ASP.NET先后觸發(fā)這兩個事件，以使緩存模塊將HttpHandler處理請求得到的相應(yīng)保存到輸出緩存中
LogRequest，PostLogRequest	ASP.NET先后觸發(fā)這兩個事件為當(dāng)前請求進(jìn)程日志記錄
EndRequest	整個請求處理完成后，EndRequest事件被觸發(fā)

對于一個ASP.NET應(yīng)用來說，HttpApplication派生于global.asax文件，我們可以通過創(chuàng)建global.asax文件對HttpApplication的請求處理行為進(jìn)行定制。global.asax采用一種很直接的方式實(shí)現(xiàn)了這樣的功能，這種方式既不是我們常用的方法重寫（Method Overriding）或者事件注冊，而是直接采用方法名匹配。在global.asax中，我們按照這樣的方法命名規(guī)則進(jìn)行事件注冊：Application_{Event Name}。比如Application_BeginRequest方法用于處理HttpApplication的BeginRequest事件。如果通過VS創(chuàng)建一個global.asax文件，下面是默認(rèn)的定義。

1: <%@ Application Language="C#" %> 2: <script runat="server"> 3: void Application_Start(object sender, EventArgs e) {} 4: void Application_End(object sender, EventArgs e) {} 5: void Application_Error(object sender, EventArgs e) {} 6: void Session_Start(object sender, EventArgs e) {} 7: void Session_End(object sender, EventArgs e) {} 8: </script>

HttpModule

ASP.NET為創(chuàng)建各種.NET Web應(yīng)用提供了強(qiáng)大的平臺，它擁有一個具有高度可擴(kuò)展性的引擎，并且能夠處理對于不同資源類型的請求。那么，是什么成就了ASP.NET的高可擴(kuò)展性呢？ HttpModule功不可沒。

從功能上講，HttpModule之于ASP.NET，就好比ISAPI Filter之于IIS一樣。IIS將接收到的請求分發(fā)給相應(yīng)的ISAPI Extension之前，注冊的ISAPI Filter會先截獲該請求。ISAPI Filter可以獲取甚至修改請求的內(nèi)容，完成一些額外的功能。與之相似地，當(dāng)請求轉(zhuǎn)入ASP.NET管道后，最終負(fù)責(zé)處理該請求的是與請求資源類型相匹配的HttpHandler對象，但是在Handler正式工作之前，ASP.NET會先加載并初始化所有配置的HttpModule對象。HttpModule在初始化的過程中，會將一些功能注冊到HttpApplication相應(yīng)的事件中，那么在HttpApplication整個請求處理生命周期中的某個階段，相應(yīng)的事件會被觸發(fā)，通過HttpModule注冊的事件處理程序也得以執(zhí)行。

所有的HttpModule都實(shí)現(xiàn)了IHttpModule接口，下面是IHttpModule的定義。其中Init方法用于實(shí)現(xiàn)HttpModule自身的初始化，該方法接受一個HttpApplication對象，有了這個對象，事件注冊就很容易了。

1: public interface IHttpModule 2: { 3: void Dispose(); 4: void Init(HttpApplication context); 5: }

ASP.NET提供的很多基礎(chǔ)構(gòu)件（Infrastructure）功能都是通過相應(yīng)的HttpModule實(shí)現(xiàn)的，下面類列出了一些典型的HttpModule:

• OutputCacheModule：實(shí)現(xiàn)了輸出緩存（Output Caching）的功能；
• SessionStateModule：在無狀態(tài)的HTTP協(xié)議上實(shí)現(xiàn)了基于會話（Session）的狀態(tài)；
• WindowsAuthenticationModule + FormsAuthenticationModule + PassportAuthentication- Module：實(shí)現(xiàn)了3種典型的身份認(rèn)證方式：Windows認(rèn)證、Forms認(rèn)證和Passport認(rèn)證；
• UrlAuthorizationModule + FileAuthorizationModule：實(shí)現(xiàn)了基于Uri和文件ACL（Access Control List）的授權(quán)。

而另外一個重要的HttpModule與WCF相關(guān)，那么就是System.ServiceModel. Activation.HttpModule。HttpModule定義在System.ServiceModel程序集中，在默認(rèn)的情況下，HttpModule完成了基于IIS的寄宿工作。

除了這些系統(tǒng)定義的HttpModule之外，我們還可以自定義HttpMoudle。通過Web.config，我們可以很容易地將其注冊到我們的Web應(yīng)用中。

HttpHandler

如果說HttpModule相當(dāng)于IIS的ISAPI Filter的話，我們可以說HttpHandler則相當(dāng)于IIS的ISAPI Extension，HttpHandler在ASP.NET中扮演請求的最終處理者的角色。對于不同資源類型的請求，ASP.NET會加載不同的Handler來處理，也就是說.aspx page與.asmx web service對應(yīng)的Handler是不同的。

所有的HttpHandler都實(shí)現(xiàn)了接口IHttpHandler。下面是IHttpHandler的定義，方法ProcessRequest提供了處理請求的實(shí)現(xiàn)。

1: public interface IHttpHandler 2: { 3: void ProcessRequest(HttpContext context); 4: bool IsReusable { get; } 5: }

對于某些HttpHandler，具有一個與之相關(guān)的HttpHandlerFactory，用于創(chuàng)建或者獲取相應(yīng)的HttpHandler。HttpHandlerFactory實(shí)現(xiàn)接口IHttpHandlerFactory，方法GetHandler用于創(chuàng)建新的HttpHandler，或者獲取已經(jīng)存在的HttpHandler。

1: public interface IHttpHandlerFactory 2: { 3: IHttpHandler GetHandler(HttpContext context, string requestType, string url, string pathTranslated); 4: void ReleaseHandler(IHttpHandler handler); 5: }

HttpHandler和HttpHandlerFactory的類型都可以通過相同的方式配置到Web.config中。下面一段配置包含對3種典型的資源類型的HttpHandler配置：.aspx,.asmx和.svc。可以看到基于WCF Service的HttpHandler類型為：System.ServiceModel.Activation.HttpHandler。

1: <?xml version="1.0" encoding="utf-8" ?> 2: <configuration> 3: <system.web> 4: <httpHandlers> 5: <add path="*.svc" verb="*" type="System.ServiceModel.Activation.HttpHandler, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" validate="false"/> 6: <add path="*.aspx" verb="*" type="System.Web.UI.PageHandlerFactory" validate="True"/> 7: <add path="*.asmx" verb="*" type="System.Web.Services.Protocols.WebServiceHandlerFactory, System.Web.Services, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" validate="False"/> 8: </httpHandlers> 9: </system.web> 10: </configuration>

轉(zhuǎn)載于:https://www.cnblogs.com/micua/p/3502706.html

總結(jié)

以上是生活随笔為你收集整理的IIS与ASP.NET管道的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。