看了《了解ASP.NET底层架构.doc》这篇文章，在分析的过程当中，充分利用Reflector是必要的。因为通过它，你可以看到实际的代码（尽管不一定和源代码一模一样）。如果说文字是有二义性的，那么，代码是没有的，通过分析代码，你可以更容易理解文字表达的内容。
另外，附上一些个人认识：
1 几个名词解释：
A: XX工厂（Factory）：生成某个对象运用了工厂模式，负责生成（生产）对象任务的对象叫做工厂。工厂模式是一种构建模式，通过附件2你应该能够理解。
B: CLR寄宿(Host) ：不要被这个名词吓倒，其实没有什么，CLR寄宿，实际上就是在非托管应用程序中加载CLR。一个非托管应用程序（比如sql server2005）需要运行托管代码（比如C#写的存储过程），那么就需要在它的进程当中加载.NET运行时CLR，也就是说CLR要寄宿在运行sql server的进程当中。
其实，从生活中来看“寄宿”这个词也可以帮助你理解。假如你和你的家人住在一起，那我们不会说你寄宿在你家，如果哪天你来了一个远房亲戚住在你家，他就是寄宿在你家。对于一个托管程序，你用Dependency这个工具来看，你会发现，它的运行要依赖于MsCoree.dll，而对于一个非托管程序，则应该不会看到这个依赖(Dependency只能看到静态依赖关系)，因为寄宿CLR一般是通过LoadLibrary来动态加载的（这个我不敢肯定，但是我看了好几个.exe和.dll都没有，比如w3wp.exe,inetInfo.exe等）。
关于寄宿的细节，你可以参考《.NET框架程序设计》（修订版）中的1.3节《加载.net运行时》和20.2《CLR寄宿》。
C: 应用程序域（AppDomain）：应用程序域从逻辑上来说，它类似于进程，它是一个逻辑上的容器。“域”的概念，其实也就是一个范围的概念，就好像以前的跑马圈地，圈住一块地之后就说这是我的地域范围。从实现上来说，AppDomain也是System命名空间中的一个类，你可以通过Reflector看到这个类的信息。你也可以参考《.NET框架程序设计》（修订版）中的20.3《应用程序域》。
D: 容器(Container)：容器就是包含其它对象的对象。
E: 管道：以前对管道的理解是两个进程通过管道来进行通信，比如在IIS5中，inetinfo.exe通过“命名管道”将请求交给aspnet_wp.exe（之所以称为命名管道，是因为给这个管道起了一个随机的名字）。现在又出来了一个http 管道（http pipeline），但是这回却是在同一个进程（比如IIS6.0中w3wp.exe）里面，这是怎么回事？让我们来看看“管道”的本质，我们分析一下实际生活中的管道，我们看到管道具有下面两个特征：
a
b
是的，我们计算机中的术语和生活中的概念是相通的。我们这里说的HTTP管道，就是指Http Module，Http Handler这些对象。而在这些HTTP管道流过的东西是同一个对象，那就是Http Context对象。在Http Module，Http Handler这些对象中对Http Context对象的处理，不过是对Http Context对象中的内容进行改变（最大的改变就是给Response对象赋上内容），但是没有改变它的结构。
2 几个容易造成误解的概念：
A:Http Application和我们在页面中使用的Application对象：这两者是不同的。前者代表着我们整个应用程序，对于我们的每个请求，HttpApplicationFactory都会分配一个Http Application对象，这个对象将管理着这个对请求的处理逻辑，或者说它是事件调度中心，你可以看到我们的Global.asax实际上就继承了Http Application。我们在页面中使用的Application是一个状态的概念，它是HttpApplicationState的一个实例，并且是“嵌”在httpContext对象上的一个子对象。
B:.NET运行时和HTTP运行时：NET运行时即是CLR，它的核心是MsCorEE.dll。后者是HTTP RunTime，它是System.web中httpRuntime类的实例。HttpRuntime负责Http Application, Http Context的创建和初始化等工作。这两者是不同的。
C: Http Application， Http Context， Http Module，Http Handler
对于每个请求都被路由到一个HttpApplication对象上.HttpApplicationFactory类根据应用程序的负载为你的ASP.NET应用创建一个HttpApplication对象池并为每个请求分发HttpApplication对象的引用. 这里我再次强调，HttpApplication的主要职责是作为Http管道的事件控制器，httpApplication它本身对发送给应用程序的数据一无所知-它只是一个通过事件来通讯的消息对象.它触发事件并通过HttpContext对象来向被调用函数传递消息.实际的当前请求的状态数据由HttpContext对象维护。你可以用Reflector看一看HttpContext类，里面包含着Request,Response,Application,Server，Session等表示状态的对象。其实，HttpContext本身也表示一种状态，它还有两个很重要的属性，Current和Items，前者用来代表自己，后者是可以存储任何对象的集合，你不要小看后者，它真的非常有用。鉴于自己与Context曾经有过一段情史，我将在以后写篇blog详细介绍它。
httpModule,有人说是它是“监视器”，有人说是“过滤器”，他们都是从不同角度来看httpModule,所以都是对的。httpModule提供了对请求进入http Handler处理之前的预处理和经过http handler处理后的事后处理，既然可以预处理，当然可以实现拦截请求，不交给http handler去处理，实现“过滤”的功能。从另外一个角度上来说，一旦有请求到来，便会初始化httpModule（httpApplication中有负责初始化httpModule的InitModules()方法），当然也就意味着httpModule监视着请求（也就是“监视器”的来源），毕竟它是我们能够对请求进行处理的开始。需要说明一点的是，ASP.NET只是为我们提供了这个能力，你需要自己去添加事件代码来实现控制，比如你可以在Global.asax中的事件处理函数中添加代码，你也可以自己定义http module.在附件４《asp-net framework深度历险.pdf》你可以看到具体的实例。至于http Handler,我们的页面其实就是一个http Handler，你可以从System.Web.UI.Page类(我们所有页面的基类)的声明中看到它要实现IHttpHandler接口。你可以翻阅《．NET程序设计技术内幕》这本书的8.5《图形控件》看看自己定制实现http Handler的好处。
但是，我不同意在附件4《asp-net framework深度历险.pdf》中所说，认为请求是一个单线流式的经过Http ApplicationFactory->Http Application-> Http Module -> Http Handler ->…。从附件1《[翻译]了解ASP.NET底层架构.doc》的图6也可以看到，所有的处理起点是在最左边的ASP.NET开始，为什么呢？实际上Http Module和Http Handler都是“嵌”在Http Application上的，整个流程是由http Application进行调度的。从另外一个角度上来说，http Application的大部分功能都是由Http Module来实现的，这些Http Module实际上就是在http Application启动并参与处理请求时被实例化的类，你可以在web.config中ttp Module>
１《[翻译]了解ASP.NET底层架构.doc》：我可以毫不掩饰的向你表达我对这篇文章的喜爱，我就是反反复复看这篇文章，并且以这篇文章为中心，去看其它的资料，才把ASP.NET底层弄个明白的。
２ http://www.jdon.com/designpatterns/designpattern_factory.htm 《设计模式——工厂模式》：我在之前也没有接触过设计模式。但实际上，就如李建忠所说，看懂设计模式不难，但是要真正掌握设计模式，正确运用设计模式就难了。在ASP.NET底层架构中，多处用到工厂模式，看完这篇浅显易懂的介绍，你应该能够看懂工厂模式，这对于我们理解ASP.NET底层架构已经足够了。
3
5
6 http://msdn2.microsoft.com/en-us/library/ms227435.aspx：还有什么比MSDN更权威的呢