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的寄宿模型有著非常大的區別，進入托管代碼的接口卻異常的相似-只有路由消息的過程有一點區別。
