从.Net类库代码来看Asp.net运行时

写在前面的话：网上讲Asp.net运行模式的好文章已经很多了，笔者本不用多此一举，另成一文。但从笔者自己的学习经验看，如果学到的这些知识不能对应到类库中的源代码，印象总归不够深刻，大有隔靴搔痒之感。只好自己写上一篇，对这方面的知识做个小小的总结。文中所有内容都是笔者在看了网上很多文章后，结合自己的开发经验得出的一些理解，难免有错误的地方，欢迎批评指出。另外，由于笔者能力所限，很多地方并未说透（真正对应到代码），也盼高手能够给予补充。

一.进入Asp.net运行时之前
虽然本文的重点是对托管代码的解析，但为了整个知识点的完整性，这里简单介绍一下IIS处理请求的一些基本情况。在一个IIS服务器上，你可以设置多个应用程序池（每个应用程序池可以单独设置允许使用的最大内存数量、CPU使用率、回收工作进程的时间间隔等参数，而且一个应用程序池里面只能使用一个版本的.NET Framework），然后把自己的Web应用分别部署到这些应用程序池中。在默认情况下，每个应用池会有一个工作进程w3wp.exe来维护（如果开通了Web园功能，也可以设置多个工作进程）。每个应用程序（虚拟目录）在池中都有自己的应用程序域，这些应用程序域都处于这个应用程序池的工作进程的进程空间内。
IIS是通过各种ISAPI的扩展来处理各种类型的应用的。当我们从客户端提交一个请求过来之后，IIS会根据请求的页面或者服务的类型，把请求映射到指定的ISAPI扩展。比方说，如果我们需要让IIS支持perl这样的服务器端程序（当然，这个移植工作早就有人做过了），我们就需要编写一个专门处理对perl页面进行的请求的ISAPI扩展。根据ISAPI的定义(符合这个定义的ISAPI扩展才能和IIS正常交互)，在你的扩展中可以包括ISAPI Extension和ISAPI Filter两大部分。ISAPI Extension是对请求的处理程序，完成和web服务器之间的输入输出；而ISAPI Filter则是一些回调接口，你可以通过实现这些接口来介入到整个请求处理的每一步骤，对Authentication，RevolveCache等环节进行控制。另外，ISAPI本身就是在工作进程里运行的，而asp.net运行时也是在工作进程里运行的，所以两者的交互非常有效率。
对于.aspx页面，这个扩展就是aspnet_isapi.dll。因为这些ISAPI都是非托管的Win32应用，直接对它们进行改动是比较困难的。所以，为了增强Asp.net运行时的可扩展性，aspnet_isapi.dll本身的功能非常少，我们可以把aspnet_isapi.dll简单理解为请求信息的路由器，负责把请求从IIS传送到asp.net运行时。而后面我们将要讲到的HttpHandle和HttpModule则分别担负起了ISAPI Extension和ISAPI Filter的功能，幸运的是，HttpHandle和HttpModule可以由纯的托管代码来实现。

