IIS是如何处理ASPNET请求的_第1页
IIS是如何处理ASPNET请求的_第2页
IIS是如何处理ASPNET请求的_第3页
IIS是如何处理ASPNET请求的_第4页
IIS是如何处理ASPNET请求的_第5页
已阅读5页,还剩6页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

IIS是如何处理ASP.NET请求的英文原文:Beginners Guide: How IIS Process ASP.NET Request前言每次服务器接受到请求,都要先经IIS处理。这不是一篇描述ASP.NE生命周期的文章,仅仅是关于IIS操作的。在我们开始之前,先了解这些会有助于对全文的理解,同时欢迎反馈和建议。什么是Web Server?每当我们通过VS运行ASP.NET网站时,VS集成的ASP.NET引擎会响应各种请求,这个引擎的名字叫“WebDev.WebServer.exe”。当我们配置一个Web程序时,总会涉及到一个词“Web Server”,它的功能便是会响应所有请求。什么是IIS?IIS(Internet Information Server)是微软Web Server的一种,用来配置ASP.NET站点。IIS拥有自己的ASP.NET处理引擎来处理请求,因此,当一个请求到达时,IIS接收并处理请求,然后返回内容。请求处理过程现在,你应能搞清楚Web Server和IIS的区别。现在我们来看一下核心部分。在继续之前,你需要搞清两个概念:1、工作进程(Worker Process)2、应用程序池(Application Pool)工作进程:在IIS中,工作进程(w3wp.exe)运行着ASP.NET应用程序,管理并响应所有的请求,ASP.NET所有的功能都运行在工作进程下,当请求到来时,工作进程会生成Request和Response相关的信息。简而言之,工作进程就是 ASP.NET程序的心脏。应用程序池:应用程序池是工作进程的容器,通常用来隔开不同配置的工作进程。当一个程序出错或进程资源回收时,其他池中的程序不会受到影响。注:当一个应用程序池包含多个工作进程时,被叫做“Web Garden”。如果我们看一下IIS 6.0的结构,就会发现,可以把它分成两部分:1、内核模块(Kernel Mode)2、用户模块(User Mode)内核模式是从IIS 6.0被引入的,它包含了一个叫HTTP.SYS的文件,每当请求进来时,会首先触发该文件的响应。HTTP.SYS文件负责把请求传入相应的应用程序池中。但HTTP.SYS如何知道应传给哪个应用程序池呢?当然不是随机抽取,每当创建一个应用程序池,该池的ID就会生成并在HTTP.SYS文件中注册,因此该文件才能确定将请求往哪传。以上便是IIS处理请求的第一步。接着,我们来看一下请求如何从HTTP.SYS传入应用程序池。在IIS的用户模块中,通过Web Admin Services (WAS)从HTTP.SYS接收请求,并传入相应的应用程序池中。当应用程序池接收到请求,会接着传给工作进程(w3wp.exe),该进程检查来请求的URL后缀以确定加载哪个ISAPI扩展。ASP.NET加载时会附带自己的ISAPI扩展(aspnet_isapi.dll),以便在IIS中映射。注意:如果先安装了,然后再安装IIS,就需要通过aspnet_regiis命令来注册ASP.NET中的ISAPI扩展。一旦工作进程加载了aspnet_isapi.dll, 就会构造一个HttpRuntime类,该类是应用程序的入口,通过ProcessRequest方法处理请求。一旦这个方法被调用,一个HttpContext的实例就产生了。可通过HTTPContent.Current获取到这个实例,且该实例会在整个生命周期中存活,我们通过它可以获取到一些常用对象,如Request,Response,Session 等。之后HttpRuntime会通过HttpApplicationFactory类加载一个HttpApplication对象。每一次请求都 要穿过一堆HttpModule到达HttpHandler,以便被响应。而这些HttpModule就被配置在HttpApplication中。有一个概念叫“Http管道”,被叫做管道是因为它包含了一系列的HttpModule,这些HttpModule拦截请求并将其导向相应的HttpHandler。我们也可自定义HttpModule,以便在请求响应之间做点特别的处理。HttpHandler是“Http管道”的终点。所有请求穿过HttpModule需抵达相应的HttpHandler,然后HttpHandler根据请求资源,产生并输出内容。也正因此,我们请求任何aspx页面才会得到响应的Html内容。结语每当请求Web服务器上的某些信息时,该请求首先会到达Http.SYS, 然后Http.SYS将其发送到相应的应用程序池,应用程序池传给工作进程并加载ISAPI扩展,然后HttpRuntime对象会被创建,并通过 HttpModule和HttpHandler处理请求。最后,ASP.NET页面生命周期就开始了。这只是大致描述IIS处理过程的文章,如果你想进一步了解相应细节,请点击下面链接来进一步学习。A low-level Look at the ASP.NET ArchitectureIIS Architecture本文翻译自:Beginners Guide: How IIS Process ASP.NET Request译后小注:1、如果在IIS配置完站点却看不到“w3wp.exe”进程,只要用浏览器打开该站其中一个页面,“w3wp.exe”进程就会出现了。2、为节省时间,直接引用了原图,英文差的,小查一下字典应该没啥问题。相关博文:Asp.Net构架(Http请求处理流程)Web应用程序和服务器端动态网页举一个客户登录的例子,当客户用浏览器填好表格后,将表格数据传回Web服务器,应把这些信息存入数据库。Web服务器软件并不能完成此项工作,它调用运行Web服务器软件的计算机上的其它程序完成,这个程序叫Web应用程序。又如,建立一个中学校园网,并建立一个学生信息数据库,可供校长、教导处、老师查询。一般要根据一些条件进行查询,如某班的学生,获得三好生的学生等。浏览器把所查找的条件送给Web服务器后,Web服务器必须调用Web应用程序完成此项工作,此程序从数据库查到有关数据后,要转换查找结果为HTML语言标记的网页,传送给Web服务器,再发送给请求此项查询的浏览器。这个根据查询条件动态生成的网页叫做服务器端动态网页。编制服务器端Web应用程序主要有如下几种方法:CGI,ISAPI,NSAPI,ASP,ASP.Net,JSP,PHP等。ASP.Net技术是微软提出的编制Web应用程序的技术。Web应用程序在Web网站系统中所起的作用如下图,图中用ASP.Net实现的Web应用程序采用ADO.Net技术访问数据库。该图是一个典型的三层数据库系统,所谓三层是根据功能将应用分为表示层、功能层、数据层3部分。这里的3层分别用浏览器、Web服务器(包含Web应用程序)、数据库服务器实现。一些文献中提到4层数据库系统是将Web应用程序从Web服务器分离,在Web服务器和数据库之间增加一个应用服务器(应用层)。解析Web服务器与应用程序服务器区别通俗的讲,Web服务器传送页面使浏览器可以浏览,然而应用程序服务器提供的是客户端应用程序可以调用(call)的方法(methods)。确切 一点,你可以说:Web服务器专门处理HTTP请求(request),但是应用程序服务器是通过很多协议来为应用程序提供(serves)商业逻辑 (business logic)。下面让我们来细细道来:Web服务器(Web Server)Web服务器可以解析(handles)HTTP协议。当Web服务器接收到一个HTTP请求(request),会返回一个HTTP响应 (response),例如送回一个HTML页面。为了处理一个请求(request),Web服务器可以响应(response)一个静态页面或图片, 进行页面跳转(redirect),或者把动态响应(dynamic response)的产生委托(delegate)给一些其它的程序例如CGI脚本,JSP(JavaServer Pages)脚本,servlets,ASP(Active Server Pages)脚本,服务器端(server-side)JavaScript,或者一些其它的服务器端(server-side)技术。无论它们(译者 注:脚本)的目的如何,这些服务器端(server-side)的程序通常产生一个HTML的响应(response)来让浏览器可以浏览。要知道,Web服务器的代理模型(delegation model)非常简单。当一个请求(request)被送到Web服务器里来时,它只单纯的把请求(request)传递给可以很好的处理请求 (request)的程序(译者注:服务器端脚本)。Web服务器仅仅提供一个可以执行服务器端(server-side)程序和返回(程序所产生的)响 应(response)的环境,而不会超出职能范围。服务器端(server-side)程序通常具有事务处理(transaction processing),数据库连接(database connectivity)和消息(messaging)等功能。虽然Web服务器不支持事务处理或数据库连接池,但它可以配置(employ)各种策略(strategies)来实现容错性(fault tolerance)和可扩展性(scalability),例如负载平衡(load balancing),缓冲(caching)。集群特征(clustering-features)经常被误认为仅仅是应用程序服务器专有的特征。应用程序服务器(The Application Server)根据我们的定义,作为应用程序服务器,它通过各种协议,可以包括HTTP,把商业逻辑暴露给(expose)客户端应用程序。Web服务器主要是处 理向浏览器发送HTML以供浏览,而应用程序服务器提供访问商业逻辑的途径以供客户端应用程序使用。应用程序使用此商业逻辑就象你调用对象的一个方法(或 过程语言中的一个函数)一样。应用程序服务器的客户端(包含有图形用户界面(GUI)的)可能会运行在一台PC、一个Web服务器或者甚至是其它的应用程序服务器上。在应用程序 服务器与其客户端之间来回穿梭(traveling)的信息不仅仅局限于简单的显示标记。相反,这种信息就是程序逻辑(program logic)。 正是由于这种逻辑取得了(takes)数据和方法调用(calls)的形式而不是静态HTML,所以客户端才可以随心所欲的使用这种被暴露的商业逻辑。在大多数情形下,应用程序服务器是通过组件(component)的应用程序接口(API)把商业逻辑暴露(expose)(给客户端应用程序) 的,例如基于J2EE(Java 2 Platform, Enterprise Edition)应用程序服务器的EJB(Enterprise JavaBean)组件模型。此外,应用程序服务器可以管理自己的资源,例如看大门的工作(gate-keeping duties)包括安全(security),事务处理(transaction processing),资源池(resource pooling), 和消息(messaging)。就象Web服务器一样,应用程序服务器配置了多种可扩展(scalability)和容错(fault tolerance)技术。一个例子例如,设想一个在线商店(网站)提供实时定价(real-time pricing)和有效性(availability)信息。这个站点(site)很可能会提供一个表单(form)让你来选择产品。当你提交查询 (query)后,网站会进行查找(lookup)并把结果内嵌在HTML页面中返回。网站可以有很多种方式来实现这种功能。我要介绍一个不使用应用程序 服务器的情景和一个使用应用程序服务器的情景。观察一下这两中情景的不同会有助于你了解应用程序服务器的功能。情景1:不带应用程序服务器的Web服务器在此种情景下,一个Web服务器独立提供在线商店的功能。Web服务器获得你的请求(request),然后发送给服务器端(server- side)可以处理请求(request)的程序。此程序从数据库或文本文件(flat file,译者注:flat file是指没有特殊格式的非二进制的文件,如properties和XML文件等)中查找定价信息。一旦找到,服务器端(server-side)程序 把结果信息表示成(formulate)HTML形式,最后Web服务器把会它发送到你的Web浏览器。简而言之,Web服务器只是简单的通过响应(response)HTML页面来处理HTTP请求(request)。情景2:带应用程序服务器的Web服务器情景2和情景1相同的是Web服务器还是把响应(response)的产生委托(delegates)给脚本(译者注:服务器端(server- side)程序)。然而,你可以把查找定价的商业逻辑(business logic)放到应用程序服务器上。由于这种变化,此脚本只是简单的调用应用程序服务器的查找服务(lookup service),而不是已经知道如何查找数据然后表示为(formulate)一个响应(response)。 这时当该脚本程序产生HTML响应(response)时就可以使用该服务的返回结果了。在此情景中,应用程序服务器提供(serves)了用于查询产品的定价信息的商业逻辑。(服务器的)这种功能(functionality)没有指 出有关显示和客户端如何使用此信息的细节,相反客户端和应用程序服务器只是来回传送数据。当有客户端调用应用程序服务器的查找服务(lookup service)时,此服务只是简单的查找并返回结果给客户端。通过从响应产生(response-generating)HTML的代码中分离出

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论