频道栏目
读书频道 > web开发 > .NET > .NET安全揭秘
3.2.3 ASP.NET Web窗体和Web Service
2012-10-24 16:30:33     我来说两句
收藏   我要投稿

本文所属图书 > .NET安全揭秘

全书共分为五个部分。第一部分:.NET安全基础,透彻讲解了.NET体系结构、程序集与反射、应用程序域和CLR寄宿等核心技术,这部分内容是.NET架构的核心,同时也是理解.NET底层安全机制的基础;第二部分:.NET平台安...  立即去当当网订购

对于ASP.NET的客户端请求,服务器端的工作进程是寄宿有CLR COM服务器的Windows进程。下面分别对三个版本的IIS对请求处理的过程做简要的分析。

1. IIS 5 的ASP.NET请求处理过程

图3-6展示了IIS 5的ASP.NET 请求处理过程。


 

IIS 5.x 一个显著的特征就是 Web Server 和真正的 ASP.NET Application 的分离。作为 Web Server 的IIS运行在一个名为 InetInfo.exe 的进程上,InetInfo.exe 是一个Native Executive,并不是一个托管的程序,而我们真正的 ASP.NET Application 则是运行在一个叫做 aspnet_wp 的 Worker Process 上面,在该进程初始化的时候会加载CLR,所以这是一个托管的环境。

ISAPI(Internet Server Application Program Interface,互联网服务器应用程序接口)是指能够处理各种后缀名的应用程序。

同一台主机上在同一时间只能运行一个 aspnet_wp 进程,每个基于虚拟目录的 ASP.NET Application 对应一个 Application Domain,也就是说每个 Application 都运行在同一个 Worker Process 中,Application之间的隔离是基于 Application Domain 的,而不是基于Process的。

由于 IIS 和 Application 运行在它们各自的进程中,它们之间的通信必须采用特定的通信机制。本质上 IIS 所在的 InetInfo 进程和 Worker Process 之间的通信是同一台机器不同进程的通信(Local Interprocess Communications),处于Performance的考虑,它们之间采用基于Named Pipe的通信机制。ASP.NET ISAPI和Worker Process之间的通信通过它们之间的一组Pipe实现。同样处于Performance的原因,ASP.NET ISAPI 通过异步的方式将Request 传到Worker Process 并获得 Response,但是 Worker Process 则是通过同步的方式向 ASP.NET ISAPI 获得一些基于 Server 的变量。

2. IIS 6 的ASP.NET请求处理过程

IIS 6 的 ASP.NET 请求处理过程如图3-7所示。

IIS 5.x 是通过 InetInfo.exe 监听 Request 并把Request分发到Worker Process的。换句话说,在IIS 5.x中,对Request的监听和分发是在User Mode中进行的,在IIS 6中,这种工作被移植到Kernel Mode中进行,这一切都是通过一个新的组件HTTP.sys 来负责的。


 

注意 为了避免用户应用程序访问或者修改关键的操作系统数据,Windows提供了两种处理器访问模式:用户模式(User Mode)和内核模式(Kernel Mode)。一般地,用户程序运行在User Mode下,而操作系统代码运行在Kernel Mode下。Kernel Mode的代码允许访问所有系统内存和所有CPU指令。

在User Mode下,http.sys接收到一个基于 ASPX 的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。最后的流程就和IIS 5.x一样了:通过AppManagerAppDomainFactory 的 Create方法为 Application 创建一个Application Domain;通过 ISAPIRuntime 的 ProcessRequest处理Request,进而使流程进入ASP.NET Http Runtime Pipeline。

3. IIS 7的ASP.NET请求处理过程

IIS 7的ASP.NET请求处理过程如图3-8所示。


 

提示 图3-8中的步骤 1~6 是处理应用启动,启动之后就无须再走这个步骤了。

上图的8个步骤分别如下:

步骤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  客户端接收到处理结果信息。

W3WP.exe 进程中又是如何处理的呢?IIS 7 的应用程序池的托管管道模式分两种: 经典和集成。这两种模式下处理策略各不相同。

4. IIS 6以及IIS 7经典模式的托管管道的架构

在IIS 7之前,ASP.NET 以 IIS ISAPI Extension 的方式外加到 IIS,其实包括 ASP 以及 PHP,也都以相同的方式配置(PHP 在 IIS 采用了两种配置方式,除了 IIS ISAPI Extension 的方式,也包括了 CGI 的方式,系统管理者能选择 PHP 程序的执行方式),因此客户端对 IIS 的 HTTP 请求会先经由 IIS 处理,然后 IIS 根据要求的内容类型,如果是 HTML 静态网页,就由 IIS 自行处理,如果不是,就根据要求的内容类型,分派给各自的 IIS ISAPI Extension;如果要求的内容类型是 ASP.NET,就分派给负责处理 ASP.NET 的 IIS ISAPI Extension,也就是 aspnet_isapi.dll。图3-9是这个架构的示意图。


 

IIS 7完全整合.NET 之后,架构的处理顺序有了很大的不同(如图3-10 所示)。最主要的原因就是 ASP.NET 从 IIS 插件(ISAPI Extension)的角色,进入了 IIS 核心,而且也能以 ASP.NET 模块负责处理 IIS 7 的诸多类型要求。这些 ASP.NET 模块不只能处理 ASP.NET 网页程序,也能处理其他如 ASP 程序、PHP 程序或静态 HTML 网页,也因为 ASP.NET 的诸多功能已经成为 IIS 7 的一部分,因此 ASP 程序、PHP 程序或静态 HTML 网页等类型的要求,也能使用像Forms认证或输出缓存(Output Cache)等 ASP.NET 2.0 的功能(但须修改 IIS 7 的设定值)。也因为 IIS 7 允许自行以 ASP.NET API 开发并加入模块,因此 ASP.NET 网页开发人员将更容易扩充 IIS 7 和网站应用程序的功能,甚至能自行以 .NET 编写管理 IIS 7 的程序(例如以程序控制 IIS 7 以建设网站或创建虚拟目录)。


 

您对本文章有什么意见或着疑问吗?请到论坛讨论您的关注和建议是我们前行的参考和动力  
上一篇:3.2.2 托管exe文件的加载和执行
下一篇:3.3 高级宿主控制
相关文章
图文推荐
排行
热门
最新书评
特别推荐

关于我们 | 联系我们 | 广告服务 | 投资合作 | 版权申明 | 在线帮助 | 网站地图 | 作品发布 | Vip技术培训 | 举报中心

版权所有: 红黑联盟--致力于做实用的IT技术学习网站