二.从非托管代码到托管代码
前面说了，aspnet_isapi.dll是非托管代码，而asp.net运行时是托管代码，他们都运行在w3wp.exe工作进程里面，那么两者之间的调用点发生在什么地方呢？在介绍接下来的内容之前必须先介绍一个概念：ECB。ECB的全称是Extension Control Block，它是一个非托管资源包,具有对ISAPI接口完整的访问能力,包含了所有和一个传入请求有关的底层信息，如提交的标单中的数据等等。所以说，asp.net中的托管代码想要访问aspnet_isapi.dll对外提供的接口，就需要通过ECB。其实更准确的来说，是托管代码公布了一个IUnknown类型的接口供aspnet_isapi.dll调用，而aspnet_isapi.dll在调用的时候会把自己的ecb地址传进去。
明白了ECB的概念，下面我们要介绍一个接口和一个接口的实现类（位于System.Web.Hosting名字空间下），请读者注意笔者在代码中的注释（本文的主要目的就是和大家一起从代码实现的角度来认识整个Asp.net运行时，所以代码里的注释是笔者添加的关键性说明，后面的所有代码段都是这样）：
[ComImport, Guid("08a2c56f-7c16-41c1-a8be-432917a1a2d1"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
3public interface IISAPIRuntime
4
13public sealed class ISAPIRuntime : MarshalByRefObject, IISAPIRuntime, IRegisteredObject
15[return: MarshalAs(UnmanagedType.Interface)]
3public object Create(string module, string typeName, string appId, string appPath, string strUrlOfAppOrigin, int iZone)
4
9[return: MarshalAs(UnmanagedType.Interface)]
11public object Create(string appId, string appPath)
12public int ProcessRequest(IntPtr ecb, int iWRType)
3private void ProcessRequestInternal(HttpWorkerRequest wr)
7this.CreateEventExecutionSteps(EventBeginRequest, steps);
2this.CreateEventExecutionSteps(EventAuthenticateRequest, steps);
3this.CreateEventExecutionSteps(EventDefaultAuthentication, steps);
4this.CreateEventExecutionSteps(EventPostAuthenticateRequest, steps);
5this.CreateEventExecutionSteps(EventAuthorizeRequest, steps);
6this.CreateEventExecutionSteps(EventPostAuthorizeRequest, steps);
7this.CreateEventExecutionSteps(EventResolveRequestCache, steps);
8this.CreateEventExecutionSteps(EventPostResolveRequestCache, steps);
9steps.Add(new MapHandlerExecutionStep(this));
10this.CreateEventExecutionSteps(EventPostMapRequestHandler, steps);
11this.CreateEventExecutionSteps(EventAcquireRequestState, steps);
12this.CreateEventExecutionSteps(EventPostAcquireRequestState, steps);
13this.CreateEventExecutionSteps(EventPreRequestHandlerExecute, steps);
14steps.Add(new CallHandlerExecutionStep(this));//从这里，您可以很容易看到Handler对页面的解析处理在整个请求的处理的什么位置
15 //有哪些应用程序事件在它之前，哪些在它之后
16this.CreateEventExecutionSteps(EventPostRequestHandlerExecute, steps);
17this.CreateEventExecutionSteps(EventReleaseRequestState, steps);
18this.CreateEventExecutionSteps(EventPostReleaseRequestState, steps);
19steps.Add(new CallFilterExecutionStep(this));
20this.CreateEventExecutionSteps(EventUpdateRequestCache, steps);
21this.CreateEventExecutionSteps(EventPostUpdateRequestCache, steps);
22this._endRequestStepIndex = steps.Count;
23this.CreateEventExecutionSteps(EventEndRequest, steps);
24steps.Add(new NoopExecutionStep());
25this._execSteps = new IExecutionStep[steps.Count];
26steps.CopyTo(this._execSteps);//把整个数组拷贝给HttpApplication的私有变量_execSteps可以看到，对执行步骤数组的初始化有两种形式，一种是直接添加一个步骤：
steps.Add(new MapHandlerExecutionStep(this));
这种执行步骤是和事件无关的，只是在整个事件流中的特定位置执行一些特定的操作（实例化Handler之类的）。
而另一种是要把相关事件的处理方法列表添加到步骤中，每一个步骤其实是对一个事件的处理：
this.CreateEventExecutionSteps(EventBeginRequest, steps);
（8）执行步骤数组的执行。
其实在前文中已经提到过了，整个执行步骤数组的执行，是在HttpApplication.ResumeSteps()中调用的。恐怕就算不看这个方法的代码，大家也能想象得出，它是遍历整个执行步骤数组，然后调用其中每一项的Execute方法。这里大家大概也就清楚了，为什么会有一个执行步骤的概念。以笔者看来，首先它在概念上很好理解，完全贴合整个应用处理的管道模型pipeline；第二它屏蔽了引发事件的应用执行步骤和普通的内置执行步骤之间的差别；第三是比较容易在以后对整个流程进行改进和扩展。