ASP.Net请求处理机制初步探索之旅 - Part 1 前奏(转)

    在读本文之前建议先阅读IIS架构：http://www.cnblogs.com/tiantianle/p/5079932.html

    不管是ASP.Net WebForm还是ASP.Net MVC在请求处理机制上大部分都是相同的，只是在请求处理管道上的处理事件做了不同的操作。因此，本文标题不区分ASP.Net WebForm和ASP.Net MVC，但在后续的介绍中会区分开来介绍。此外，本文以IIS经典模式为主，不讨论集成模式（IIS7后加入了集成模式，不用加载外部的aspnet_isapi.dll组件）。

一、当一个请求到来时HTTP.sys先进行了基本处理，然后转发给IIS的工作者进程。

假设请求是针对此网页所属的ASP.NET应用程序的第一次请求。

当请求到达Web服务器时，HTTP.SYS负责接收，根据请求的URL，HTTP.SYS将其传递给此ASP.NET应用程序所对应的应用程序池，由在此应用程序池中运行的工作者进程负责处理请求。

接下来主要看工作者进程做了什么。

二、判断是否动态资源

　　首先会判断请求的是否是静态资源，如果是则直接到文件系统中拿到请求的html/css/js/jpg/gif/png等资源直接响应请求。

如果是动态资源则先查找由哪个扩展来处理。静态还是动态由文件后缀名决定。

　　IIS本身不会处理动态资源请求，会由W3WP.exe所维护的工作者进程根据请求的资源类型(文件后缀名)到一个称为“处理程序映射”中去查找应该由哪个扩展程序来处理这个请求。在IIS中，对于asp.net的请求一般是由aspnet_isapi.dll这个组件来进行.net运行时的加载和具体请求的处理。现在我们应该知道：Asp.Net 只是服务器(IIS)的一个组成部分而已，它是一个 ISAPI扩展。

由于IIS服务器在设计时引入了开放的ISAPI接口标准，具备极高的可扩展性。在核心组件不变的情况下可灵活支持不同类型不同版本的ASP.NET应用程序。

关于ISAPI：

ISAPI(服务器应用编程接口)为开发人员提供了强大的可编程能力，只要按照标准接口开发不同类型的Web应用程序的ISAPI扩展程序，就能实现对IIS功能上的扩展，从而使IIS可以处理不同类型的客户端请求。IIS管理器提供了应用程序配置功能，可以对不同的客户端请求配置不同的ISAPI扩展程序。ISAPI扩展程序通常以DLL形式存在，可以被IIS加载并调用。

NET运行时的加载

　　如果Web应用程序是第一次加载，那么首先会由aspnet_isapi.dll加载.NET运行时（主要是调用服务器上的.Net Framework创建CLR运行时）。

工作者进程工作于非托管环境（指Windows操作系统本身）之中，而.NET中的对象则工作于托管环境（指CLR）之中，aspnet_isapi.dll起到了一个沟通两者的桥梁作用，将收到的HTTP请求（由非托管环境传来）转发给相应.NET对象（处于托管环境中）处理

加载CLR之后，由ApplicationManager类负责创建一个应用程序域。每个ASP.NET应用程序都运行于自己的应用程序域中，由唯一的应用程序标识符标识。每个应用程序域都对应着一个ApplicationManager类的实例，由它来负责管理运行在域中的ASP.NET应用程序（比如启动和停止一个ASP.NET应用程序，在指定的ASP.NET应用程序中创建对象等等）。

    关于应用程序域：

一个IIS工作进程所在的应用程序池可以承载多个应用程序域AppDomain。使用.NET建立的可执行程序并没有直接承载到进程当中而是承载到应用程序域（AppDomain）当中。应用程序域是.NET引入的一个新概念，它比进程所占用的资源要少，可以被看作是一个轻量级的进程。

创建好AppDomain之后，就将请求转给该AppDomain中的ISAPIRuntime对象，然后调用ISAPIRuntime对象的ProcessRequest()方法来进行处理。

　　ISAPIRuntme.ProcessRequest()方法是进入ASP.Net的第一个入口，ASP.Net的核心处理部分就刚刚开始。此篇我将其称为前奏，是因为它是在ASP.Net的核心处理部分之前，将HTTP请求一步一步地传递给了ISAPIRuntime对象，后面我们再继续探索ASP.Net的请求处理机制，今天就到此结束！