介紹
Microsoft Active Server Pages(微軟動態網頁服務)，同樣也被大家稱為ASP，首先是在1996年末年發布的，為程序員提供一個用來建立WEB應用程序豐富復雜的框架。幾年後，他的基礎構造發展改進了很多，也就是大家現在所了解的ASP.net.ASP.Net是一個用來構件WEB應用程序的框架，也就是說，他必須運行在WEB服務上，用客服端-服務端模型了表述的話通常是浏覽器發送不同類型的資源請求到WEB服務器。在出現動態服務器資源生成技術(如CGI，PHP，JSP以及ASP)，所有的WEB服務只能接受客服端的靜態資源請求並把他們回送到客服端。
表面上看起來,這樣在服務端和客戶端的交互是非常的簡單。會話通過HTTP協議進行，他是一個建立在TCP和IP協議(用來在2個連接到不同類型的網絡端點交換數據，如我們所知道的WWW萬維網)上的應用程序級協議。
本質上任何動態服務器技術需要運行在特定WEB服務上，同樣ASP.Net緊密地和微軟因特網信息服務，也叫做IIS。
不同的服務選擇不同的方式去生成動態資源等等。。。我們將要解析一下IIS是怎麼做到的當一個請求信息一旦到達服務端以及最後回送到客戶端。
IIS and ISAPI 擴展
如上面提到的，靜態資源不需要被服務器處理;一旦這樣的資源請求到達服務器，服務器只需要從文件系統中找到他的內容並且以字節流形式發送到客戶端通過HTTP協議。靜態資源可以是圖片，Javascript,CSS或者普通Html頁面。很顯然服務器需要知道怎樣去區分靜態和動態資源，動態資源需要如何被處理而不是直接發送回客戶端。因此出現了ISAPI擴展，ISAPI是因特網服務應用程序編程的接口。ISAPI作為模塊被執行如早期的Win32.dll.IIS依靠ISAPI來處理特定的資源。通過IIS映射ISAPI擴展和文件的方式，把每種文件擴展類型關聯到特定的ISAPI擴展，也就是說，當一個請求某種文件的請求到達，IIS處理並轉到相應的ISAPI擴展，以確認這種請求能被處理。
圖表1：在IIS5.0中配置ISAPI擴展映射
ISAPI擴展明顯需要符合一個通用接口，這樣他們才能被IIS調用並提供必要的數據用來處理請求和生成回送。
如圖1，.ASP擴展名被映射到asp.dll ISAPI擴展;在ASP處理時段，這個組件負責執行所有需要的任務去生成回送，也就是說，通過收集請求信息，並使得他能夠在ASP頁面可用，其他ASP內部對象，解析並執行ASP頁面最後以Html形式返回結果。
盡管，這樣相對於CGI技術來說已經是很大的進步了，但是ASP.Net更強大。
在安裝ASP.net後，ASP.net配置IIS 把ASP.Net指定的文件請求重定向到一個新的ISAPI擴展aspnet_isapi.dll.這個擴展有些不同於以前的ASP.dll擴展。
表格I：ASPnet_isapi.dll在IIS應用程序中的映射
ExtensionResource Type
.asaxASP.Net 應用程序文件. 常用的有 global.asax.
.ascxASP.Net 用戶控件文件.
.ashxHTTP handlers, the managed counterpart of ISAPI extensions.
.asmxASP.Net web services.
.aspxASP.Net web pages.
.axdASP.Net internal HTTP handlers.
除了表格1所列出的文件擴展名，ASP.Net ISAPI擴展也管理其他一些通常不提供給浏覽器訪問的文件擴展類型，如Visual Studio工程文件，資源文件以及配置文件。
ASP.Net處理模型
到目前為止，我們已經明白當請求一個asp.net文件的請求傳到IIS後，他被轉遞到aspnet_isapi.dll,他是asp.net相關處理的主要入口點。實際上，這個擴展明顯依賴於系統上IIS的版本，因此處理模型是通過ASP.Net運行時通過有序的操作執行來處理請求並生成回送，也許有那麼一點改變。
在IIS5.X，所有asp.net相關請求通過ISAPI擴展被分配到外部工作進程叫做aspnet_wp.exe.ISAPI擴展，在IIS進程(inetinfo.exe)中運行,再傳遞控制權連同所有關於當前傳入請求的信息到aspnet_wp.exe。2個進程間的通信通過命名管道(眾所周知IPC[內部進程通信]機制建立。ASP.NET工作進程執行ISAPI擴展的大部分任務。注意一下每個WEB應用程序的實質，以及與IIS下不同虛擬目錄的通訊，他們在asp.net工作進程同一個進程的上下文中被執行。為了實現讀取各自執行中上下文ASP.Net引入了應用程序域的概念，縮寫AppDomains.他們可以被認為是一個輕量級的進程。更多的將在後面介紹。
如果運行在IIS6上，ASPnet_wp.exe進程沒有被使用，選擇一個更優的進程叫做w3wp.exe.同時，inetinfo.exe也不再用來傳遞HTTP請求到ISAPI擴展，盡管這樣他還是保持為其他協議的請求提供服務。雖然IIS6能夠運行在兼容模式下並且模擬之前的行為，但是相對於先前的IIS5處理模型有了很多的變化。相對早期最大改變，當處理模型運行在IIS5上，傳入進來的請求以lower-kernel-level形式然後傳遞到正確的ISAPI擴展，從而避免在內部信息處理方面花費過多的操作。在下面的段落中，我們將進行更深入的研究。
IIS5.0 處理模型
在Windows2000以及XP系統上這是默認的處理模型。如上所說他有IIS inetinfo.exe進程默認在TCP端口80監聽傳入的HTTP請求並且把他們推送進隊列等待處理。如果請求類型是asp.net,處理將委托給asp.net isapi擴展 aspnet_isapi.dll.這樣輪流通過命名管道與asp.net工作進程通信，最終工作進程處理並傳遞請求到ASP.Net HTTP運行時環境。圖表2將具體描敘這個過程。
圖表2：IIS5.0處理模型
圖表2顯示一個我們尚未提到過的元素—ASP.NET HTTP運行時環境。目前他並不是我們這編文章的主題，他將在接下來的文章中被解析。HTTP運行時可以被看作一個黑色盒子，所有ASP.NET指定處理在這裡發生，所有的受管制代碼運行場所，從HTTP運行時一直到httphandler最終處理請求並生成回送都在這裡被處理。這裡還涉及到ASP.Net管道或http運行時管道。
就這個模型有一個有趣的地方就是所有請求，一旦被ISAPI擴展處理，就被傳遞到asp.net工作進程。每次活動時間有且僅有一個進行實例，一個例外，後面討論。因此所運行在IIS上的asp.net web應用程序實際上也運行在工作進程上。盡管如此，這並不意味著所有應用運行在同一個上下文上並共享他們所有的數據。值得一提，asp.net引入APPDomain概念，本質上是一種提供獨立和安全邊界的受管制輕量級進程。每個IIS虛擬目錄在一個APPDomain裡執行，他將自動加載到工作進程只要資源是屬於第一次請求的應用程序。一旦appdomain被加載，換句話說，當前請求所有需要的程序集被加載到appdomain–實際上是傳遞到ASP.Net管道處理。若干appdomains能夠這樣運行在同樣的進程中，當多個請求對於同樣的appdomain能夠在多個線程出來。盡管如此，一個線程並不屬於一個appdomain，他能為多個不同的appdomians處理多個請求,但是同一個給定的時間一個線程屬於一個APPdomain.
處於性能目的，工作線程能夠根據一些標准(通過MacHINCE.CONFIG文件配置)被回收。這些標准包括進程生命周期，請求以及隊列數量，空閒時間，內存分配。一旦達到這些參數中一項臨界值，ISAPI擴展將生成一個新的工作進程實例用來處理請求。實際上，先前的進程實例並沒有被關閉，但是他被終止服務等待的請求。
IIS6.0處理模型
IIS6是Windows2003系統默認的。在IIS5處理模型的上他有幾個改變和改進。其中之一最大改變就是應用程序池概念。在IIS5系列應用程序上，即所有的appDomains—運行在ASP.Net工作進程上。為了在安全以及特性上完成一個出色的界定，IIS6處理模型允許應用程序運行在同一個工作進程的不同拷貝上。每個應用程序池能夠包含多個appdomains(運行在單獨一個工作進程拷貝上).換而言之，這個變化是從單一進程運行所有程序到多個進程運行每一個應用池。這個模型也叫做工作過程隔離模式。
例外一個大變化相對先前的模型在IIS監聽所有傳入數據方面。在IIS5裡，由IIS進程,inetinfo.exe監聽指定的TCP端口。在IIS6中，傳入請求被處理並隊列在核心級別來替換先前通過核心驅動調用http.sys的用戶模式;這種方法有幾個優勢相對於先前的模式被叫作 kernel-level 請求隊列。
圖表3 IIS6處理模型
圖表3主要由請求處理組成。一旦一個請求到達核心級別設備驅動http.sys，然後發送到相應的應用程序池隊列，每個隊列屬於一個指定的應用程序池。
工作進程負責加載ASP.Net ISAPI擴展，依次加載 CRL 委派所有工作到HTTP運行時。
W3WP.exe進程與IIS5下面的aspnet_wp.exe不同，他不是ASP.Net特有的，能夠用來處理任何類型的請求。什麼樣的ISAPI模塊被加載類型根據需要的服務資源類型。
