ASP.NET的过程模型之一IIS和ASP.NET的ISAPI

前几天有朋友在MSN上问我，“asked从最初收到Http请求到最后生成Response的整个过程是什么？”我觉得这个问题跟IIS和ASP.NETASP.NET运行时的处理模型有关，三言两语解释不清楚，所以决定写这样一篇介绍IIS和ASP.NET运行时进程模型的文章，谈谈我对它的粗浅认识。如果有错，希望大家及时改正。本文大致分为两个部分。第一部分，我会讲两个不同版本的IIS————IIS 5 . x和IIS 6(虽然IIS 7已经发布很久了，但是和之前的两个版本相比变化很大。因为对IIS 7缺乏深入了解，这里就不介绍了。不过，这方面我以后会补的。)处理模型：IIS如何监听外界的Http请求，如何根据ISAPI扩展映射将不同资源的请求分配到不同的ISAPI扩展，基于ASP.NET资源的ASP.NET ISAPI如何将请求传输到ASP.NET的运行时环境。在第二部分中，我们将着重于在托管的ASP.NET运行时环境中处理传入的Http请求。我们先来看看IIS 5.x和IIS 6的处理。1.一、基于IIS 5.x的流程模型IIS 5.x是IIS 5的显著特点。x是网络服务器和真实ASP.NET应用的分离。作为一个网络服务器，IIS运行在一个名为InetInfo.exe的进程上，而InetInfo.exe是一个本机执行程序，而不是一个托管程序，而我们真正的aspnet应用程序运行在一个名为aspnet_wp的工作进程上，当进程初始化时，它将加载CLR，因此它是一个托管环境。接下来，我们将讨论如何创建aspnet_wp，如何在aspnet_wp和InetInfo.exe之间进行通信，并简要介绍如何在aspnet_wp中将Request导入到ASP.NET的RUTIME Pipeline中。我们通过创建一个虚拟目录来托管IIS下的资源。原则上，我们可以通过IIS访问虚拟目录下的所有资源。这个只包含一些静态的资源文件，比如图片、纯Html文件、CSS、JS等。还包含一些需要动态执行的文件，如aspx、asmx等。我们还可以在IIS下托管Remoting和wcf服务。对于这些静态文件，IIS直接提取相应的文件，并将其作为Http响应返回给客户端。但是，对于这些需要进一步处理的动态执行的文件，IIS必须进一步将Request传递给相应的处理程序，当处理程序完成执行时，将获得最终的Http Response，并通过IIS返回给客户端。对于IIS，这些处理程序由ISAPI扩展实现。对于基于aspnet的资源，其对应的isapi扩展是ASP.NET ISAPI，由一个aspnet_isapi.dll承载。IIS的元数据数据库维护一个名为ISAPI扩展映射的数据表，负责将不同类型的资源映射到对应的ISAPI扩展。

