ASP.NET是一個非常強大的構建Web應用的平台，它提供了極大的靈活性和能力以致於可以用它來構建所有類型的Web應用。
絕大多數的人只熟悉高層的框架如： WebForms和 WebServices --這些都在ASP.NET層次結構在最高層。
這篇文章的資料收集整理自各種微軟公開的文檔，通過比較IIS5、IIS6、IIS7這三代IIS對請求的處理過程，讓我們熟悉ASP.NET的底層機制並對請求(request)是怎麼從Web服務器傳送到ASP.NET運行時有所了解。通過對底層機制的了解，可以讓我們對ASP.net有更深的理解。
IIS 5 的 ASP.net 請求處理過程
對圖的解釋：
IIS 5.x一個顯著的特征就是Web Server和真正的ASP.NET Application的分離。作為Web Server的IIS運行在一個名為InetInfo.exe的進程上，InetInfo.exe是一個Native Executive，並不是一個托管的程序，而我們真正的ASP.NET Application則是運行在一個叫做aspnet_wp的 Worker Process上面，在該進程初始化的時候會加載CLR，所以這是一個托管的環境。
ISAPI：指能夠處理各種後綴名的應用程序。 ISAPI是下面單詞的簡寫：Internet Server Application Programe Interface，互聯網服務器應用程序接口。
IIS 5 模式的特點：
1、首先，同一台主機上在同一時間只能運行一個aspnet_wp進程，每個基於虛擬目錄的ASP.NET Application對應一個Application Domain ，也就是說每個Application都運行在同一個Worker Process中，Application之間的隔離是基於Application Domain的，而不是基於Process的。
2、其次，ASP.NET ISAPI不但負責創建aspnet_wp Worker Process，而且負責監控該進程，如果檢測到aspnet_wp的 Performance降低到某個設定的下限，ASP.NET ISAPI會負責結束掉該進程。當aspnet_wp結束掉之後，後續的Request會導致ASP.NET ISAPI重新創建新的aspnet_wp Worker Process。
3、最後，由於IIS和 Application運行在他們各自的進程中，他們之間的通信必須采用特定的通信機制。本質上IIS所在的InetInfo進程和Worker Process之間的通信是同一台機器不同進程的通信(local interprocess communications)，處於Performance的考慮，他們之間采用基於Named pipe的通信機制。ASP.NET ISAPI和Worker Process之間的通信通過他們之間的一組Pipe實現。同樣處於Performance的原因，ASP.NET ISAPI通過異步的方式將Request傳到Worker Process並獲得Response，但是Worker Process則是通過同步的方式向ASP.NET ISAPI獲得一些基於Server的變量。
IIS6 的 ASP.net 請求處理過程
