当一个客户端页面访问IIS试图获取一些信息的时候，发生了什么事情？一个请求在通过了HTTP管道后又发生了什么？本文主要是描述这两个过程，即IIS处理asp.net请求和asp.net的页面生命周期。欢迎大家积极拍砖，共同学习，共同进步。
首先我们要弄清楚两个非常重要的概念：
1， worker process(w3wp.exe). worker process管理所有的来自客户端的请求并给出响应。它是IIS下asp.net应用程序的核心。
2， application pool. 它是worker process的容器，IIS5及之前的IIS版本均没有application pool的概念。每一个application pool对应着一个worker process，在IIS Metabase中维护着Application Pool和worker process的Mapping。这就避免了IIS5中出现的worker process（IIS5中是aspnet_wp.exe，同一时间只能运行一个该进程)崩溃，application全崩溃的局面。
客户端向IIS发出一个资源请求后发生了如下事情：
1， server接受该请求
IIS6通过内核模式（Kernel mode）中的HTTP.SYS来分发各个Request到application pool。 这并不是随机的过程，在application pool创建的时候就已经注册到了HTTP.SYS,所以当请求来到时HTTP.SYS会直接发送到相应的application pool。 接下来在IIS的用户模式（User mode)中，Web Admin Services (WAS) 做了从HTTP.SYS中得到Request并分发到application pool的工作。application pool直接把request传递给worker process。
2， 请求传递到worker process后，worker process初始化加载ASP.NET ISAPI(Internet Server Application Program Interface)，ASP.NET ISAPI进而加载CLR创建托管环境。
(注：ISAPI只是一个接口，起到一个代理的作用，主要能力就是根据Request URL的后缀来寻找该后缀的处理程序）
ASP.NET ISAPI定义在aspnet_isapi.dll中，它本身运行在一个非托管的环境中。ASP.NET ISAPI开始一个HttpRuntime, HttpRuntime调用ProcessRequest方法来开始处理请求。ProcessRequest根据ISAPI传进来的iWRType 来创建不同的HttpWorkerRequest，从而屏蔽了不同IIS的差异。接下来ProcessRequest方法创建了HttpContext，我们使用HTTPContext.Current来访问它。在HttpRuntime使用HttpApplicationFactory创建了HttpApplication对象（IHttpHandler）以后，所有的请求都会在通过httpmodule后找到相应的Httphandler进行处理。在HttpApplicationFactory创建HttpApplication之前，会查找config（web.config和Machine.config）文件中注册的所有的HttpModule，并根据配置信息加载相应的Assembly，通过Reflection创建对应的HttpModule，并将这些Module加到HttpApplication 的_moduleCollection Filed中。我们对一个Application的请求最终会落到一个HttpApplication对象上。当一个请求到来时，ASP.NET会在Httplication Pool中查找未被使用的HttpApplication对象。
|