在上图中，我们展示了IIS5.x如何处理基于ASP.NET资源的Http请求的一般过程(以aspx为例)。首先，用户通过浏览器请求一个aspx页面，浏览器请求Web服务器，也就是目标主机的IIS。正如我们上面提到的，IIS运行在一个名为InetInfo.exe的进程中，而InetInfo.exe是一个本地执行程序，而不是一个托管程序。分析了IIS Request(此处为aspx)的目标资源文件的扩展名，通过isapi扩展名映射，对应的ISPAI为ASP.NET ISAPI，因此加载了aspnet_isapi.dll。到目前为止，这一请求的处理工作已移交给ASP.NET国际审计与调查研究所。aspnet的Isapi将创建一个名为aspnet_wp.exe的工作进程(如果该进程不存在)。当aspnet_wp.exe被初始化时，它将加载CLR，从而为aspnet应用程序创建一个托管运行环境。当使用CLR初始化时，它将加载两个重要的dll:appmanagerdomainfactory和ISAPIRuntime。使用应用程序管理器的创建方法为应用程序创建应用程序域；该请求由ISAPIRuntime的ProcessRequest处理，然后该进程被拖到ASP.NET的http运行时管道的范围内。ASP.NET的http运行时管道是一个相对复杂的过程，相关介绍将放在本文的下一部分。这里我们可以把它想象成一个黑盒，它接管了Request并最终生成了Html。这基本上就是整个处理流程，非常简单。然而，这里有几点需要指出。1.首先，同一主机上只能同时运行一个aspnet_wp Process，每个基于虚拟目录的aspnet应用对应一个Application Domain，这意味着每个应用运行在同一个Worker Process中，应用之间的隔离是基于Application Domain而不是Process。其次，ASP.NET isapi不仅负责创建aspnet_wp Worker进程，还负责监控该进程。如果检测到aspnet_wp的性能下降到某个设定的下限，ASP.NET isapi将负责结束该过程。aspnet_wp完成后，后续的请求将导致ASP.NET的ISAPI重新创建一个新的aspnet_wp工作进程。3.最后，由于IIS和Application运行在各自的进程中，它们之间的通信必须采用特定的通信机制。本质上，InetInfo进程和IIS所在的Worker进程之间的通信是同一个机器的本地进程间通信，性能考虑了这一点，两者之间采用了基于命名管道的通信机制。isapi和ASP.NET的Worker Process之间的通信是通过它们之间的一组管道实现的。出于同样的性能原因，ASP.NET ISAPI以异步方式向工作进程发送请求并获得响应，而工作进程以同步方式从ASP.NET ISAPI获得一些基于服务器的变量。2.2.基于iis6的过程模型可靠性和性能永远不会是我们在软件开发中不变的主题。作为基于Http应用的主机IIS，这两个方面尤为重要。从IIS 5.x到IIS 6的演变，不难看出IIS 6在之前版本的基础上所做的改进也是基于这两个方面。在介绍IIS 6的处理模型之前，我们先来看看IIS 5.x: 1的缺陷。从性能的角度来看，IIS和应用程序在不同的进程中运行。虽然它们采用了基于命名管道的异步通信模式，但无法从根本上解决进程间通信对性能的影响。其次，从可靠性的角度来看，一台机器上只能运行一个工作进程，每个应用程序都在同一个进程中运行。虽然基于应用域的隔离可以提供一定的可靠性，但是一旦整个过程崩溃，所有应用都会受到影响。所以有时候我们需要提供基于流程的隔离。基于可靠性的提高，IIS 6引入了应用池。

顾名思义，应用程序池是应用程序的容器。在IIS 6中，我们可以创建几个应用程序池。当创建一个网络应用程序时，我们为它指定一个给定的应用程序池。在运行时，应用程序对应于一个工作进程：w3wp.exe。也就是说，与之前版本的IIS不同，对于IIS 6，可以在同一台机器上同时运行多个worker process，每个Worker process中的每个Application域对应一个Application。这样，不仅可以在应用程序之间提供应用程序域级隔离，还可以将不同的应用程序放在不同的应用程序池中，从而基于进程级隔离。对于主机的一些重要应用，该方法可以提供良好的可靠性。在性能方面，IIS 5.x通过InetInfo.exe监控请求，并将请求分发到工作进程。换句话说，在IIS 5.x中，对Request的监控和分发是在User Mode中进行的，在IIS 6中，这种工作被移植到内核Mode中，而这一切都由一个新的组件：http.sys来处理。注意：为了防止用户应用程序访问或修改关键的操作系统数据，windows提供了两种处理器访问模式：User Mode和kernel Mode。通常，用户程序以用户模式运行，而操作系统代码以内核模式运行。内核模式代码允许访问所有系统内存和所有中央处理器指令。关于用户模式和内核模式，以及Windows底部的一些内容，建议大家看看《Microsoft Windows Internal》 Four Edition，由mark e. rusinovich David a. Solomon认证。

上图基本演示了IIS 6的整个过程。在用户模式下，http.sys接收一个基于aspx的http Request，然后它会根据IIS中的Metabase检查基于请求的应用程序属于哪个应用程序池，如果应用程序池不存在，它会创建它。否则，将请求直接发送到相应应用程序池的队列。如上所述，每个应用程序池对应一个工作进程：w3wp.exe，它无疑是在用户模式下运行的。维护IIS元数据库中应用程序池和工作进程的映射。根据这样的映射，WAS(网络管理服务)将应用程序池队列中存在的请求传递给相应的工作进程(如果没有，创建这样的进程)。在工作进程初始化时，ASP。NETISAPI被加载，ASP。然后，NETISAPI加载CLR。最后的过程与IIS 5.x相同：通过AppManagerAppDomainFactory的创建方法为应用程序创建一个应用程序域；该请求通过ISAPIRuntime的ProcessRequest进行处理，然后该进程进入ASP.NET的http运行时管道。这就是IIS流程模型的全部内容。在下一节中，我将介绍ASP.NET HTTP运行时管道。