IIS版本下ASP.net请求处理过程分析第1/3页

大多数人只熟悉高级框架，如网络表单和网络服务——所有这些都是ASP.NET的最高级别。本文的材料是从微软发布的各种文档中收集的。通过比较IIS5、IIS6和IIS7的请求处理过程，我们熟悉了ASP.NET的底层机制，了解了请求是如何从Web服务器传输到ASP.NET运行时的。通过了解背后的机制，我们可以对ASP.net有更深入的了解。ASP.net请求处理IIS 5

图说明：IIS 5.x的一个显著特点是将网络服务器和真实的ASP.NET应用程序分开。作为一个网络服务器，IIS运行在一个名为InetInfo.exe的进程上，而InetInfo.exe是一个本机执行程序，而不是一个托管程序，而我们真正的aspnet应用程序运行在一个名为aspnet_wp的工作进程上，当进程初始化时，它将加载CLR，因此它是一个托管环境。ISAPI:指可以处理各种后缀名称的应用程序。ISAPI是以下几个字的简称：互联网服务器应用程序接口。IIS 5模式的特点：首先，同一主机上只能同时运行一个aspnet_wp进程，每个基于虚拟目录的aspnet应用对应一个Application Domain，这意味着每个应用运行在同一个Worker Process中。应用程序之间的隔离基于应用程序域，而不是进程。其次，ASP.NET isapi不仅负责创建aspnet_wp Worker进程，还负责监控该进程。如果检测到aspnet_wp的性能下降到某个设定的下限，ASP.NET isapi将负责结束该过程。aspnet_wp完成后，后续的请求将导致ASP.NET的ISAPI重新创建一个新的aspnet_wp工作进程。最后，由于IIS和Application运行在各自的进程中，它们之间的通信必须采用特定的通信机制。本质上，InetInfo进程和IIS所在的Worker进程之间的通信是同一个机器的本地进程间通信，性能考虑了这一点，两者之间采用了基于命名管道的通信机制。isapi和ASP.NET的Worker Process之间的通信是通过它们之间的一组管道实现的。出于同样的性能原因，ASP.NET ISAPI以异步方式向工作进程发送请求并获得响应，而工作进程以同步方式从ASP.NET ISAPI获得一些基于服务器的变量。ASP.net请求处理国际软件研究所6

图说明：IIS 5.x通过InetInfo.exe监控请求，并将请求分发到工作流程。换句话说，在IIS 5.x中，对Request的监控和分发是在User Mode中进行的，在IIS 6中，这种工作被移植到内核Mode中，而这一切都由一个新的组件：http.sys来处理。注意：为了防止用户应用程序访问或修改关键的操作系统数据，windows提供了两种处理器访问模式：User Mode和kernel Mode。通常，用户程序以用户模式运行，而操作系统代码以内核模式运行。内核模式代码允许访问所有系统内存和所有中央处理器指令。在用户模式下，http.sys接收一个基于aspx的http Request，然后它会根据IIS中的Metabase检查基于请求的应用程序属于哪个应用程序池，如果应用程序池不存在，它会创建它。否则，将请求直接发送到相应应用程序池的队列。每个应用程序池对应一个工作进程：w3wp.exe，它无疑是在用户模式下运行的。维护IIS元数据库中应用程序池和工作进程的映射。根据这样的映射，WAS(网络管理服务)将应用程序池队列中存在的请求传递给相应的工作进程(如果没有，创建这样的进程)。在工作进程初始化时，加载ASP.NET isapi、ASP.NET isapi，然后加载CLR。最后的过程与IIS 5.x相同：通过AppManagerAppDomainFactory的创建方法为应用程序创建一个应用程序域；该请求通过ISAPIRuntime的ProcessRequest进行处理，然后该进程进入ASP.NET的http运行时管道。阅读下一页的全文。