深入解析 ASP.NET 內部機制（二）：HTTP 請求如何流向 ASP.NET 處理管線

上一篇我們探討了 http.sys 與 aspnet_filter 的角色，這次我們將目光投向請求通過這兩關後，IIS 如何決定將請求交給誰處理，以及 ASP.NET 內部啟動時經歷的初始化流程。

MIME 對應：IIS 的「分流站」

當請求通過 http.sys 與 aspnet_filter 後，尚未進入 ASP.NET 處理程序。此時 IIS 會查閱其 MIME 對應表（即「應用程式副檔名對應」），依副檔名決定由哪個 ISAPI 擴充或處理常式介入。圖示如下：

若為 .htm、.jpg 等靜態檔案，IIS 直接服務，請求不會進入 ASP.NET；若為 .aspx、.asmx 等動態副檔名，IIS 會將請求轉交 aspnet_isapi.dll，並啟動工作進程 w3wp.exe 載入該 DLL，隨後展開一系列初始化動作，最後將請求遞送給 ASP.NET 運行時。

從工作進程到應用程式域的啟動序列

1. 啟動 w3wp.exe：IIS 依應用程式集區設定啟動工作進程，載入 aspnet_isapi.dll。
2. 建立應用程式域：aspnet_isapi.dll 為 managed 組件，所有 managed 代碼必須在 AppDomain 中執行。ASP.NET 會為每個虛擬目錄（即一個 Web 應用程式）建立獨立的 AppDomain，確保隔離性。
3. 應用程式域建立的關鍵步驟：此過程涉及信任等級、程式碼存取安全性（CAS）、組件載入與編譯等核心機制，直接影響執行權限、安全性邊界與動態編譯行為，是理解 ASP.NET 運行時行為的基石。

掌握這段流程，不僅能釐清「為什麼靜態檔不經 ASP.NET」，更能在除錯權限、編譯、應用程式域卸載等疑難雜症時抓到關鍵線索。