ASP.NET底層架構探索之IE6的革新

asp.net|架構

　　IIS 5 和6以不同的方式工作

　　當一個請求來到時，IIS檢查指令碼映射(副檔名映射)然後把請求路由到aspnet_isapi.dll。這個DLL的操作和請求如何進入ASP.NET運行時在IIS5和6中是不同的。圖2顯示了這個流程的一個粗略概覽。

　　在IIS5中，aspnet_isapi.dll直接寄宿在inetinfo.exe進程中，如果你設定了Web網站或虛擬目錄的隔離度為中或高，則會寄宿在IIS單獨的(被隔離的)背景工作處理序中。當第一個ASP.NET請求來到，DLL(aspnet_isapi.dll)會開始另一個新進程aspnet_wp.exe並將請求路由到這個進程中來進行處理。這個進程依次載入並寄宿.NET運行時。每個轉寄到ISAPI DLL的請求都會通過具名管道調用被路由到這個進程來。

　　

　　圖2-從較高層次來看請求從IIS到ASP.NET運行時，並通過請求處理管道的流程。IIS5和IIS6通過不同的方式與ASP.NET互動，但是一旦請求來到ASP.NET管道，整個處理流程就是一樣的了。

　　不同於以前版本的伺服器，IIS6為ASP.NET做了全面的最佳化。

　　IIS6-應用程式集區萬歲

　　IIS6對處理模型做了意義重大的改變，IIS不再直接寄宿象ISAPI擴充這樣的外部可執行代碼。IIS總是建立一個獨立的背景工作執行緒-一個應用程式集區-所有的處理都發生在這個進程中，包括ISAPI dll的執行。應用程式集區是IIS6的一個很大的改進，因為它允許對指定線程中將會執行什麼代碼進行非常細粒度的控制。應用程式集區可以在每個虛擬路徑上或者整個Web網站上進行配置，這樣你可以將每個Web應用隔離到它們自己的進程中，這樣每個應用都將和其他運行在同一台機器上的Web應用完全隔離。如果一個進程崩潰了，不會影響到其他進程(至少在Web處理的觀點上來看是如此)。

　　不止如此，應用程式集區還是高度可配置的。你可以通過設定池的執行扮演層級(execution impersonation level )來配置它們的運行安全環境，這使你可以定製賦予一個Web應用的許可權(同樣，粒度非常的細)。對於ASP.NET的一個大的改進是，應用程式集區覆蓋了在machine.config檔案中大部分的ProcessModel節的設定。這一節的設定在IIS5中非常的難以管理，因為這些設定是全域的而且不能在應用程式的web.config檔案中被覆蓋。當運行IIS6是，ProcessModel相關的設定大部分都被忽略了，取而代之的是從應用程式集區中讀取。注意這裡說的是大部分-有些設定，如線程池的大小還有IO線程的設定還是從machine.config中讀取，因為它們線上程池的設定中沒有對應項。

　　因為應用程式集區是外部的可執行程式，這些可執行程式可以很容易的被監控和管理。IIS6提供了一系列的進行系統狀況檢查，重啟和逾時的選項，可以很方便的用來檢查甚至在許多情況下可以修正程式的問題。最後IIS6的應用程式集區並不像IIS5的隔離模式那樣依賴於COM+，這樣做一來可以提高效能，二來提高了穩定性(特別對某些內部需要調用COM組件的應用來說)

　　儘管IIS6的應用程式集區是單獨的EXE，但是它們對HTTP操作進行了高度的最佳化，它們直接和核心模式下的HTTP.SYS驅動程式進行通訊。收到的請求被直接路由給適當的應用程式集區。InetInfo基本上只是一個管理程式和一個佈建服務程式-大部分的互動實際上是直接在HTTP.SYS和應用程式集區之間發生，所有這些使IIS6成為了比IIS5更加的穩定和高效的環境。特別對靜態內容和ASP.NET程式來說這是千真萬確的。

　　一個IIS6應用程式集區對於ASP.NET有著天生的認識，ASP.NET可以在底層的API上和它進行互動，這允許直接存取HTTP緩衝API，這樣做可以將ASP.NET層級的緩衝直接下發到Web伺服器。

　　在IIS6中，ISAPI擴充在應用程式集區的背景工作處理序中運行。.NET運行時也在同一個進程中運行，所以ISAPI擴充和.NET運行時的通訊是發生在進程內的，這樣做相比IIS5使用的具名管道有著天生的效能優勢。雖然IIS的寄宿模型有著非常大的區別，進入Managed 程式碼的介面卻異常的相似-只有路由訊息的過程有一點區別。