ASP.NET是如何在IIS下工作的

逃离我推掉我的手 2022-01-11 19:05 184阅读 0赞

ASP.NET与IIS是紧密联系的，由于IIS6.0与IIS7.0的工作方式的不同，导致ASP.NET的工作原理也发生了相应的变化。

IIS6(IIS7的经典模式)与IIS7的集成模式的不同

IIS6的运行过程：

[![IIS6运行图示][IIS6]][IIS6_IIS6]

分析上图可知：

在 User Mode 下，http.sys 接收到 http request，然后它会根据 IIS 中的 Metabase 查看基于该 Request 的 Application 属于哪个 Application Pool， 如果该 Application Pool 不存在，则创建之。否则直接将 request 发到对应 Application Pool 的 Queue中。每个 Application Pool 对应着一个 Worker Process — w3wp.exe，(运行在 User Mode 下)。

在 IIS Metabase 中维护着 Application Pool 和 Worker Process 的Mapping。WAS（Web Administrative Service）根据这样一个 mapping，将存在于某个 Application Pool Queue 的 request 传递到对应的 Worker Process (如果没有，就创建这样一个进程)。在 Worker Process 初始化的时候，加载 ASP.NET ISAPI，ASP.NET ISAPI 进而加载 CLR。最后通过 AppManagerAppDomainFactory 的 Create 方法为 Application 创建一个 Application Domain；通过 ISAPIRuntime 的 ProcessRequest 处理 Request，进而将流程进入到 ASP.NET Http Runtime Pipeline。

几个知识点:

*  HTTP.SYS：（Kernel）的一个组件，它负责侦听（Listen）来自于外部的HTTP请求,根据请求的URL将其转发给相应的应用程序池 (Application Pool)。当此HTTP请求处理完成时，它又负责将处理结果发送出去.为了提供更好的性能，HTTP.SYS内部建立了一个缓冲区，将最近的HTTP请求处理结果保存起来。
 *  Application Pool: IIS总会保持一个单独的工作进程：应用程序池。所有的处理都发生在这个进程里，包括ISAPI dll的执行。对于IIS6而言，应用程序池是一个重大的改进，因为它们允许以更小的粒度控制一个指定进程的执行。你可以为每一个虚拟目录或者整个Web 站点配置应用程序池，这可以使你很容易的把每一个应用程序隔离到各自的进程里，这样就可以把它与运行在同一台机器上其他程序完全隔离。从Web处理的角度看，如果一个进程死掉，至少它不会影响到其它的进程。  
    当应用程序池接收到HTTP请求后，交由在此应用程序池中运行的工作者进程Worker Process: w3wp.exe来处理此HTTP请求。
 *  Worker Process: 当工作者进程接收到请求后，首先根据后缀找到并加载对应的ISAPI扩展 (如:aspx 对应的映射是aspnet\_isapi.dll)，工作者进程加载完aspnet\_isapi.dll后，由aspnet\_isapi.dll负责加载 ASP.NET应用程序的运行环境即CLR (.NET Runtime)。  
    Worker Process运行在非托管环境，而.NET中的对象则运行在托管环境之上(CLR)，它们之间的桥梁就是ISAPI扩展。
 *  WAS（Web Admin Service）：这是一个监控程序，它一方面可以存取放在InetInfo元数据库（Metabase）中的各种信息，另一方面也负责监控应用程序池（Application Pool）中的工作者进程的工作状态况，必要时它会关闭一个老的工作者进程并创建一个新的取而代之。

IIS7的运行过程：

[![IIS7运行图示][IIS7]][IIS7_IIS7]

分析上图可知：

1、当客户端浏览器开始 HTTP 请求一个WEB 服务器的资源时，HTTP.sys 拦截到这个请求。

2、HTTP.sys 联系 WAS 获取配置信息。

3、WAS 向配置存储中心(applicationHost.config)请求配置信息。

4、WWW 服务接收到配置信息，配置信息指类似应用程序池配置信息，站点配置信息等等。

