ASP.net對于編寫WEB應用程序以及組件來說是一個很好的框架，但是由于他的龐大性對于很多人來說要了解他的每一個細節好象是否不太可能，我一直認為有必要了解一下基層結構的工作原理以便在設計時獲取更高的性能，在接下來的一系列文章中，我將要描敘一下WEB的生命周期，從當請求被服務器接受開始，傳送到ASP.net管道處理一直到生成回送信息（如：HTML）在管道處理后期。

介紹

　　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擴展，以確認這種請求能被處理。

　　ISAPI擴展明顯需要符合一個通用接口，這樣他們才能被IIS調用并提供必要的數據用來處理請求和生成回送。

　　.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應用程序中的映射

Extension Resource Type
.asax ASP.NET 應用程序文件. 常用的有 global.asax.
.ascx ASP.NET 用戶控件文件.
.ashx HTTP handlers, the managed counterpart of ISAPI extensions.
.asmx ASP.NET web services.
.aspx ASP.NET web pages.
.axd ASP.NET internal HTTP handlers.

除了表格1所列出的文件擴展名，ASP.net ISAPI擴展也管理其他一些通常不提供給瀏覽器訪問的文件擴展類型，如Visual Studio工程文件，資源文件以及配置文件。

　　ASP.NET處理模型

　　到目前為止，我們已經明白當請求一個asp.net文件的請求傳到IIS后，他被轉遞到aspnet_isapi.dll,他是asp.net相關處理的主要入口點。實際上，這個擴展明顯依賴于系統上IIS的版本，因此處理模型是通過asp.net運行時通過有序的操作執行來處理請求并生成回送，也許有那么一點改變。