ASP.NET構架與安全機制
本文講述ASP.NET構架與安全機制和Provider模型，然而在寫作的過程中，我發現由于涉及的知識面太廣，Provider 模型在本文章中的地位已經大大降低了。與此同時，我認識到想用十個Part講述清楚ASP.NET構架與安全機制是不可能的，但我仍會嘗試用最少的文字講述最多的內容。
希望通過這一系列文章的講解，可以讓你更好的理解ASP.NET構架與安全機制。
Http請求處理流程概述
思考“為什么在地址欄輸入www.tracefact.net就可以看到張子陽的個人空間?”，類似于思考“為什么蘋果是往地上掉不是往天上飄?”。對于普通訪問者來說，這就像每天太陽東邊升起西邊落下一樣是理所當然的;對于很多程序員來說，認為這個與己無關，不過是系統管理員或者網管員的責任。畢竟，IIS是 Windows 的一個組件，又不是 ASP.NET 的一個組成部分。而實際上，從你輕拍回車到頁面呈現在你眼前的十分之一秒內，IIS和.Net Framework已經做了大量的幕后工作。
你可能覺得了解這些幕后工作是如何運作的無關緊要，作為程序員的你只要保證開發出的程序可以高效地運行就可以了。然而，在開發過程中，你卻發現常常需要使用諸如 HttpContext 這樣的類。這個時候，你可曾思考過這些類的構成和類的實體是如何創建的?你可能簡單地回答：HttpContext代表當前請求的一個上下文環境。可你又知道IIS 、Framework、ASP.NET 是如何協同工作處理每個Http請求、如何區分不同的請求、IIS、Framework、ASP.NET三者之間的數據如何流動么?
回答上面這些問題，首先需要了解IIS是如何處理頁面請求的，這也是理解 Form驗證模式和Windows 驗證模式 的基礎。
Http請求剛剛到達服務器的時候
當服務器接收到一個 Http請求的時候，IIS 首先需要決定如何去處理這個請求(NOTE：服務器處理一個.htm頁面和一個.aspx頁面肯定是不一樣的么)。那IIS依據什么去處理呢?―― 根據文件的后綴名。
服務器獲取所請求的頁面(NOTE：也可以是文件，比如 jimmy.jpg)的后綴名以后，接下來會在服務器端尋找可以處理這類后綴名的應用程序，如果IIS找不到可以處理此類文件的應用程序，并且這個文件也沒有受到服務器端的保護(NOTE：一個受保護的例子就是 App_Code中的文件，一個不受保護的例子就是你的js腳本)，那么IIS將直接把這個文件返還給客戶端。
能夠處理各種后綴名的應用程序，通常被稱為 ISAPI 應用程序(NOTE：Internet Server Application Programe Interface，互聯網服務器應用程序接口)。雖然這 ISAPI 聽上去還挺氣派，也算是“應用程序”呢，但仔細看看它的全稱就明白了：它實際上只是一個接口，起到一個代理的作用，它的主要工作是映射所請求的頁面(文件) 和與此后綴名相對應的實際的處理程序。
1. HttpRuntime將Http請求轉交給 HttpApplication，HttpApplication代表著程序員創建的Web應用程序。HttpApplication創建針對此Http 請求的 HttpContext對象，這些對象包含了關于此請求的諸多其他對象，主要是HttpRequest、HttpResponse、 HttpSessionState等。這些對象在程序中可以通過Page類或者Context類進行訪問。
2. 接下來Http請求通過一些Module，這些Module可以做一些執行某個實際工作前的事情。
3. 在這一步，執行實際的一些操作，通常也就是.aspx頁面所完成的業務邏輯。
4. Http請求再一次回到Module，此時Module可以做一些某個工作已經完成了之后的事情。
NOTE：注意我用紅色標識的字，然后回想一下：ASP.NET 中是不是有眾多的 Inserting 、Inserted 之類成對的事件?其實，這里講述的就是為什么ASP.NET可以將一個Insert操作分成前后兩部分，然后再分別進行事件攔截的幕后原理。
總結
我首先概要介紹了這系列文章將要為大家講述的主題。然后，我提出了部分程序員存在的一個問題：在一個比較高的層次上學習和使用ASP.NET構架與安全機制。
隨后，我以一個訪問我個人空間首頁的例子，引出了本文主要講述的三個內容：
1. Http請求剛剛到達時IIS時，IIS 所做的工作。
2. Http請求的宿主環境。
3. Http管道。
【編輯推薦】
