IIS 5 的ASP 请求处理过程
对图的解释：
IIS 5.x 一个显著的特征就是Web Server 和真正的ASP.NET Application 的分离。作为Web Server
的进程上， 是一个Native Executive，并不是一个托管的程序，而我们真正的ASP.NET Application aspnet_wp 的Worker Process 上面，在该进程初始化的时候会加载CLR，所以这是一个托管的环境。
IIS6 的ASP 请求处理过程
对图的解释：
IIS 5.x 是通过 监听Request 并把Request分发到Work Process。换句话说，在IIS 5.x中对
Mode中进行，在IIS 6中，这种工作被移植到kernel Mode中进行，所有的这一切都是通过一个新的组件：
注：为了避免用户应用程序访问或者修改关键的操作系统数据，windows提供了两种处理器访问模式：
用户模式（User Mode）和内核模式（Kernel Mode）。一般地，用户程序运行在User mode下，而操作系统代码运行在Kernel Mode下。Kernel Mode的代码允许访问所有系统内存和所有CPU指令。
在User Mode下，http.sys接收到一个基于aspx 的http request，然后它会根据IIS中的Metabase 查看该基于该Request 的Application 属于哪个Application Pool，如果该Application Pool不存在，则创建之。否则直接将request 发到对应Application Pool 的Queue中。每个Application Pool 对应着一个Worker Process：，毫无疑问他是运行在User Mode下的。在IIS Metabase 中维护着Application Pool 和worker process的Mapping。WAS（Web Administrative service）根据这样一个mapping，将存在于某个Application Pool Queue的request 传递到对应的worker process(如果没有，就创建这样一个进程)。在worker process 初始化的时候，加载
ASP.NET ISAPI，ASP.NET ISAPI 进而加载CLR。最后的流程就和IIS 5.x一样了：通过AppManagerAppDomainFactory 的Create方法为Application 创建一个Application Domain；通过ISAPIRuntime 的ProcessRequest处理Request，进而将流程进入到ASP.NET Http Runtime Pipeline。
IIS 7的ASP 请求处理过程
IIS7 站点启动并处理请求的步骤如下图：
步骤1 到6 ，是处理应用启动，启动好后，以后就不需要再走这个步骤了。
上图的8个步骤分别如下：
1、当客户端浏览器开始HTTP 请求一个WEB 服务器的资源时，HTTP.sys 拦截到这个请求。
php的工作流程2、HTTP.sys contacts WAS to obtain information from the configuration store.
3、WAS 向配置存储中心请求配置信息。fig。
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、客户端接受到处理结果信息。
< 进程中又是如果处理得呢？？IIS 7 的应用程序池的托管管道模式分两种：经典和集成。这两种模式下处理策略各不相通。
本文作者：郭红俊blog.joycode/ghj
IIS 6 以及IIS7 经典模式的托管管道的架构
在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。下图是这个架构的示意图。
IIS7 应用程序池的托管管道模式经典模式也是这样的工作原理。这种模式是兼容IIS 6 的方式，以减少升级的成本。
IIS6 的执行架构图，以及IIS7应用程序池配置成经典模式的执行架构图
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 以建置网站或虚拟目录）。
IIS 7 的执行架构图（集成托管信道模式下的架构）
源文档 <blog.joycode/ghj/archive/2008/07/25/115200.aspx>