5、WWW 服务使用配置信息去配置 HTTP.sys 处理策略。

6、WAS为请求创建一个进程(如果不存在的话)。

7、工作者进程处理请求并对HTTP.sys做出响应。

8、客户端接受到处理结果信息。

除了IIS的整体运行方式不同之外，IIS7相比IIS6最大的不同之处在于它提供了两种应用程序池管道模式：

经典模式：是与IIS 6或者之前版本保持兼容的一种模式，一个典型问题就是，在处理ASP.NET这种动态网站的时候，它是通过一个所谓的ISAPI程序，作为插件的方式来工作的。针对不同的动态应用程序(例如ASP,PHP等)，会需要不同的ISAPI（Internet Server Application Programe Interface，互联网服务器应用程序接口）。如图，在IIS中，打开“处理程序映射”，可以看到aspx类型页面的处理程序为aspnet\_isapi.dll。

[![经典模式处理程序映射][161322566822242.png]][161322566822242.png 1]

下图展示了IIS7经典模式与IIS6的应用程序池管道模式运行原理，针对不同的请求，会指定不同的ISAPI(dll)进行处理：

[![经典模式运行图][161337256198408.jpg]][161337256198408.jpg 1]

集成模式：asp.net不再像IIS6一样只限定于aspnet\_isapi.dll中，而是被解放出来，从IIS接收到HTTP请求开始，即进入asp.net的控制范围，asp.net可以存在于一个请求在IIS中各个处理阶段。允许我们将ASP.NET更好地与IIS集成，甚至允许我们在ASP.NET中编写一些功能（例如Module）来改变IIS的行为（扩 展）。集成的好处是，不再通过ISAPI的方式，提高了速度和稳定性。至于扩展，则可以使得我们对于IIS，以及其他类型的请求有更多的控制。（例如，我 们希望静态网页也具备一些特殊的行为）。如图

[![集成模式运行图][161337282442707.jpg]][161337282442707.jpg 1]

如下图在IIS7集成模式中，打开处理程序映射，可以看到aspx类型页面所对应的不再是一个dll，而是一个类型。

[![集成模式处理程序映射][161343232288356.png]][161343232288356.png 1]

总结与扩展：

对于处理ASP.NET应用程序而言，IIS6及IIS7的经典模式需要aspnet\_isapi.dll来处理，而IIS7集成模式不需要aspnet\_isapi.dll来处理，而可以直接根据文件扩展名找到相应的处理程序接口。例如aspx的处理程序是System.Web.UI.PageHandlerFactory类型。

介绍完IIS的工作原理，来看一下ASP.NET内部的运行机制。

首先看一下IIS处理模型：

[![image][]][image 1]

上面介绍IIS工作原理时，已经介绍了从发起HTTP请求，到响应请求的过程，这里主要介绍当请求到达.NET Runtime之后，.NET运行时所发生的一系列工作。

先看如下的.NET运行时工作序列图：

[![.net运行时序列图][.net]][.net_.net]

1.HTTP请求进入Web服务器后，首先由HTTP.SYS来判断请求的页面是否存在，如果存在的话将把请求信息转交给.NET Runtime。在这部分实际是完成两个步骤，在将请求转交给.NET Runtime的同时将请求信息封存在HTTPWorkRequest类中供其它步骤调用。HttpWorkRequest类在以后的操作中至关重要，它第一次将Http请求信息转换为类信息。  
2.当请求到达.NET Runtime后，接下来的操作将会在托管环境中完成，这时请求就真正进入了.NET中，对请求信息的操作是由.NET的底层类库来实现。首先.NET Runtime将会针对请求信息做两个动作，一是准备HostingEnvironment；二是调用ApplicationManager类为HTTP请求动态的分配AppDomain，并把处理权交给AppDomain。  
3.HTTP请求进入AppDomain后，将由对象ISAPIRuntime来接管，一方面经方法ProcessRequest()得到HttpWorkerRequest对象，另一方面由方法StartProcessing()生成HttpRuntime对象，接下来把处理权交给了HttpRuntime(HttpWorkerRequest对象将作为HttpRuntime方法中的参数被使用)。  
4.HTTPRuntime接收到Http请求后，方法ProcessRequest处理请求。将对第1步中的HTTPWorkRequest类中的信息进行操作，具体的实现由ProcessRequest方法实现。内部代码如下：

