與 ASP.NET 1.0 相比，ASP.NET 2.0 的各方面改進可以說是非常巨大的。但就其實現層面來說，最大的增強莫過于提供了對異步頁面的支持。通過此機制，編寫良好的頁面可以將數據庫、WebService 調用等慢速操作，對網站吞吐能力的影響降到最低，并極大的改善網站的平均頁面響應速度。本文將從使用和實現兩個層面，簡單的剖析這一強大機制的原理，以便讀者能夠更好的應用這一機制。
      對一個網頁請求的生命周期來說，首先是 Web 服務器收到客戶端 HTTP 請求，將請求轉交給 ASP.NET 引擎；引擎將以流水線方式調用合適的 Web 應用程序和最終的頁面進行處理；頁面會根據請求內容，執行某些后臺操作，如訪問數據庫、調用遠程 WebService 等等；最終將結果以某種可視化形式，展示到最終用戶的瀏覽器中。
      而為了提高響應速度和吞吐量，現代的 Web 服務器往往會將 Web 應用程序和頁面，放在一個緩沖池中備用，避免每次處理請求時重建環境。而請求到來時，Web 服務器會從一個系統線程池中獲取臨時線程，調用從 Web 應用程序和頁面緩沖池中獲取的處理實例，完成對請求的處理，并最終返回處理的結果。
      咋一看這種機制非常完美，能夠最大限度的重用系統資源，但實際上其中存在著很大的優化余地。

      我們可以將一個頁面請求的處理過程進一步細化為下面步驟：

      1.Web 服務器接受請求并由引擎轉發請求
      2.頁面處理請求，訪問數據庫、調用遠程 WebService 等
      3.頁面將處理結果，以某種形式展現，如 HTML 表格等
      4.Web 服務器將結果返回給最終客戶的瀏覽器

      其中第一步涉及到核心態網絡驅動，需要頻繁切換回用戶態，以將請求轉交給處理引擎。這里涉及到大量的核心態和用戶態切換。為減少這個負擔，IIS 6 開始提供了 http.sys 在核心態直接對大多數請求進行處理。這是 MS 在中間件一級就已經替我們做好的優化，我們無需也無法關心。

      而另外一個潛在的優化點就是異步頁面的目標：增強頁面處理請求的并發性。
      Web  服務器在從線程池獲取臨時線程后，在線程中調用頁面相關代碼處理請求。而這里的請求處理過程往往涉及到較為緩慢的操作，例如訪問數據庫、調用遠程  WebService 等。如果數據庫是在本機的話還好，系統 CPU 時間只是從處理線程移交到后臺數據庫線程；而一旦處理運算邏輯在遠程，例如訪問外部獨立數據庫，或調用 WebService 完成某種操作，此時此線程就只能無謂的等待操作結束。而作為 Web 服務器處理客戶端請求的線程池，其最大容納線程的數量肯定是有限的。（雖然大多數情況下這個上限值可以修改，例如 ASP.NET 中可以通過修改 machine.config 的  processModel 標簽調整最大數量，缺省25）。一旦超過此數量的請求正在并行執行，或者說正在等待后臺慢速的操作，此時新來的請求就會因為處理請求線程池中無可用線程，出現雖然 CPU 負荷非常低，但仍出現 “503 服務器不可用” 類似的錯誤，從而事實上造成對應用的 DoS（拒絕服務）攻擊。即使此上限設置很大，也會因為大量等待操作，降低其它本可以快速的頁面的響應速度。

      要處理這種情況，雖然可以通過繼續增大請求處理線程池最大容量緩解，但總是治標不治本。更好的方法就是將請求處理和頁面處理分離，避免慢速頁面處理占用快速請求處理的時間。頁面在接受到引擎的處理頁面請求后，通過調用異步方法來試圖完成實際頁面處理，處理結果從單獨線程池獲取線程進行監控，而發送頁面請求的請求處理線程將被直接釋放，以便繼續處理其它的頁面請求。這也就是 ASP.NET 異步頁面的基本思路。實際上這個思路在 ASP.NET 1.1 時就已經提出， Fritz Onion 曾于 2003 年在 MSDN 雜志發表過一篇文章詳細討論這個問題，并給出了一個簡