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实际上就继承了 HttpApplication。我们在页面中使用的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> 看到预定义的http Module， 包括会话,验证等。