前言
为什么我会起这样的一个标题，其实我原本只想了解asp.net的管道模型而已，但在查看资料的时候遇到不明白的地方又横向地查阅了其他相关的资料，而收获比当初预想的大了很多。
有本篇作基础，下面两篇就更好理解了：
目录
一般不写目录，感觉这次要写的东西有些多就写一个清晰一下吧。
1.Asp.net管道模型；
2.进程的子进程与进程的线程；
参考：ASP.NET使用管道模型（PipleLines）处理HTTP请求
管道模型中包含以下对象：
流程图：
Http Request传到工作进程（IIS5.x为aspnet_wp.exe，IIS6.x和IIS7.x为w3wp.exe）后，工作进程实例中通过ISAPIRuntime（主要作用是调用一些非托管代码生成HttpWorkerRequest对象，HttpWorkerRequest对象包含当前请求的所有信息，然后传递给HttpRuntime）传递HttpWorkerRequest对象给HttpRuntime并调用HttpRuntime的ProcessRequest方法，HttpRuntime为管道模型的入口此时正式进入管道模型。
HttpRuntime根据HttpWorkerRequest对象生成HttpContext，HttpContext包含request、response等属性, 再调用HttpApplicationFactory的GetApplicationInstance方法生成HttpApplication, HttpApplication对象包含多个HttpModule对象（当一个HTTP请求到达HttpModule时，整个ASP.NET Framework系统还并没有对这个HTTP请求做任何处理，也就是说此时对于HTTP请求来讲，HttpModule是一个HTTP请求的“必经之路”，所以可以在这个HTTP请求传递到真正的请求处理中心（HttpHandler）之前附加一些需要的信息在这个HTTP请求信息之上，或者针对截获的这个HTTP请求信息作一些额外的工作，或者在某些情况下干脆终止满足一些条件的HTTP请求，从而可以起到一个Filter过滤器的作用），并调用各个HttpModule对象的Init方法初始化HttpModule，在Init方法中可以订阅HttpApplication的事件从而作出相应的处理。当HttpApplication执行到Application_ResolveRequestCache时暂时将控制权交给HttpHandler并根据HttpHandler中是否启用SessionState来确定是否生成会话跟踪功能（.aspx中用enablesessionstate设置，.ashx中用是否继承IRequiresSessionState接口来设置），然后HttpApplication继续执行自身的事件直到执行完PreRequestHandlerExecute事件就根据URL请求的后缀名获取HttpHandlerFactory对象（默认情况下.aspx调用System.Web.UI.PageHandlerFactory,.ashx调用System.Web.UI.SimpleHandlerFactory），调用HttpHandlerFactory的GetHandler方法生成具体的HttpHandler对象或调用ReleaseHandler方法使工厂可以重用现有的处理程序实例来处理http请求并返回http响应，再经过HttpApplication对象的一系列事件（具体事件请参考HttpModule的认识(转载)）最终返回到客户端，当然http响应所经过的HttpApplication的一系列事件都可以被HttpModule对象所订阅。
参考：百度问答
我拿Windows举例子吧, 因为Linux的内核好像是没有线程概念的.进程和线程的区别在于粒度不同, 进程之间的变量(或者说是内存)是不能直接互相访问的, 而线程可以, 线程一定会依附在某一个进程上执行.我举个例子, 你在Windows下开一个IE浏览器, 这个IE浏览器是一个进程. 你用浏览器去打开一个pdf, IE就去调用Acrobat去打开, 这时Acrobat是一个独立的进程, 就是IE的子进程.而IE自己本身同时用同一个进程开了2个网页, 并且同时在跑两个网页上的脚本, 这两个网页的执行就是IE自己通过两个线程实现的.值得注意的是, 线程仍然是IE的内容, 而子进程Acrobat严格来说就不属于IE了, 是另外一个程序.之所以是IE的子进程, 只是受IE调用而启动的而已.
追问：那我可不可以这样理解，父进程创建了一个子进程，只要给这个子进程分配一定的任务，他们从此就没有关系了 。。。。
回答：也不能这么说从此就没关系了, 父进程还是可以通过和子进程通信来获得一些信息的. 拿上面的例子来说,
IE可以通过一些进程间通信的接口来知道Acrobat是否顺利的把pdf打开了之类的信息. 但有一点我觉得你的理解基本正确,
就是父进程和子进程是独立的. 假如IE开了一个病毒子进程, 子进程不听话, 父进程也没什么特别的办法, 除了向系统申请去关闭它之外.
区分子进程和线程很简单: 一个独立程序的运行称为一个进程, 在进程里并发执行的不同部分称为线程. 由这个进程引发的另外的独立程序运行为这个进程的子进程.(基本上就是这样, 更加严格的定义建议参考操作系统的教科书)
参考：.NET简谈组件程序设计之(AppDomain应用程序域)
参考：http://blog.csdn.net/zhoufoxcn/article/details/2425420中周公的回答
进程：属于操作系统上的概念，一个进程占有一个内存地址，是应用程序与应用程序之间的边界，进程之间不能共享代码和数据空间（也就是不能直接交互），但可以通过IPC（remoting、named pipe、webservice等）进行数据交互。一个进程出现错误甚至崩溃不会影响其他进程的执行。
子进程：由另一个进程启动，子进程与父进程没有从属关系，两进程可以通过IPC进行数据交互。
线程：属于操作系统上的概念，是代码执行堆栈和执行上下文的边界，同一进程的多个线程共享代码和数据空间，但只负责执行代码而没有携带数据的功能。独立或多个线程协同负责执行进程中的任务。
题外：对于线程其实还有很多方面可以深入，更多请参考《深入线程》
应用程序域（AppDomain）
参考：理解AppDomain
AppDomain是.net framework独有的概念，是逻辑宿主，其功能就像进程那样是程序运行的独立空间（从进程中分配独立的内存空间，AppDomain间不能共享代码和数据空间），当一个AppDomain中的程序出现异常甚至崩溃时不会影响到其他AppDomain中运行的程序。但AppDomain不是进程，一个进程可以拥有一个或多个AppDomain，其中必须有一个默认的AppDomain。
也许这里您会有这样的疑问：AppDomain是线程吗？如果不是那么与线程的关系是什么呢？在.net framework中存在进程、应用程序域（AppDomain）、线程三个独立又有联系的概念，一个进程含一个或多个AppDomain（必须存在一个默认AppDomain）；一个进程含一个或多个线程（通常含一个线程池，里面有多个可重用的线程）；AppDomain与线程是多对多关系，但某一个时刻一个线程只能处理一个AppDomain，而AppDomain可以由多个线程同时处理（并发）。
从运行程序时的过程是这样的：系统首先分配一段内存地址空间然后把控制权交给了CLR生成默认AppDomain，然后将程序集加载到默认AppDomain中，程序正式运行（系统在托管堆中没有AppDomain的概念，AppDomain不是操作系统的概念，由CLR管理）。默认AppDomain随CLR而生而亡，无法以编码方式删除或者卸载其中的程序集。
下面以图的形式描述进程、线程、AppDomain的位置关系。
AppDomain之间不能直接交互，可通过代理的方式进行数据交互（如果是进程就使用IPC）。（具体实现以后探讨！）
上图左边为IIS5.X WEB SERVER，右边为Asp.net Application的工作进程（worker process），Asp.net是以作为IIS组件的形式扩展IIS的。
当一个http request发送到IIS5.X时，IIS先把虚拟目录转变为物理目录，然后根据文件后缀名检查iis中的metabase文件检查文件扩展名与可执行代码（扩展程序）映射记录（如.aspx、.ashx等对应aspnet_isapi.dll），如果metabase文件中没有就再检查是否为不受服务器端保护的文件（受服务器端保护：App_Code文件夹下的文件；不受服务器端保护：css、js文件），如果都不存在则直接返回404HTTP状态码给客户端；（该查找循序可通过《理解并自定HttpHandler》）存在则iis的inetinfo.exe实例会调用相应的可执行代码（这里是aspnet_isapi.dll），aspnet_isapi.dll会通过一个命名管道（named pipe,一种简单的IPC——进程通信机制，具体内容请参考：《命名管道及延伸进程通信学习》）把从inetinfo.exe获取的request异步转发到Asp.net工作进程实例：aspnet_wp.exe，然后就进入管道模型。同时aspnet_isapi.dll通过named pipe监测工作进程的运行状况，如果工作进程性能低于某个值aspnet_isapi.exe就会杀死工作进程，当下一个请求传递过来时重新启动一个工作进程处理请求。而工作进程通过named pipe同步请求web server的信息（如调用Server对象获取服务器信息）。
图依然秉承着我很丑但很有用的原则，嘻嘻！！
aspnet_wp.exe的工作进程中含有一个线程池和一个默认AppDomain，当一个Request发送到工作进程后，工作进程会根据请求的虚拟目录的文件（一个虚拟目录对应一个Application）由默认AppDomain创建AppDomain并将该虚拟目录的程序集加载到AppDomain中（虚拟目录中可能不止一个程序集，而默认AppDomain会将整个虚拟目录下的所有程序集加载到AppDomain上），如果该虚拟目录的AppDomain已存在就直接使用该AppDomain，如果虚拟目录的程序集发生变化（包括web.config变化），就会新建一个AppDomain再将以变化的程序集加载到新的AppDomain中；这时从线程池获取空闲线程执行程序集（写一个网站发布成两个虚拟目录进行测试，可以看到执行http请求处理的线程不断地变化，两个虚拟目录会出现使用相同线程的情况）。程序集中的变量和状态均保存在所属的AppDomain的内存中，如HttpContext.Current.Items、Application等(Application对象其实就是一张HashTable，可以被多个线程（iis5.X）或多个Application实例（iis6.x）访问)，AppDomain之间不能直接访问对方的变量和状态。Session状态变量有三种模式InProc、StateServer和SQLServer，其中默认为InProc表示Session状态保存在Asp.net进程中，如果虚拟目录的程序集发生变化后在新AppDomain中调用之前所设置的Session状态变量就会发现Session丢失了（客户端的Cookie中保存的SessionID依旧，如果存在应该是可以读取的），表明Session模式为InProc时Session状态变量保存在对应的AppDomain中。
题外话：如果session模式设置为StateServer表示使用状态服务器保存Session状态，就是使用另外一个本地或远程进程来保存Session状态，本地开启状态服务器步骤（系统为Windows server类型）：1.开始->所有程序->管理工具->服务->开启 Asp.net状态服务，然后配置一下网站的web.config为<sessionState mode="StateServer" stateConnectionString="tcpip=localhost:4242"/>
IIS5.x、IIS6.x和IIS7.x的区别
参考：各版本IIS下ASP.net请求处理过程区别
IIS5.x设计为一个服务器只启用一个工作进程来处理所有请求/响应，为保证各个Application（以虚拟目录为单位）独立运行且不干扰其他Application（一个Application崩溃不导致整个进程崩溃），引入了AppDomain。但AppDomain效果差强人意，于是IIS6.x开始使用应用程序池（Application Pool）。在非Web Garden模式下一个Application对应一个应用程序池，对应一个工作进程，6.x开始工作进程从Aspnet_wp改为w3wp；在Web Garden模式下一个Application对应一个应用程序池，对应多个工作进程，Application可以在任意一个工作进程上执行，一旦其中一个工作进程崩溃也能及时处理该Application的请求，但在Web Garden模式下SessionState不能使用InProc模式，因为该模式会将SessionState保存在工作进程的AppDomain中。
IIS5.x中识别请求属于哪个Application是在工作进程中在用户模式下实现的，而IIS6.x是由Web Server的http.sys在核心模式实现的（IIS5.x的是Aspnet_isapi.dll，而IIS6.x开始使用了新组件http.sys）。注：为了避免用户应用程序访问或者修改关键的操作系统数据，windows提供了两种处理器访问模式：用户模式（User Mode）和内核模式（Kernel Mode）。一般地，用户程序运行在User mode下，而操作系统代码运行在Kernel Mode下。Kernel Mode的代码允许访问所有系统内存和所有CPU指令。
IIS5.x和IIS6.x的ASP.NET都是以IIS ISAPI extension的方式外加到IIS，而IIS7.x开始把Asp.net继承到IIS当中，并且IIS7.x工作模式有经典模式和集成模式两种，具体请看参考。
总结
本篇是参考了各位大哥的整理、总结后个人的一个归纳总结，以后继续完善！！
转载请标明出处哦！http://www.cnblogs.com/fsjohnhuang/archive/2012/07/12/2587658.html