作者：Simone Busoli
日期：6.13.2007
ASP.NET的内部机制有时就象是舞台背后的魔术，给开发者提供一个高度抽象的层面，把注意力集中在应用程序的逻辑上，而不需要去处理Http协议的底层机制。ASP.NET建立在.NET框架上，从而大多是托管代码。现在，Web请求的入口被本地代码编写的Web服务器，所以往往需要一套通信机制。本篇文章准备描述托管代码与非托管代码之间的桥梁以及两者如何相互协作搭建起处理ASP.NET请求的环境。
请参见：ASP.NET Internals – IIS and the Process Model
简介
在这一系列的先前的文章中我们已经介绍了第一步，一个Web请求被Web服务器如何接收以及通过什么样的途径最终被标识为ASP.NET资源的请求。你已经看到了不同版本的IIS如何处理到来的ASP.NET请求，直到它们最终被分派到一个叫aspnet_isapi.dll的非托管Win32组件，它是Web服务器与托管ASP.NET之间的桥梁。
在这篇文章中我准备从上篇文章的基础上继续深入的讨论，并且开始研究托管部分的进程环境，也就是先前提到过的称之为黑箱的ASP.NET Http运行时环境。
注：ASP.NET运行时环境也常被称为ASP.NET管道，Http运行时管道，或两种说法的混合。
离开aspnet_isapi.dll进入托管世界
先前的文章中我已经解释了IIS5.0和6.0是怎样管理Asp.net请求的。不管它是怎样处理Worker Process的生成，管理和回收，请求的所有信息最后都交由aspnet_isapi.dll处理。
它是托管与非托管世界之间的桥梁，也是ASP.NET体系架构中正式文档最少的部分。
注：在我写这篇文章的时候IIS7.0刚刚在Longhorn Server Beta3和Go Live通行证一起发布。很多东西会在IIS7.0中改变，虽然以前的文章都是针对某个IIS的版本，但是以后的文章会着重介绍IIS7.0的改变及增强。
我们讨论的主题因为缺少现成的文档资料，所以我下面解释的也不一定正确，尤其是非托管体系架构那块。所幸的是我们对这个非正式主题的讨论是基于一些工具的，这些工具帮助我们理解框架的工作原理：
Lutz Roeder's .NET Reflector，静态分析及反编译.NET托管类的代码
Microsoft CLR Profiler，通过函数调用，内存分配，类实例及其他很多特征分析框架的动态行为
JetBrains dotTrace Profiler，一个商业的.NET应用程序剖析器，也可以得到限时的版本
Red Gate ANTS Profiler，另一个商业的.NET应用程序剖析器，也可以得到限时的版本
下图为译者添加：
回到托管与非托管世界间的桥梁，一旦CLR通过IIS6.0进程模块的ISAPI扩展或IIS5.0进程模块的Worker Process装载，ASP.NET ISAPI组件通过一系列包含于命名空间System.Web.Hosting的托管类调用一系列非托管COM接口，AppManagerAppDomainFactory 类和ISAPIRuntime类暴露了一些COM接口的方法。
注：CLR，公共语言运行时，代表所有.NET应用程序的执行环境。实际上它对运行时托管应用程序提供环境及服务。它被Win32进程宿主，而ASP.NET是框架CLR提供的其中一个宿主。特别地，在ASP.NET中ASP.NET Worker Process（IIS5.0对应aspnet_wp.exe，IIS6.0对应w3wp.exe）是宿主在CLR中的一个进程。
在深入研究这些类之间的交互之前，让我们先表面地看看请求是如何被处理的。我已经在前面介绍了两个类，因为处理请求的入口可粗略地分成两方面：
1、建立一个AppDomain，如果还没存在，将AppDomain委派给相应的请求定位的应用程序，它由AppManagerAppDomain类完成。
2、提交与处理请求，由ISAPIRuntime类完成。
尽管两方面都很重要，第一类由没有开发者介入期望发生的交互组成，它关心应用程序的ASP.NET Internals – IIS and the Process Model