ASP.NET的底層的工作機制介紹

　　特別說明：翻譯此文的目的僅僅是為了給廣大的ASP.NET愛好者提供一些幫助，由於本人能力有限，文中不對地方，還請批評指正。如果你需要轉載，請你保留該文以及原英文的連結。多謝!

　　目錄

　　1. ASP.NET是什麼?

　　2.從瀏覽器到ASP.NET

　　3.ISAPI連線

　　4.IIS5和IIS6的不同之處

　　5.進入.NET執行時

　　6.載入.NET—稍微有點神祕

　　7.回到執行時

　　8.HttpRuntime，HttpContext以及HttpApplication

　　9.Web程式的主要部分：HttpApplication

　　10.穿過ASP.NET管道

　　11.HttpContext，HttpModules和HttpHandlers

　　12.HttpModules

　　13.HttpHandlers

　　14.是否已經提供了足夠的底層知識?

　　摘要：ASP.NET是一個用於構建Web程式的強大平臺，提供了巨大的彈性和能力以至於它可以構建任意的Web程式。許多人僅僅對處於ASP.NET高層次的框架如：WebForms和WebServices比較熟悉，因此，在這篇文章裡，我將會闡述有關ASP.NET比較底層的知識，並且將會解釋，如何將請求從Web Server移交給ASP.NET執行時，然後通過ASP.NET HTTP管道處理這些請求。

　　對於我來說，瞭解一個平臺的內部工作機制總是會讓我感到一些滿足和安慰，如同洞察，可以幫助我寫出更好的程式。知道了工具有什麼用途，以及它們如何組裝成複雜框架的一部分，這些將會使你很容易的找到問題的解決方案，以及在你修改和除錯錯誤時，都顯得非常重要。這篇文章的目的就是從底層瞭解ASP.NET以及幫助你理解請求如何流入ASP.NET處理管道里。同時，你將會了解ASP.NET引擎的核心，以及一個Web請求如何在這裡結束。這裡講到的許多知識都是你日常工作中沒必要知道的，但是，如果你理解了ASP.NET如何把請求路由到應用程式的程式碼裡(通常比較高層次的)，這將對你非常有用。

　　注：整個ASP.NET引擎完全構建在託管程式碼裡，其所有的擴充套件性都是通過託管程式碼去構建。

　　使用ASP.NET的大多數都比較熟悉WebForms和WebServices。這些高層次的實現，使得構建Web程式變得非常容易。ASP.NET被設計為驅動引擎，它把底層的介面提供給Web Server，為高層次Web應用程式的前端和末端提供了路由服務。WebForms和WebServices是建立在ASP.NET框架之上，有關HTTP處理的兩種最常用的方式。

　　其實，在較低的層次上，ASP.NET也提供了足夠多的靈活性。HTTP執行時和請求管道提供了同樣的能力，可以構建類似於WebForms和WebServices的實現，當然，這些已經使用.NET託管程式碼實現了。如果你需要構建一個自定義HTTP處理平臺，而這個平臺要比WebForms所處的層次低一點，那麼你就會用到所有這些類似的功能。

　　構建大多的Web介面，使用WebForms無疑是最容易的方法，但是，如果你想自定義一個內容處理器，或者需要對流入和流出的內容做特殊的處理，或者需要為一個應用程式定製一個應用伺服器介面，那麼使用這些低層次的處理或者模組將會得到更好的效能，以及可以在真正的請求處理中獲得更多的控制權。儘管那些高層次的實現，如：WebForms和WebServices已提供了類似的功能，但由於它們針對請求新增了太多的控制(導致效能下降)。所以你完全可以另闢佳境，在較低層次上處理這些請求。

　　ASP.NET是什麼?

　　讓我們從最簡單的定義開始，ASP.NET是什麼?我通常喜歡用如下語句來描述ASP.NET。

　　ASP.NET是完全使用託管程式碼處理Web請求的一個成熟引擎平臺。它不僅僅只是WebForms和WebServices。

