在寫本系列文章的過程中，我遇到了很大的困惑：在我准備講述問題A的時候，我發現需要先解釋問題B;當我考慮如何講解問題B的時候，又發現如果對問題C不夠清楚，很難較好地理解問題B。好吧，事已至此，我決定從問題C開始著手。不幸的是… 我已經跑題了。
本系列文章原計劃分成十個部分講述Asp.Net構架、安全機制 和 Provider模型，然而在寫作的過程中，我發現由於涉及的知識面太廣，Provider 模型在本系列文章中的地位已經大大降低了。與此同時，我認識到想用十個Part講述清楚ASP.Net的構架與安全機制是不可能的，但我仍會嘗試用最少的文字講述最多的內容。
閱讀的過程中，你可能會覺得文中有的內容看上去與正在討論的內容關系不大，這時候請你耐心地讀下去，它往往是你理解後面問題的關鍵。
在開始閱讀這一系列文章之前，請注意以下幾點：
·本系列文章文會詳細講述 Form驗證，粗略講述Windows驗證，不講述 Passport驗證。
·有時候我會采用自頂向下的方式講述，另一些時候我會采用自底向上的方式講述，這一切視需要而定。
·盡管我很不願意在段落之中插入過多的灰色說明文字，但是很多地方不如此很難講述清楚，我會在所有Part全部發布完後對本系列文章進行修訂。
·我們經常提到或者聽到三層式開發，也不斷在網上搜尋三層式開發的源碼來研究。實際上，等你了解了Provider模型後，就會發現最近的三層構架其實就在身邊。希望能認真學習Provider模型並思考其實用價值。
·文章中的插圖是在 IIS 6.0 和 Windows Server2003 下截取的，如果與 IIS 5.0的區別大到足以產生誤導，請反饋給我。
·由於本系列文章涉及的知識點比較多，而我又采用寫一個Part發布一個的方式。所以，很可能寫Part.4時候才發現Part.3很多地方沒有講清楚，這時候我會停下來重新修改Part.3;我也可能在寫Part.5的時候發現Part.1的一些內容挪到Part.2更合適。 請原諒我在做這些改動的時候不再另行通知。
這將是一次漫長的旅途，如果你現在已經整裝待發，那我們就上路吧!
引言
我查閱過不少Asp.Net的書籍，發現大多數作者都是站在一個比較高的層次上講解ASP.Net。他們耐心、細致地告訴你如何一步步拖放控件、設置控件屬性、編寫CodeBehind代碼，以實現某個特定的功能。
這種做法，實際上是回答了“如何去做”的問題，卻沒有回答“為什麼可以這樣做”的問題。
盡管我很推崇 悉江華 先生的《聖殿祭祀的ASP.Net開發詳解》一書，但當我翻看了一下其對角色(Role) 和 用戶(Member)的講解時，我決定跳過去直接讀後面的章節。因為我發現他也隨了大流，對這部分的講解停留在“如何去做”的層面上。我相信像悉先生 這樣的牛人是不可能不了解底層運作原理的，僅僅是因為那本書原本就已經很厚了吧。
當你按“如何去做”所講解的內容去開發程序的時候，對於你的用戶，你仍是一名程序員;但對於實現了MembershipProvider 和 RoleProvider 抽象類的微軟開發人員來說，你已經成了他們的一個用戶。
NOTE：我既不反對一些作者只講解“如何去做”，也不反對你只學“如何去做”，這樣也有它的好處，就是可以快速開發。我只是建議多掌握一點底層知識，對一些問題會有更好的理解。
希望通過這一系列文章的講解，可以讓你更好的理解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 聽上去還挺氣派，也算是“應用程序”呢，但仔細看看它的全稱就明白了：它實際上只是一個接口，起到一個代理的作用，它的主要工作是映射所請求的頁面(文件) 和與此後綴名相對應的實際的處理程序。
讓我們更進一步地看一下 ISAPI ，看看它到底是什麼樣子，請按下面的步驟進行：
1. 打開IIS。
2. 選擇隨意一個站點，鼠標右鍵，“屬性”。
3. 選擇“主目錄”選項卡。
4. 選擇“配置”。
你應該會看到如下的畫面：
圖1. 應用程序配置
很清楚地就可以看到，所有IIS所能處理，或者叫 ISAPI 所提供代理服務的 文件類型 及其相對應的實際的後台處理程序都在這裡清楚地列出來了。
我們找到 .ASPx 的應用處理程序，然後點“編輯”，會出現下面的畫面：
圖2. 編輯.ASPx文件的處理程序
一路看到這裡，可以看出，所有的.aspx文件實際上都是由 aspnet_isapi.dll 這個程序來處理的，當IIS把對於.aspx頁面的請求提交給了ASPnet_isapi.dll以後，它就不再關心這個請求隨後是如何處理的了。
這裡需要注意兩點：
1、當你修改“限制為”後，可以限制頁面(文件)只能以某種特定方式訪問。
2、“確認文件是否存在”是實現 URL 地址映射的關鍵選項，我以後會專門講述。
理解宿主環境(Hosting)
從本質上講，Asp.Net 主要是由一系列的類組成，這些類的主要目的就是將Http請求轉變為對客戶端的響應。HttpRuntime類是Asp.Net的一個主要入口，它有一個稱作 ProcessRequest 的方法，這個方法以一個 HttpWorkerRequest 類作為參數。HttpRuntime 類幾乎包含著關於單個 Http請求的所有信息：所請求的文件、服務器端變量、QueryString、Http 頭信息 等等。ASP.Net 使用這些信息來加載、運行正確的文件，並且將這個請求轉換到輸出流中，一般來說，也就是Html頁面。
NOTE：二般來說，也可以是張圖片。
當 Web.config文件的內容發生改變 或者 .ASPx文件發生變動的時候，為了能夠卸載運行在同一個進程中的應用程序(NOTE：卸載也是為了重新加載)，Http請求被分放在相互隔離的應用程序域中。
NOTE：可能你以前就聽過應用程序域，但是不了解怎麼回事，應用程序域就是 AppDomain。
對於IIS來說，它依賴一個叫做 HTTP.SYS 的內置驅動程序來監聽來自外部的 HTTP請求。在操作系統啟動的時候，IIS首先在HTTP.SYS中注冊自己的虛擬路徑。
NOTE：實際上相當於告訴HTTP.SYS哪些URL是可以訪問的，哪些是不可以訪問的。舉個簡單的例子：為什麼你訪問不存在的文件會出現 404 錯誤呢?就是在這一步確定的。
如果請求的是一個可訪問的URL，HTTP.SYS會將這個請求交給 IIS 工作者進程。
NOTE：IIS6.0中叫做 w3wq.exe，IIS5.0中叫做 ASPnet_wp.exe。
每個工作者進程都有一個身份標識 以及 一系列的可選性能參數。
NOTE：可選性能參數，是指諸如 回收機制的設置、超時時間設置 等等。
接下來進行的事情就是上一章節講述的 ISAPI 了。
NOTE：這部分的內容相關性比較強，為了讓大家好理解，我最後還是決定把 ISAPI 放到前面了，可能全系列完成的時候會再調整吧。
除了映射文件與其對應的處理程序以外，ISAPI 還需要做一些其他的工作：
1. 從HTTP.SYS中獲取當前的Httq請求信息，並且將這些信息保存到 HttpWorkerRequest 類中。
2. 在相互隔離的應用程序域AppDomain中加載HttpRuntime。
3. 調用 HttpRuntime的ProcessRequest方法。
接下來才是程序員通常編寫的代碼所完成的工作了，然後，IIS 接收返回的數據流，並重新返還給 HTTP.SYS，最後，HTTP.SYS 再將這些數據返回給客戶端浏覽器。
OK，現在你看到張子陽的空間主頁了。
圖3.ASP.Net 的宿主環境
理解管道(Pipeline)
在前面兩章中，我們在一個相對比較低的層次上討論了從發出Http請求到看到浏覽器輸出這轉瞬即逝的十分之一秒內IIS和 Framework 所做的事情。但是我們忽略了一個細節：程序員編寫的代碼是如何在這一過程中銜接的，本章我們就來看看這個問題。
當Http請求進入 ASP.Net Runtime以後，它的管道由托管模塊(NOTE：Managed Modules)和處理器(NOTE：Handlers，這可不是CPU)組成，並且由管道來處理這個 Http請求。
圖4. 理解 Http 管道
我們按編號來看一下這幅圖中的數據是如何流動的。
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構架與安全機制》系列文章的第一篇。
我首先概要介紹了這系列文章將要為大家講述的主題。然後，我提出了部分程序員存在的一個問題：在一個比較高的層次上學習和使用ASP.Net。
隨後，我以一個訪問我個人空間首頁的例子，引出了本文主要講述的三個內容：
1. Http請求剛剛到達時IIS時，IIS 所做的工作。
2. Http請求的宿主環境。
3. Http管道。
希望這篇文章能給你帶來幫助。
