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

　　ASP.net对于编写WEB应用程序以及组件来说是一个很好的框架，但是由于他的庞大性对于很多人来说要了解他的每一个细节好象是否不太可能，我一直认为有必要了解一下基层结构的工作原理以便在设计时获取更高的性能，在接下来的一系列文章中，我将要描叙一下WEB的生命周期，从当请求被服务器接受开始，传送到ASP.net管道处理一直到生成回送信息(如：HTML)在管道处理后期。

　　介绍

　　Microsoft Active Server Pages(微软动态网页服务)，同样也被大家称为ASP，首先是在1996年末年发布的，为程序员提供一个用来建立WEB应用程序丰富复杂的框架。几年后，他的基础构造发展改进了很多，也就是大家现在所了解的ASP.net.ASP.net是一个用来构件WEB应用程序的框架，也就是说，他必须运行在WEB服务上，用客服端-服务端模型了表述的话通常是浏览器发送不同类型的资源请求到WEB服务器。在出现动态服务器资源生成技术(如CGI，PHP，JSP以及ASP)，所有的WEB服务只能接受客服端的静态资源请求并把他们回送到客服端。

　　表面上看起来,这样在服务端和客户端的交互是非常的简单。会话通过HTTP协议进行，他是一个建立在TCP和IP协议(用来在2个连接到不同类型的网络端点交换数据，如我们所知道的WWW万维网)上的应用程序级协议。

　　本质上任何动态服务器技术需要运行在特定WEB服务上，同样ASP.net紧密地和微软因特网信息服务，也叫做IIS。

　　不同的服务选择不同的方式去生成动态资源等等。。。我们将要解析一下IIS是怎么做到的当一个请求信息一旦到达服务端以及最后回送到客户端。

　　IIS and ISAPI 扩展

　　如上面提到的，静态资源不需要被服务器处理;一旦这样的资源请求到达服务器，服务器只需要从文件系统中找到他的内容并且以字节流形式发送到客户端通过HTTP协议。静态资源可以是图片，javascript,CSS或者普通HTML页面。很显然服务器需要知道怎样去区分静态和动态资源，动态资源需要如何被处理而不是直接发送回客户端。因此出现了ISAPI扩展，ISAPI是因特网服务应用程序编程的接口。ISAPI作为模块被执行如早期的Win32.dll.IIS依靠ISAPI来处理特定的资源。通过IIS映射ISAPI扩展和文件的方式，把每种文件扩展类型关联到特定的ISAPI扩展，也就是说，当一个请求某种文件的请求到达，IIS处理并转到相应的ISAPI扩展，以确认这种请求能被处理。

　　图表1：在IIS5.0中配置ISAPI扩展映射

　　ISAPI扩展明显需要符合一个通用接口，这样他们才能被IIS调用并提供必要的数据用来处理请求和生成回送。

　　如图1，.ASP扩展名被映射到asp.dll ISAPI扩展;在ASP处理时段，这个组件负责执行所有需要的任务去生成回送，也就是说，通过收集请求信息，并使得他能够在ASP页面可用，其他ASP内部对象，解析并执行ASP页面最后以HTML形式返回结果。

　　尽管，这样相对于CGI技术来说已经是很大的进步了，但是ASP.net更强大。

　　在安装ASP.net后，ASP.net配置IIS 把ASP.net指定的文件请求重定向到一个新的ISAPI扩展aspnet_isapi.dll.这个扩展有些不同于以前的asp.dll扩展。

　　表格I：aspnet_isapi.dll在IIS应用程序中的映射

　　ExtensionResource Type

　　.asaxASP.NET 应用程序文件. 常用的有 global.asax.

　　.ascxASP.NET 用户控件文件.

　　.ashxHTTP handlers, the managed counterpart of ISAPI extensions.

　　.asmxASP.NET web services.

　　.aspxASP.NET web pages.

　　.axdASP.NET internal HTTP handlers.

　　除了表格1所列出的文件扩展名，ASP.net ISAPI扩展也管理其他一些通常不提供给浏览器访问的文件扩展类型，如Visual Studio工程文件，资源文件以及配置文件。

　　ASP.NET处理模型

　　到目前为止，我们已经明白当请求一个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运行时管道。

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有