IIS是如何处理ASP.NET请求的

前言

这不是一篇描述asp.net生命周期的文章,仅仅是关于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中映射。

注意:如果先安装了asp.net,然后再安装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 Architecture

IIS Architecture

 

时间: 2024-10-31 04:35:37

IIS是如何处理ASP.NET请求的的相关文章

StaticFileMiddleware中间件如何处理针对文件请求

StaticFileMiddleware中间件如何处理针对文件请求 我们通过<以Web的形式发布静态文件>和<条件请求与区间请求>中的实例演示,以及上面针对条件请求和区间请求的介绍,从提供的功能和特性的角度对这个名为StaticFileMiddleware的中间进行了全面的介绍,接下来我们将更近一步,将从实现原理的角度来进一步认识这个中间件. [本文已经同步到<ASP.NET Core框架揭秘>之中] 目录 一.StaticFileMiddleware二.Content

ASP.NET 未被授权访问所请求的资源。请考虑授予 ASP.NET 请求标识访问此资源的权限

开发了一个导入TXT文件的功能,执行过程中出错.提示:.....ASP.NET 未被授权访问所请求的资源.请考虑授予 ASP.NET 请求标识访问此资源的权限.ASP.NET 有一个在应用程序没有模拟时使用的基进程标识(通常,在 IIS 5 上为 {MACHINE}\ASPNET,在 IIS 6 上为网络服务).如果应用程序正在通过 <identity sonate="true"/> 模拟,则标识将为匿名用户(通常为IUSR_MACHINENAME)或经过身份验证的请求用户

ASP.NET请求管道、应用程序生命周期、整体运行机制

我们知道在ASP.NET中,若要对ASP.NET应用程序进行 初始化并使它处理请求,必须执行一些处理步骤,熟悉应用程序生命周期非常重要,这样才能在适当的生命周期阶段编写代码,达到预期的效果.永远不要做只会拖 控件的.NET程序员,Never!那么你就必须懂ASP.NET应用程序生命周期,懂ASP.NET页面生命周期,懂ASP.NET 服务器控件原理.接下来,我们一起来看看 可以先看一下先导篇 [深入ASP.NET原理系列]--ASP.NET请求管道对Asp.Net WebForm和Asp.Net

ASP.NET 无权访问所请求的资源。请考虑对 ASP.NET 请求标识授予访问此资源的权限。

ASP.NET 无权访问所请求的资源.请考虑对 ASP.NET 请求标识授予访问此资源的权限.ASP.NET 有一个在应用程序没有模拟时使用的基进程标识(通常,在 IIS 5 上为 {MACHINE}\ASPNET,在 IIS 6 和 IIS 7 上为网络服务,在 IIS 7.5 上为配置的应用程序池标识).如果应用程序正在通过 <identity impersonate="true"/> 模拟,则标识将为匿名用户(通常为 IUSR_MACHINENAME)或经过身份验证的

Windows + IIS 环境部署Asp.Net Core App

环境:Windows Server 2012, IIS 8, Asp.Net Core 1.1. 不少人第一次在IIS中部署Asp.Net Core App的人都会遇到问题,会发现原来的部署方式无法运行Asp.Net Core App程序.过去无论是原始的Asp程序还是后来的Asp.Net程序,在IIS中的部署方式都没太大变化,仅需指向程序目录,然后设定虚拟目录,最后做一些参数配置.Asp.Net Core App为了做到跨平台,自带了一个轻量级的Web Server - Kestrel,那么要

1.4部署到IIS「深入浅出ASP.NET Core系列」

很多人第一次在IIS中部署Asp.Net Core App的人都会遇到问题,会发现原来的部署方式无法运行Asp.Net Core App程序.其实大的方式没有多少变化,Asp.Net Core App为了做到跨平台,自带了一个轻量级的Web Server-Kestrel,那么要在IIS中部署Asp.Net Core App,就必须有一种新的机制来协调IIS与Kestrel Server之间的数据传递 Asp.Net Core的部署模式 与传统的Asp.Net程序不同,Asp.Net Core A

深度理解IIS下部署ASP.NET Core2.1 Web应用拓扑图

原文:深度理解IIS下部署ASP.NET Core2.1 Web应用拓扑图 IIS部署ASP.NET Core2.1 应用拓扑图 我们看到相比Asp.Net, 出现了3个新的组件:ASP.NET Core Module.Kestrel.dotnet.exe, 后面我们会理清楚这三个组件的作用和组件之间的交互原理. 引入Kestrel的原因 进程内HTTP服务器,与老牌web服务器解耦,实现跨平台部署 IIS.Nginx.Apache等老牌web服务器有他们自己的启动进程和环境:为了实现跨平台部署

Windows Server 2008 R2 + IIS 环境部署Asp.Net Core App

环境:Windows Server 2012, IIS 8, Asp.Net Core 1.1. 不少人第一次在IIS中部署Asp.Net Core App的人都会遇到问题,会发现原来的部署方式无法运行Asp.Net Core App程序.过去无论是原始的Asp程序还是后来的Asp.Net程序,在IIS中的部署方式都没太大变化,仅需指向程序目录,然后设定虚拟目录,最后做一些参数配置.Asp.Net Core App为了做到跨平台,自带了一个轻量级的Web Server - Kestrel,那么要

修改 ASP.NET 请求队列的限制

查询 ASP.NET 时,服务的请求将通过 Internet Information Services (IIS) 和 ASP.NET 工作进程之间的管道来传递,并且在该管道内排队.(ASP.NET 在自己的进程中运行 - 这一点不同于传统的 ASP,传统的 ASP 与 IIS 服务在同一个进程中运行.)默认情况下,此队列最多可以包含 5,000 个请求.如果请求超过 5,000 个,则用户将收到“503 - 服务不可用”错误,并被拒绝服务. 尽管默认值对于相对数目较少的 Communicato