　　ASP.NET是一個請求處理引擎。它獲取客戶端請求，然後通過它內建的管道，把請求傳到一個終點，在這個終點，開發者可以新增處理這個請求的邏輯程式碼。實際上這個引擎和HTTP或者Web Server是完全分開的。事實上，HTTP執行時是一個元件，你可以把它宿主在IIS之外的應用程式上。甚至完全可以和其它的服務組合在一起。例如，你可以把HTTP執行時宿主在Windows桌面應用程式裡(詳細的內容請檢視：http://www.west-wind.com/presentations/aspnetruntime/aspnetruntime.aspx)。

　　通過使用內建的管道路由請求，HTTP執行時提供了一套複雜的，但卻很優雅的機制。在處理請求的每一個層面都牽涉到許多物件，但大多數物件都可以通過派生或者事件介面來擴充套件。所以，此框架具有非常高的可擴充套件性。通過這一套機制，可以進入較低層次的介面如：快取，身份驗證，授權等是有可能的。你可以在處理請求之前或之後過濾內容，或者僅僅把匹配指定簽名的客戶端請求直接路由到你的程式碼裡或轉向其它的URL。針對同一件事情，可以通過不同的處理方法完成，而且實現程式碼都非常的直觀。除此之外，在容易開發和效能之間，HTTP執行時還提供了最佳的靈活性。

　　整個ASP.NET引擎完全構建在託管程式碼裡，所有的擴充套件性功能都是通過託管程式碼的擴充套件提供。對於功能強大的.NET框架而言，使用自己的東西，構建一個成熟的、高效能的引擎體系結構已經成為一個遺囑。儘管如此，但重要的是，ASP.NET給人印象最深的是高瞻遠矚的設計，這使得在其之上的工作變得非常容易，並且提供了幾乎可以鉤住請求處理當中任意部分的能力。

　　使用ASP.NET可以完成一些任務，之前這些任務是使用IIS上的ISAPI擴充套件和過濾來完成的。儘管還有一些限制，但與ASP相比，已經有了很大的進步。ISAPI是底層Win32樣式的API，僅它的介面就有1兆，這對於大型的程式開發是非常困難的。由於ISAPI是底層的介面，因此它的速度也是非常的快。但對於企業級的程式開發是相當的難於管理的。所以，在一定的時間內，ISAPI主要充當其它應用程式或平臺的橋介面。但是無論如何，ISAPI沒有被廢棄。事實上，微軟平臺上的ASP.NET和IIS的介面是通過宿主在.NET裡的ISAPI擴充套件來通訊的，然後直達ASP.NET執行時。ISAPI提供了與Web Server通訊的核心介面，然後ASP.NET使用非託管程式碼獲取請求以及對客戶端請求發出響應。ISAPI提供的內容經由公共物件類似於HttpRequest和HttpResponse，通過一個設計優良的、可訪問的介面，以託管物件的方式暴露非託管資料。

　　從瀏覽器到ASP.NET讓我們從一個典型的ASP.NET Web請求的生命週期的起點開始。使用者通過在瀏覽器中鍵入一個URL，點選一個超連結，提交一個HTML表單(一個post請求)，或者一個客戶端程式呼叫基於ASP.NET的WebService(通過ASP.NET提供服務)。在伺服器端，IIS5或者IIS6將會收到這個請求。ASP.NET的底層通過ISAPI擴充套件與IIS通訊，然後，通過ASP.NET，這個請求通常被路由到一個帶有.aspx副檔名的頁面。但是，這個處理過程如何工作，則完全依賴於HTTP處理器(handler)的執行。這個處理器將被安裝用於處理指定的擴充套件。在IIS中，.aspx經由“應用程式擴充套件”被對映到ASP.NET ISAPI的dll檔案：aspnet_isapi.dll。每一個觸發ASP.NET的請求，都必須經由一個已經註冊的，並且指向aspnet_isapi.dll的副檔名來標識。

　　注：ISAPI是自定義Web請求處理中第一個並且具有最高效能的IIS入口點。

　　依靠副檔名，ASP.NET把一個請求路由到一個恰當的處理器，該處理器則負責處理這個請求。舉個例子，WebServices的副檔名.asmx不會把一個請求路由到磁碟上的某一個頁面，而是會路由到在定義中附加了指定特性(WebMethodAttribute)的類，此特性會把它標識成一個Web Services的實現。許多其它的處理器將隨著ASP.NET一起被安裝。當然也可以定義你自己的處理器。在IIS裡所有的HttpHandler被對映並指向ASP.NET ISAPI擴充套件，並且這些HttpHandler也都在web.config裡配置，用於把請求路由到指定的HTTP處理器裡執行。每一個處理器都是一個.NET類，用於處理指定的擴充套件。而這些處理器可以處理簡單到只有幾行程式碼的Hello World，也可以處理複雜到類似ASP.NET的頁面以及執行WebService。就目前而言，僅僅需要理解擴充套件就是一種基本的對映機制，ASP.NET用它可以從ISAPI裡獲取一個請求，然後把請求路由到指定處理該請求的處理器中。