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）等。