1.  \[AspNetHostingPermission(SecurityAction.Demand, Level=AspNetHostingPermissionLevel.Medium)\] 
2.  **public****static****void** ProcessRequest(HttpWorkerRequest wr) 
3.  \{ 
4.  **if** (wr == **null**) 
5.   \{ 
6.  **throw****new** ArgumentNullException("wr"); 
7.   \} 
8.  **if** (UseIntegratedPipeline) 
9.   \{ 
10. **throw****new** PlatformNotSupportedException(System.Web.SR.GetString("Method\_Not\_Supported\_By\_Iis\_Integrated\_Mode", **new****object**\[\] \{ "HttpRuntime.ProcessRequest" \})); 
11.  \} 
12.  ProcessRequestNoDemand(wr); 
13. \} 
14. **internal****static****void** ProcessRequestNoDemand(HttpWorkerRequest wr) 
15. \{ 
16.  RequestQueue queue = \_theRuntime.\_requestQueue; 
17. **if** (queue != **null**) 
18.  \{ 
19.  wr = queue.GetRequestToExecute(wr); 
20.  \} 
21. **if** (wr != **null**) 
22.  \{ 
23.  CalculateWaitTimeAndUpdatePerfCounter(wr); 
24.  wr.ResetStartTime(); 
25.  ProcessRequestNow(wr); 
26.  \} 
27. \} 
28. **internal****static****void** ProcessRequestNow(HttpWorkerRequest wr) 
29. \{ 
30.  \_theRuntime.ProcessRequestInternal(wr); 
31. \}

5.在HttpRunTime中经过一系列的驱动后，将会在ProcessRequestInternal方法中为Http请求分配应用程序。在这一步中还将创建HttpContext对象。

1.  context = **new** HttpContext(wr, **false**); // 基于HttpWorkerRequest生成HttpContext
2.  IHttpHandler applicationInstance = HttpApplicationFactory.GetApplicationInstance(context); // 得到HttpApplication
3.  handler2.BeginProcessRequest(context, **this**.\_handlerCompletionCallback, context); // 由HttpApplication处理请求

6.经过步骤5后HTTP请求信息才由基本信息转交给了Asp.net中的各个对象。接下来的操作会触发一些列的管道事件，这时的请求才真正转到HttpModule和HttpHandler中。  
接下来我们看看常说的管道事件的创建过程:

1.  **internal****override****void** BuildSteps(WaitCallback stepCallback) 
2.  \{ 
3.   ArrayList steps = **new** ArrayList(); 
4.   HttpApplication app = **base**.\_application; 
5.  **bool** flag = **false**; 
6.   UrlMappingsSection urlMappings = RuntimeConfig.GetConfig().UrlMappings; 
7.   flag = urlMappings.IsEnabled && (urlMappings.UrlMappings.Count > 0); 
8.   steps.Add(**new** HttpApplication.ValidatePathExecutionStep(app)); 
9.  **if** (flag) 
10.  \{ 
11.  steps.Add(**new** HttpApplication.UrlMappingsExecutionStep(app)); 
12.  \} 
13.  app.CreateEventExecutionSteps(HttpApplication.EventBeginRequest, steps); 
14.  app.CreateEventExecutionSteps(HttpApplication.EventAuthenticateRequest, steps); 
15.  app.CreateEventExecutionSteps(HttpApplication.EventDefaultAuthentication, steps); 
16.  app.CreateEventExecutionSteps(HttpApplication.EventPostAuthenticateRequest, steps); 
17.  app.CreateEventExecutionSteps(HttpApplication.EventAuthorizeRequest, steps); 
18.  app.CreateEventExecutionSteps(HttpApplication.EventPostAuthorizeRequest, steps); 
19.  app.CreateEventExecutionSteps(HttpApplication.EventResolveRequestCache, steps); 
20.  app.CreateEventExecutionSteps(HttpApplication.EventPostResolveRequestCache, steps); 
21.  steps.Add(**new** HttpApplication.MapHandlerExecutionStep(app)); 
22.  app.CreateEventExecutionSteps(HttpApplication.EventPostMapRequestHandler, steps); 
23.  app.CreateEventExecutionSteps(HttpApplication.EventAcquireRequestState, steps); 
24.  app.CreateEventExecutionSteps(HttpApplication.EventPostAcquireRequestState, steps); 
25.  app.CreateEventExecutionSteps(HttpApplication.EventPreRequestHandlerExecute, steps); 
26.  steps.Add(**new** HttpApplication.CallHandlerExecutionStep(app)); 
27.  app.CreateEventExecutionSteps(HttpApplication.EventPostRequestHandlerExecute, steps); 
28.  app.CreateEventExecutionSteps(HttpApplication.EventReleaseRequestState, steps); 
29.  app.CreateEventExecutionSteps(HttpApplication.EventPostReleaseRequestState, steps); 
30.  steps.Add(**new** HttpApplication.CallFilterExecutionStep(app)); 
31.  app.CreateEventExecutionSteps(HttpApplication.EventUpdateRequestCache, steps); 
32.  app.CreateEventExecutionSteps(HttpApplication.EventPostUpdateRequestCache, steps); 
33. **this**.\_endRequestStepIndex = steps.Count; 
34.  app.CreateEventExecutionSteps(HttpApplication.EventEndRequest, steps); 
35.  steps.Add(**new** HttpApplication.NoopExecutionStep()); 
36. **this**.\_execSteps = **new** HttpApplication.IExecutionStep\[steps.Count\]; 
37.  steps.CopyTo(**this**.\_execSteps); 
38. **this**.\_resumeStepsWaitCallback = stepCallback; 
39. \}

管道事件请求序列图如下：

[![管道][161608570255132.png]][161608570255132.png 1]

转载于:https://www.cnblogs.com/kevinGao/p/4188741.html

[IIS6]: https://images0.cnblogs.com/blog/273364/201404/161207272753366.png
[IIS6_IIS6]: /images/20220110/a000daf9cc9d4924bce9dc07a2ea009d.png
[IIS7]: https://images0.cnblogs.com/blog/273364/201404/161216481506049.png
[IIS7_IIS7]: /images/20220110/a8d56119677b44ec85a758115ed67823.png
[161322566822242.png]: https://images0.cnblogs.com/blog/273364/201404/161322566822242.png
[161322566822242.png 1]: /images/20220110/07f269def11c4d85afa57e07c42e608b.png
[161337256198408.jpg]: https://images0.cnblogs.com/blog/273364/201404/161337256198408.jpg
[161337256198408.jpg 1]: /images/20220110/00bb36b1e50d4911815005ab1830e5bd.png
[161337282442707.jpg]: https://images0.cnblogs.com/blog/273364/201404/161337282442707.jpg
[161337282442707.jpg 1]: /images/20220110/58720c19200c474d9d02cfbaf1f09e22.png
[161343232288356.png]: https://images0.cnblogs.com/blog/273364/201404/161343232288356.png
[161343232288356.png 1]: /images/20220110/311fcf6dc58a47f291158a2f9ab8d250.png
[image]: /images/20220110/d56a3a472faa444d8a3fdeeed2a2615a.png
[image 1]: https://images0.cnblogs.com/blog/273364/201404/161608439784385.png
[.net]: https://images0.cnblogs.com/blog/273364/201404/161608534007006.png
[.net_.net]: /images/20220110/63a929e53bcc489e9eeebe92a842325e.png
[161608570255132.png]: https://images0.cnblogs.com/blog/273364/201404/161608570255132.png
[161608570255132.png 1]: /images/20220110/1ca9f18a2dfa4fbc9fd33e579a4ad626.png