ASP.NET的本质之IIS以及进程模式

　　到目前为止，我们已经明白当请求一个asp.net文件的请求传到IIS后，他被转递到aspnet_isapi.dll,他是asp.net相关处理的主要入口点。实际上，这个扩展明显依赖于系统上IIS的版本，因此处理模型是通过asp.net运行时通过有序的操作执行来处理请求并生成回送，也许有那么一点改变。

　　在IIS5.X，所有asp.net相关请求通过ISAPI扩展被分配到外部工作进程叫做aspnet_wp.exe.ISAPI扩展，在IIS进程(inetinfo.exe)中运行,再传递控制权连同所有关于当前传入请求的信息到aspnet_wp.exe。2个进程间的通信通过命名管道(众所周知IPC[内部进程通信]机制建立。ASP.NET工作进程执行ISAPI扩展的大部分任务。注意一下每个WEB应用程序的实质，以及与IIS下不同虚拟目录的通讯，他们在asp.net工作进程同一个进程的上下文中被执行。为了实现读取各自执行中上下文ASP.net引入了应用程序域的概念，缩写AppDomains.他们可以被认为是一个轻量级的进程。更多的将在后面介绍。

　　如果运行在IIS6上，aspnet_wp.exe进程没有被使用，选择一个更优的进程叫做w3wp.exe.同时，inetinfo.exe也不再用来传递HTTP请求到ISAPI扩展，尽管这样他还是保持为其他协议的请求提供服务。虽然IIS6能够运行在兼容模式下并且模拟之前的行为，但是相对于先前的IIS5处理模型有了很多的变化。相对早期最大改变，当处理模型运行在IIS5上，传入进来的请求以lower-kernel-level形式然后传递到正确的ISAPI扩展，从而避免在内部信息处理方面花费过多的操作。在下面的段落中，我们将进行更深入的研究。

　　IIS5.0 处理模型

　　在windows2000以及XP系统上这是默认的处理模型。如上所说他有IIS inetinfo.exe进程默认在TCP端口80监听传入的HTTP请求并且把他们推送进队列等待处理。如果请求类型是asp.net,处理将委托给asp.net isapi扩展 aspnet_isapi.dll.这样轮流通过命名管道与asp.net工作进程通信，最终工作进程处理并传递请求到asp.net HTTP运行时环境。图表2将具体描叙这个过程。

　　图表2：IIS5.0处理模型

　　图表2显示一个我们尚未提到过的元素—ASP.NET HTTP运行时环境。目前他并不是我们这编文章的主题，他将在接下来的文章中被解析。HTTP运行时可以被看作一个黑色盒子，所有ASP.NET指定处理在这里发生，所有的受管制代码运行场所，从HTTP运行时一直到httphandler最终处理请求并生成回送都在这里被处理。这里还涉及到asp.net管道或http运行时管道。

　　就这个模型有一个有趣的地方就是所有请求，一旦被ISAPI扩展处理，就被传递到asp.net工作进程。每次活动时间有且仅有一个进行实例，一个例外，后面讨论。因此所运行在IIS上的asp.net web应用程序实际上也运行在工作进程上。尽管如此，这并不意味着所有应用运行在同一个上下文上并共享他们所有的数据。值得一提，asp.net引入APPDomain概念，本质上是一种提供独立和安全边界的受管制轻量级进程。每个IIS虚拟目录在一个APPDomain里执行，他将自动加载到工作进程只要资源是属于第一次请求的应用程序。一旦appdomain被加载，换句话说，当前请求所有需要的程序集被加载到appdomain–实际上是传递到asp.net管道处理。若干appdomains能够这样运行在同样的进程中，当多个请求对于同样的appdomain能够在多个线程出来。尽管如此，一个线程并不属于一个appdomain，他能为多个不同的appdomians处理多个请求,但是同一个给定的时间一个线程属于一个APPdomain.

　　处于性能目的，工作线程能够根据一些标准(通过MACHINCE.CONFIG文件配置)被回收。这些标准包括进程生命周期，请求以及队列数量，空闲时间，内存分配。一旦达到这些参数中一项临界值，ISAPI扩展将生成一个新的工作进程实例用来处理请求。实际上，先前的进程实例并没有被关闭，但是他被终止服务等待的请求。

　　IIS6.0处理模型

　　IIS6是WINDOWS2003系统默认的。在IIS5处理模型的上他有几个改变和改进。其中之一最大改变就是应用程序池概念。在IIS5系列应用程序上，即所有的appDomains—运行在asp.net工作进程上。为了在安全以及特性上完成一个出色的界定，IIS6处理模型允许应用程序运行在同一个工作进程的不同拷贝上。每个应用程序池能够包含多个appdomains(运行在单独一个工作进程拷贝上).换而言之，这个变化是从单一进程运行所有程序到多个进程运行每一个应用池。这个模型也叫做工作过程隔离模式。

　　例外一个大变化相对先前的模型在IIS监听所有传入数据方面。在IIS5里，由IIS进程,inetinfo.exe监听指定的TCP端口。在IIS6中，传入请求被处理并队列在核心级别来替换先前通过核心驱动调用http.sys的用户模式;这种方法有几个优势相对于先前的模式被叫作 kernel-level 请求队列。

　　图表3 IIS6处理模型

　　图表3主要由请求处理组成。一旦一个请求到达核心级别设备驱动http.sys，然后发送到相应的应用程序池队列，每个队列属于一个指定的应用程序池。

　　工作进程负责加载asp.net ISAPI扩展，依次加载 CRL 委派所有工作到HTTP运行时。

　　W3WP.exe进程与IIS5下面的aspnet_wp.exe不同，他不是asp.net特有的，能够用来处理任何类型的请求。什么样的ISAPI模块被加载类型根据需要的服务资源类型。

查看本文来源