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