IIS5 IIS6 IIS7的ASP.net 请求处理过程比较(2)

　　IIS7站点启动并处理请求的步骤如下图：

　　步骤1 到6 ，是处理应用启动，启动好后，以后就不需要再走这个步骤了。

　　上图的8个步骤分别如下：

　　1、当客户端浏览器开始HTTP请求一个WEB服务器的资源时，HTTP.sys拦截到这个请求。

　　2、HTTP.sys contacts WAS to obtain information from the configuration store.

　　3、WAS向配置存储中心请求配置信息。applicationHost.config。

　　4、WWW服务接受到配置信息，配置信息指类似应用程序池配置信息，站点配置信息等等。

　　5、WWW服务使用配置信息去配置HTTP.sys处理策略。

　　6、WAS starts a worker process for the application pool to which the request was made.

　　7、The worker process processes the request and returns a response to HTTP.sys.

　　8、客户端接受到处理结果信息。

　　W3WP.exe进程中又是如果处理得呢?? IIS 7 的应用程序池的托管管道模式分两种：经典和集成。这两种模式下处理策略各不相通。

　　本文http://blog.joycode.com/ghj

　　在IIS7之前，ASP.NET是以IIS ISAPI extension的方式外加到IIS，其实包括ASP以及PHP，也都以相同的方式配置(PHP在 IIS采用了两种配置方式，除了IIS ISAPI extension的方式，也包括了CGI的方式，系统管理者能选择PHP程序的执行方式)，因此客户端对IIS的 HTTP请求会先经由IIS处理，然后IIS根据要求的内容类型，如果是HTML静态网页就由IIS自行处理，如果不是，就根据要求的内容类型，分派给各自的IIS ISAPI extension;如果要求的内容类型是ASP.NET，就分派给负责处理ASP.NET的 IIS ISAPI extension，也就是aspnet_isapi.dll。下图是这个架构的示意图。

　　IIS 7 应用程序池的托管管道模式经典模式也是这样的工作原理。这种模式是兼容IIS 6 的方式，以减少升级的成本。

　　IIS6的执行架构图，以及IIS7应用程序池配置成经典模式的执行架构图

　　而IIS 7 完全整合.NET之后，架构的处理顺序有了很大的不同(如下图)，最主要的原因就是ASP.NET从 IIS插件(ISAPI extension)的角色，进入了IIS核心，而且也能以ASP.NET模块负责处理IIS 7 的诸多类型要求。这些ASP.NET模块不只能处理ASP.NET网页程序，也能处理其他如ASP程序、PHP程序或静态HTML网页，也因为ASP.NET的诸多功能已经成为IIS 7 的一部份，因此ASP程序、PHP程序或静态HTML网页等类型的要求，也能使用像是Forms认证(Forms Authentication)或输出缓存(Output Cache)等ASP.NET 2.0的功能(但须修改IIS 7 的设定值)。也因为IIS 7 允许自行以ASP.NET API开发并加入模块，因此ASP.NET网页开发人员将更容易扩充IIS 7 和网站应用程序的功能，甚至能自行以.NET编写管理IIS 7 的程序(例如以程控IIS 7 以建置网站或虚拟目录)。

　　IIS5到 IIS6的改进，主要是HTTP.sys的改进。

　　IIS6到 IIS7的改进，主要是ISAPI的改进。、

　　来源：http://blog.joycode.com/ghj/archive/2008/07/25/115200.aspx