發佈時間：2007年5月2日
通過：
在這一系列文章中，我要去處理，並描述一個Web請求的生命週期的早期階段，其生命，當它接受由Web服務器，通過其處理到ASP.NET管道一代管道的端點的響應。
介紹
微軟的Active Server Pages的，也被稱爲ASP，因爲它的第一個版本在1996年年底提供的Web開發人員提供了一個豐富 而複雜的框架用於構建Web應用程序。隨着時間的流逝，其基礎設施的發展和完善，以至於現在被稱爲ASP.NET已不再是類似於其前身。 ASP.NET是一個框架，用於構建Web應用程序，也就是在Web上運行的應用程序，客戶端-服務器範例表示主要是在瀏覽器的不同種類的資源，到Web服務器轉發請求。CGI，PHP，JSP和ASP等服務器端資源的動態生成技術問世之前 ，所有Web服務器必須做的是接受客戶的靜態資源的請求，並將其轉發給請求者。當動態技術開始成長起來的Web服務器成爲投資承擔更大的責任，因爲他們不得不找到一種方法來生成那些站在他們一邊的動態資源並將結果返回到客戶端，他們以前沒有建任務。
從鳥的眼睛視圖，客戶端和服務器之間的交互是非常簡單的。在網上發生的通信，應用水平依賴於TCP協議通過HTTP（超文本傳輸協議）和IP傳輸兩個節點之間的數據連接到異構網絡被稱爲萬維網。
每個動態服務 器端技術基本上斜靠在一個特定的Web服務器實現， ASP.NET是微軟的Internet信息服務器，又名IIS緊密結合。
不同的服務器上選擇了不同的方式來生成和動態資源，就是我們要研究的是如何IIS一起請求的路徑，如下一次在服務器上，並返回給客戶端的服務。
IIS和ISAPI擴展
如前所述，靜態資源不需要由服務器處理的，一次這樣的資源的請求到達時，服務器從文件系統中檢索它的內容，並將其發送回給客戶端，作爲字節流的流動上的HTTP協議。靜態資源可以是圖像，JavaScript文件，CSS樣式表或普通的HTML頁面。很顯然，服務器需要知道如何區分靜態和動態的資源，而第二個需要以某種方式處理，而不是僅僅發送回客戶端。這就是出現ISAPI擴展，ISAPI代表的互聯網服務器應用程序編程接口ISAPI擴展模塊實現普通的老式的Win32
DLL，IIS依靠處理特定資源。ISAPI擴展和文件之間的映射配置通過IIS管理單元和存儲在IIS元數據庫中，每一個文件的擴展名可以與一個特定的ISAPI擴展，也就是說，對此類文件的請求到達時，IIS處理相應的ISAPI擴展，有信心，這將是能夠處理它。
圖1：在IIS 5.0上配置ISAPI擴展映射
ISAPI擴展顯然需要尊重一個共同的接口，通過它們可以被稱爲IIS提供了必要的數據來闡述請求並生成響應。
如圖1所示，asp擴展映射到asp.dll的 ISAPI 擴展，這個組件的ASP的時間是在負責執行所需的全部任務，就是收集有關請求的信息，生成響應到ASP 頁面通過請求，響應和其他常見的ASP內在對象，解析和執行的 ASP頁面，並返回生成的HTML。
其實，這是一個很大的改進的技術，如CGI相比，但ASP.NET採用這種方法能更進一步，並引入抽象，完全屏蔽了開發人員不必關心在這個階段會發生什麼。
安裝時，ASP.NET配置IIS，ASP.NET特定文件的請求重定向 到一個新的ISAPI擴展名爲aspnet_isapi.dll的。這擴展是有點不同，那麼前asp.dll的擴展，這是基本上只是負責分析和執行請求的ASP頁面。一個通用的ISAPI模塊處理請求而採取的步驟是完全隱藏IIS，因此 ISAPI擴展，可以按照不同的範式，以處理請求。
表1：IIS應用程序映射爲aspnet_isapi.dll的
| 延期 | 資源類型 |
| ASAX。 | ASP.NET應用程序文件。通常的Global.asax。 |
| 的。ascx | ASP.NET用戶控制文件。 |
| ashx的。 | HTTP處理程序，ISAPI擴展的管理對口。 |
| asmx的。 | ASP.NET Web服務。 |
| 的。aspx | ASP.NET網頁。 |
| AXD。 | ASP.NET內部HTTP處理程序。 |
表1中列出的文件擴展名，ASP.NET ISAPI 擴展管理其他文件擴展名通常不提供網頁瀏覽器，如Visual Studio項目文件，源代碼文件和配置文件，例如。
ASP.NET進程模型
到目前爲止，我們已經看到，當請求一個ASP.NET文件拾起 IIS，它被傳遞給aspnet_isapi.dll的，這是ASP.NET相關處理的主入口點 。其實，ISAPI擴展確實理智取決於IIS系統上可用的版本，並可能會有很大的過程模型，它是由ASP.NET運行時執行的操作來處理請求並生成響應的順序，一點點。
IIS 5.X 下運行時，所有的ASP.NET相關的請求派出的 ISAPI擴展名爲aspnet_wp.exe的外部工作進程。 ASP.NET ISAPI擴展的IIS進程 inetinfo.exe的主持，通過控制aspnet_wp.exe的，連同所有有關的信息傳入的請求。兩者之間的通信是通過命名管道，一個衆所周知的IPC（進程間通信）機制。ASP.NET工作進程進行了相當數量的任務，與ISAPI擴展。他們的ASP.NET請求的抽油煙機下發生的所有的東西，是主要作者。介紹將在後面討論的一個話題，請注意一個事實，每一個web應用程序，IIS託管在不同的虛擬目錄，對應 的上下文中執行相同的過程中，ASP.NET工作進程。爲了提供隔離和抽象從執行上下文ASP.NET模型引入了應用程序域的概念，在簡短的AppDomain。它們可以被認爲是輕量進程。在此以後。
的另一邊，如果運行在IIS 6下，aspnet_wp.exe的過程中不使用，在向另一個進程名爲w3wp.exe的。此外，inetinfo.exe的不再使用的HTTP請求轉發到ISAPI擴展，雖然它一直運行其他協議請求服務。使用以前版本的IIS進程模型相比很多其他細節變化，雖然IIS 6能夠在兼容模式下運行，其前身效仿行爲。水平較低-內核- 前進了一大步，比IIS 5 上運行時，使用的過程模型 ，前者處理傳入的請求，然後轉發到正確的ISAPI擴展，從而避免了進程間通信技術這可能代表一個昂貴的操作下的性能和資源消耗的角度來看。在下面的段落中，我們將深入到這個話題。
IIS 5.0進程模型
這是默認的進程模型，可在Windows 2000和XP機器。正如前面提到的，包括在默認情況下，IIS inetinfo.exe的進程聽傳入的HTTP請求到一個單一的隊列和排隊，等待被處理的TCP端口上80 。如果請求是特定於ASP.NET，處理委託給ASP.NET ISAPI 擴展aspnet_isapi.dll的。這反過來，通信與ASP.NET輔助進程aspnet_wp.exe的通過命名管道，最後是負責的工作進程提供ASP.NETHTTP運行時環境的要求。這個過程是在圖2中以圖形方式表示。
圖2：IIS 5.0進程模型
在圖2中表示一個額外的元素，我們沒有提到的是，ASP.NET HTTP運行時環境。這不是這篇文章的主題，並在後續的文章，但爲了討論HTTP運行時環境，可以看作是一個黑盒子，所有的ASP.NET特定的處理髮生，所有的託管代碼最終會被解釋生命和開發商其實可以把他們的手，誰最終將處理請求並生成響應的HttpHandler的httpRuntime直。這甚至被稱爲爲ASP.NET 管道或HTTP運行時管道。
這個過程模型的一個有趣的點是，所有的請求，一旦所處理的 ISAPI擴展，傳遞給ASP.NET工作進程。這個過程中只有一個實例是活躍在同一時間，但有一個例外，稍後討論。因此，所有的ASP.NET Web應用程序託管在IIS實際上是託管工作進程裏面，太。然而，這並不意味着，所有的應用程序都運行在相同的情況下，並分享他們的所有數據。如前所述， ASP.NET介紹AppDomain中的概念，它本質上是一種管理的輕量級進程提供隔離和安全邊界。每個IIS虛擬目錄的執行，這是自動加載到工作進程時，屬於該應用程序的資源請求第一次在一個單一的AppDomain。一旦在AppDomain加載-也就是說，需要滿足該請求的所有程序集加載到AppDomain中-控制實際上是傳遞給 ASP.NET管道的實際處理。因此，多個AppDomain可以運行在同一個進程中，由多個線程同時請求相同的AppDomain可以送達。然而，一個線程不屬於一個AppDomain，可以起到不同的AppDomain的請求，但在一個給定的時間內，一個線程屬於一個單一的AppDomain。
就性能而言，可以回收工作進程，根據一些標準，可以指定在machine.config文件放置在目錄C：\ WINDOWS \ microsoft.net \框架\ [框架版本] \ CONFIG聲明。這些標準是年齡的過程中，服務請求和排隊數量，花費的時間空閒和消耗的內存。一旦達到這些參數閾值，ISAPI擴展創建一個新的工作進程，我們將從此使用服務請求的實例。這是唯一的時候，可以同時運行多個副本的過程。事實上，舊的流程實例沒有死亡，但它允許終止掛起的請求提供服務。
IIS 6.0進程型號“
IIS 6進程模型的機器上運行的是Windows 2003 Server操作系統是默認的模型。它引入了一些變化和改進，在IIS 5的過程模型。最大的變化之一是應用程序池的概念。在IIS 5.X所有Web應用程序，那就是所有AppDomain，被託管的ASP.NET工作進程。達到更精細的粒度通過安全邊界和個性化，在IIS 6進程模型允許應用程序內運行新的工作進程，w3wp.exe的不同副本。每個應用程序池可以包含多個AppDomain和託管工作進程的一個副本。換句話說，這種轉變是從一個單一的過程，所有的應用程序託管託管每一個應用程序池的多個進程。這種模式也稱爲工作進程隔離模式。
從以前的模型的另一個大的變化是IIS偵聽傳入請求的方式。IIS 5的模型，這是IIS進程，inetinfo.exe的，誰是在一個特定的TCP端口監聽HTTP請求。在IIS 6架構，處理傳入的請求，並通過名爲HTTP.SYS的內核驅動程序在內核級別，而不是用戶模式排隊，這種方法有幾個優點舊的模式，被稱爲內核級別的請求排隊。
圖3：IIS 6.0進程模型
圖3示出部分中的請求的處理時，使用的II 6模型的主要組成部分。一旦請求到達內核級別的設備驅動程序HTTP.SYS將其路由到正確的應用程序池隊列。每個隊列屬於一個特定的應用程序池，從而達到一個特定的工作進程，下次收到請求從隊列副本。這種方法的高度降低了使用命名管道沒有進程間通信正在發生在IIS 5型自引入的開銷，但要求爲首的工作進程，直接從內核級別的驅動程序。關於可靠性也具有許多優點。由於在內核模式下運行，請求調度不會受到用戶級別，就是在工作進程崩潰和故障happing。因此，即使工作進程崩潰，系統仍然能夠接受傳入的請求，並最終重新啓動崩潰的過程。
它的工作過程是誰在負責加載ASP.NET ISAPI 擴展，這反過來，HTTP運行時加載的CRL和所有的工作委託。
w3wp.exe的工作進程，aspnet_wp.exe的過程中使用IIS 5型不同，是不是特定於ASP.NET，並用於處理任何請求。具體的工作進程，然後決定哪些的ISAPI模塊加載根據資源的類型，它需要服務。
圖3爲簡單起見不強調一個細節是通過加載一個模塊在IIS 6中被稱爲Web管理服務（WAS）傳入的請求從應用程序池隊列轉發到合適的工作進程。此模塊是負責讀取工作進程-從IIS元數據庫和Web應用程序綁定，將請求轉發給正確的工作進程。