MVC之前的那點事兒系列，是筆者在2012年初閱讀MVC3源碼的時候整理的，主要講述的是從HTTP請求道進入MVCHandler之前的內容，包括了原創，翻譯，轉載，整理等各類型文章，當然也參考了博客園多位大牛的文章，對此表示感謝，這次有時間貼出來，希望對大家有用。
主要內容
本文講解的是：服務器接受Http Request請求之後，是如何進入.Net CLR，從而進一步操作的。
我們大家都知道，IIS必須先接受請求，然後才能有機會進入CLR，但對請求(request)是怎麼從Web服務器傳送到ASP.NET運行時的卻不甚了解。IIS由於版本的不同，在進入CLR時候方式可能有所不同，本章節將就IIS5/6/7的三本版本的進入方式給予解釋，通過對這些底層機制的了解，可以讓我們對 ASP.net 有更深的理解。。
IIS 5 的 ASP.net 請求處理過程
IIS5核心特征是：IIS是允許在一個叫InetInfo.exe的進程上的，所以無論是aspx頁面還是html頁面都是通過這個進程處理的，其中，由於aspx頁面擴展名映射到了aspnet ISAPI.DLL上，所以如果頁面是aspx的話，aspnet ISAPI.DLL則創建aspnet_wp這個Worker Process，並在初始化的時候加載CLR，所以這是一個托管的環境。
需要注意的幾點是：
同一台服務器只能運行一個 aspnet_wp 進程，也就是說所有的ASP.NET Web Application都在同一個Worker Process 中，但是不意味著他們共享同一個context和數據庫， ASP.NET裡有個AppDomain的概念，每個站點或虛擬目錄都對應一個單獨的AppDomain，每個AppDomain是隔離的，有自己獨立的 context上下文，所以安全沒問題，所以我們的結論是：ASP.NET程序是繼續AppDomain的，而不是基於Process的。
ASP.NET ISAPI 不但負責創建 aspnet_wp Worker Process，而且負責監控該進程，如果檢測到 aspnet_wp 的 Performance 降低到某個設定的下限，ASP.NET ISAPI 將結束掉該進程，在Request來了以後，ASP.NET ISAPI 將重新創建新的 aspnet_wp Worker Process。
由於 IIS 和 Application 運行在他們各自的進程中，他們之間的通信必須采用特定的通信機制。由於之間的通信是同機器不同進程的通信（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 的變量。
IIS 6 的 ASP.net 請求處理過程
