asp.net管道模型（管线模型）

　　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下一个HTTP请求/响应过程的总体框架　　　　　　　　　　　　　　　　　　

　　上图左边为IIS5.X WEB SERVER，右边为Asp.net Application的工做进程（worker process），Asp.net是以做为IIS组件的形式扩展IIS的。

　　参考：各版本IIS下ASP.net请求处理过程区别

　　当一个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/01/19/2327296.html