IIS與ASP.NET 通訊機制深度剖析

IIS5.X缺點：

• ISAPI 動態鏈接庫被加載到InetInfo.exe 進程中，它和工做進程之間是一種典型的跨進程通訊方式，儘管採用命名管道，可是仍然會帶來性能的瓶頸。
• 全部的 ASP.NET 應用運行在相同進程（aspnet_wp.exe）中的不一樣的應用程序域中，基於應用程序域的隔離不能從根本上解決一個應用程序對另外一個程序的影響。在更多的時
  候，咱們須要不一樣的Web 應用運行在不一樣的進程中。

IIS6.X:

爲了解決第一個問題，IIS 6.0 將ISAPI 動態鏈接庫直接加載到工做進程中；爲了解決第二個問題，引入了應用程序池（Application Pool）的機制。

除了上面兩點改進以外，IIS 6.0 還有其餘一些值得稱道的地方。其中最重要的一點就是建立了一個名爲HTTP.SYS 的HTTP 監聽器。HTTP.SYS 以驅動程序的形式運行在Windows的內核模式（Kernel Mode）下，它是Windows 2003 的TCP/IP 網絡子系統的一部分，從結構上看它屬於TCP 之上的一個網絡驅動程序。

HTTP.SYS 可以帶來以下的好處

• 持續監聽：因爲HTTP.SYS 是一個網絡驅動程序，始終處於運行狀態，對於用戶的HTTP請求可以及時做出反應。
• 更好的穩定性：HTTP.SYS 運行在操做系統內核模式下，並不執行任何用戶代碼，因此其自己不會受到Web 應用、工做進程和IIS 進程的影響。
•  內核模式下數據緩存：若是某個資源被頻繁請求，HTTP.SYS 會把響應的內容進行緩存，緩存的內容能夠直接響應後續的請求。因爲這是基於內核模式的緩存，不存在內核模式和用戶模式的切換，響應速度將獲得極大的改進。

IIS6.0缺點：

• 相同操做的重複執行：IIS 與ASP.NET 之間具備一些重複的操做，好比身份驗證。
•  動 態文件與靜態文件處理的不一致： 由於只有基於ASP.NET 動態文件（ 好比.aspx、.asmx、.svc 等）的HTTP 請求才能經過ASP.NET ISAPI 進入ASP.NET 管道，而對於一些靜態文件（好比.html、.xml、.img 等）的請求則由IIS 直接響應，那麼ASP.NET管道中的一些功能將不能用於這些基於靜態文件的請求，好比咱們但願經過Forms 認證應用於基於圖片文件的請求就作不到。
•  IIS 難以擴展：對於IIS 的擴展基本上就體如今自定義ISAPI，可是對於大部分人來講，這不是一件容易的事情。由於ISAPI 是基於Win32 的非託管的API，並不是一種面向應用的編程接口。一般咱們但願的是諸如定義ASP.NET 的HttpModule 和HttpHandler 同樣，經過託管代碼的方式來擴展IIS。

 IIS7.0

IIS 7.0 大都將配置信息存放於XML 形式的配置文件中，基本的配置存放在applicationHost.config 中

7.0優勢：

• 容許經過本地代碼（Native Code）和託管代碼（Managed Code）兩種方式定義IIS Module，這些IIS Module 註冊到IIS 中造成一個通用的請求處理管道。由這些IIS Module 組成的
  這個管道可以處理全部的請求，不論請求基於怎樣的資源類型。好比，能夠將
  FormsAuthenticationModule 提供的Forms 認證應用到基於.aspx、CGI 和靜態文件的請求。
•  將 ASP.NET 提供的一些強大的功能應用到原來難以企及的地方，好比將ASP.NET 的URL 重寫功能置於身份驗證以前。
•  採用相同的方式去實現、配置、檢測和支持一些服務器特性（Feature），好比Module、Handler 映射、定製錯誤配置（Custom Error Configuration）等。