免费信息网站建设,滨州网站建设铭盛信息,网站关键词库怎么做有什么效果,网站底部的备案信息修改介绍 微软的Active ServerPages#xff0c;即ASP#xff0c;自1996年首次发布以来#xff0c;为Web开发者构建Web应用提供了一个丰富、复杂的框架。过去的几年它的基础架构发展的如此迅速#xff0c;成为目前大家了解的ASP.NET#xff0c;已经不再象它的前身。ASP.NET是构…介绍 微软的Active ServerPages即ASP自1996年首次发布以来为Web开发者构建Web应用提供了一个丰富、复杂的框架。过去的几年它的基础架构发展的如此迅速成为目前大家了解的ASP.NET已经不再象它的前身。ASP.NET是构建Web应用的框架就是说应用程序运行在Web上客户-服务器端模式表现为浏览器向Web服务器发送各种资源的请求。象CGI、PHP、JSP、ASP等动态服务器端资源生成技术出现以前所有Web服务器必须接受客户端静态资源请求将其发送给请求者。随着动态技术的发展Web服务器开始承担更多的职责因为它们必须采取一些方式在服务器端生成动态资源将结果返回给客户端这已经是一项不同于以前的任务。 从菜鸟的角度来看客户端和服务器端的交互很简单就是出现了使用HTTP超文本传输协议的Web通讯。HTTP是一种依赖TCP、IP在异构网络即万维网的两个连接节点间传输数据的应用层协议。 每一种动态服务器端技术都完全了解特定的Web服务器实现ASP.NET跟微软的因特网信息服务器即IIS紧密结合在一起。 不同的服务器使用不同的方法生成动态资源我们需要检验的是IIS怎样在服务器上处理某个请求的路径将结果返回给客户端。IIS和ISAPI扩展 前面提到静态资源不需要服务器处理一旦接收到静态资源请求服务器只需要从文件系统获取它的内容按照HTTP协议向客户端发送内容的字节流。静态资源可以是图片、脚本文件、css样式表或者html页面。很明显服务器需要知道怎样区别静态和动态资源因为后者需要经过某些处理而不是直接将其发送给客户端。这就是ISAPI出现的原因ISAPI表示因特网应用程序接口Internet Server ApplicationProgramming Interface。ISAPI扩展是使用Win32.dll实现的模块IIS使用它处理特定的资源。ISAPI扩展和文件之间的映射通过IIS插件配置存储在IIS元数据中。每一个文件扩展可以和特定的ISAPI扩展关联就是说当这种文件的请求到达后IIS将它交给相应的ISAPI扩展认为它能够处理。 图1在IIS 5.0中配置ISAPI扩展映射 很明显ISAPI需要实现一个公共接口IIS能够使用详细描述请求的数据进行调用生成响应。 如图1的演示.asp扩展被映射到asp.dll的ISAPI扩展。对于ASP页面这个组建负责处理所有的请求任务生成输出包括收集请求信息通过Request、Response以及其它公共ASP内置对象将这些信息传递给ASP页面解析执行ASP页面返回结果HTML。 实际上与CGI这样的技术相比这是一个极大的改进但ASP.NET采取了更进一步的做法引入抽象方法避免开发者必须关注这个过程中到底发生了什么。 安装完后ASP.NET配置IIS将特定的ASP.NET文件请求重定向到一个叫做aspnet_isapi.dll的ISAPI扩展。这个ISAPI扩展的处理跟之前的asp.dll扩展有点不一样asp.dll扩展只是负责解析和执行请求的ASP页面。普通ISAPI模块处理请求的步骤完全被IIS隐藏因此为了处理请求ISAPI扩展可以采用不同的模式。 表1aspnet_isapi.dll的IIS应用程序映射
扩展名资源类型
.asax ASP.NET application files. Usually global.asax.
.ascx ASP.NET user control files.
.ashx HTTP handlers, the managed counterpart of ISAPI extensions.
.asmx ASP.NET web services.
.aspx ASP.NET web pages.
.axd ASP.NET internal HTTP handlers.
除了表1中的文件扩展列表ASP.NET ISAPI扩展也管理其它一些不支持浏览器请求的文件扩展例如Visual Studio工程文件、源代码和配置文件等。ASP.NET处理模型 目前为止我们已经了解IIS接收到ASP.NET文件请求时将其传给aspnet_isapi.dll这个ASP.NET相关处理的主入口点。实际上ISAPI扩展怎样进行处理依赖于操作系统的IIS版本不同版本的处理模型可能很不一样。处理模型指ASP.NET运行时为了处理请求、生成响应而进行的操作序列。 当运行在IIS5.x时所有ASP.NET相关的请求被ISAPI扩展分发到一个叫做aspnet_wp.exe的外部工作进程。运行在IIS进程inetinfo.exe中的ASP.NETISAPI扩展将控制转给aspnet_wp.exe并传递请求相关的所有信息。它们之间的通讯通过命名管道进行即众所周知的IPC进程间通讯Inter ProcessCommunication机制。ASP.NET工作进程与ISAPI扩展一起执行一定数量的任务它们是ASP.NET请求背后处理的主要承担者。介绍一下后面会讨论的一个主题注意对应于IIS上不同虚拟目录的每一个web应用程序都是在同一个进程的上下文中执行的即ASP.NET工作进程。为了在执行上下文中提供隔离ASP.NET模型引入了应用程序域的概念简写为AppDomain。它们可以看作是轻量级的进程更多的讨论在后面。 另一方面如果运行在IIS6不会使用aspnet_wp.exe而是另外一个叫做w3wp.exe的进程。另外inetinfo.exe不再向ISAPI传递HTTP请求但它仍然处理其他请求协议。尽管IIS 6能够以兼容模式运行模拟前一个版本IIS的行为但与IIS5相比处理模型上很多细节改变了。一个大的改进是与运行在IIS5上的处理模型相比到达的请求将在较低的内核层级处理然后传递给适当的ISAPI扩展。这避免了进程间通讯技术从性能和资源消耗角度来看进程间通讯是一个昂贵的操作。我们在下面的章节中深入探讨这个。IIS 5.0处理模型 这是Windows 2000和XP机器上默认的处理模型。前面提到它位于IIS inetinfo.exe进程中默认监听TCP80端口接收HTTP请求将请求排列到一个队列中等待接受处理。如果请求是ASP.NET类型这个处理被委托给ASP.NETISAPI扩展即aspnet_isapi.dll。接下来通过命名管道与ASP.NET工作进程aspnet_wp.exe通讯最后由工作进程将请求交给ASP.NET HTTP运行时环境。图2以图形方式展现这个处理过程。 图2IIS 5.0处理模型 图2中出现了一个我们还没有提到过的额外元素ASP.NETHTTP运行时环境。这不是本文的主题会在后续的文章中详细解释但为了本文的讨论可以把HTTP运行时环境看作一个黑箱ASP.NET相关的处理在这儿完成所有托管代码位于这开发者可以在这进行处理从直接的HttpRuntime到HttpHandler等在这处理请求生成响应。这也被称为ASP.NET管道或者HTTP运行时管道。 这个处理模型中有意思的一点是所有的请求一旦被ISAPI扩展处理就被传给ASP.NET工作进程。同一时间只有一个ASP.NET进程实例是活动状态不过有一个例外后面会讨论。因此运行在IIS中的所有ASP.NETweb应用程序实际上也是运行在工作进程上的然而这并不意味着所有的应用程序运行在相同的上下文中共享所有的数据。前面提到ASP.NET引入了AppDomain的概念它其实是一种托管的轻量级进程提供隔离和安全边界。每个IIS虚拟目录在独立的AppDomain中执行当属于这个应用的任何一个资源在第一次请求时这个AppDomain被自动加载到工作进程中。AppDomain被加载之后就是说所有用于处理这个请求所需的程序集被加载到AppDomain中然后控制权被传给ASP.NET管道进行实际的处理。多个AppDomain可以运行在同一个进程中同一个AppDomain的请求可以用多个线程来处理然而线程并不属于AppDomain它可以服务于不同AppDomain的请求但在给定的时间一个线程只会属于一个AppDomain。 出于性能原因工作进程可能会依据某些条件进行回收可以从位于C:\windows\microsoft.net\Framework\[frameworkversion]\CONFIG目录中的machine.config文件看到这些描述性的条件包括进程生存时间、正在处理以及队列中的请求数、空闲时间以及内存消耗。一旦达到这些参数中的某个预设值ISAPI扩展为工作进程创建一个新的实例用它继续处理请求。只有在这个时候多个工作进程并发运行实际上老的进程实例并没有被结束掉允许它处理剩余的请求。IIS 6.0处理模型 IIS 6处理模型是运行Windows 2003 Server操作系统的机器上默认的模型它在IIS5处理模型的基础上引入了几个改进最大的改变之一是引入了应用程序池的概念。在IIS5.x上所有的web应用程序即所有的AppDomain运行在ASP.NET工作进程中为了实现更好的安全边界粒度以及定制能力IIS6处理模式允许应用程序运行在不同的工作进程中即w3wp.exe。每个应用程序池可以包含多个AppDomain运行在独立的工作进程中换句话说就是从单个进程运行所有的应用程序切换到每个工作进程运行一个应用程序池。这个模式也叫做工作进程隔离模式worker processisolation mode。 与之前的模式相比另一个大的改变是IIS监听请求的方式。IIS5模式中由IIS进程inetinfo.exe来监听特定的TCP端口接收HTTP请求在IIS6架构中通过一个叫做http.sys的内核驱动在内核层级而不是之前的用户模式下处理和排队请求这种方式比老的模式有一些优点叫做内核级请求队列kernel-level request queuing。 图3IIS 6.0处理模型 图3演示了使用IIS6模式处理请求的主要组建。请求到达后内核级的设备驱动http.sys将其传递到正确的应用程序池队列中每个队列属于特定的应用程序池也就是说属于特定的工作进程接下来工作进程从队列中接收请求。这种方式极大的降低了IIS5模式中引入的命名管道的开销因为不再需要进程间通讯请求直接从内核级驱动传递给工作进程这样有很多的优点例如可靠性。因为运行在内核模式中请求分发不受用户模式即工作进程中宕机和故障的影响因此即使工作进程宕机了系统仍然能够接收请求重起宕机的进程。 工作进程负责加载ASP.NET ISAPI扩展它依次加载CLR将所有的工作委托给HTTP运行时。 w3wp.exe工作进程不同于IIS 5模式中的aspnet_wp.exe进程跟ASP.NET不相关它用于处理任何类型的请求然后工作进程根据它需要处理的资源类型决定加载哪些ISAPI模块。 出于简化目的在图3中有一个细节没有标出来到达的请求通过IIS 6中加载的一个叫做Web管理服务WAS的模块从应用程序池队列传递给正确的工作进程。这个模块负责从IIS元数据读取工作进程与web应用程序的邦定信息将请求传递给正确的工作进程。
