在使用过IIS服务器的过程中，我们来讲解下IIS服务器的知识。IIS服务器 5.x和IIS服务器 6.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。 对于Windows平台下的IIS来讲，ASP.NET无疑是一等公民，它们之间不应该是“井水不犯河水”的关系，而应该是“你中有我，我中有你”的关系。
为此，在IIS服务器 7.0中，实现了两者的集成。对于集成模式下的IIS服务器 7.0，我们获得如下的好处。
允许我们通过本地代码（Native Code）和托管代码（Managed Code）两种方式定义IIS Module，这些IIS Module注册到IIS中形成一个通用的请求处理管道。由这些IIS Module组成的这个管道能够处理所有的请求，不论请求基于怎样的资源类型。
比如，IIS服务器可以将FormsAuthenticationModule提供的Forms认证应用到基于.aspx，CGI和静态文件的请求。 将ASP.NET提供的一些强大的功能应用到原来难以企及的地方，比如将ASP.NET的URL重写功能置于身份验证之前。采用相同的方式去实现、配置、检测和支持一些服务器特性（Feature），比如Module、Handler映射、错误定制配置（Custom Error Configuration）等。
【编辑推荐】
