知识大全比较IIS5、IIS6、IIS7的ASP.net请求处理过程

Posted 2022-07-17 知

篇首语：须知少年凌云志，曾许人间第一流。本文由小常识网(cha138.com)小编为大家整理，主要介绍了知识大全比较IIS5、IIS6、IIS7的ASP.net请求处理过程相关的知识，希望对你有一定的参考价值。

比较IIS5、IIS6、IIS7的ASP.net请求处理过程 以下文字资料是由(全榜网网www.cha138.com)小编为大家搜集整理后发布的内容，让我们赶快一起来看一下吧！

SP NET是一个非常强大的构建Web应用的平台它提供了极大的灵活性和能力以致于可以用它来构建所有类型的Web应用绝大多数的人只熟悉高层的框架如 WebForms 和 WebServices 这些都在ASP NET层次结构在最高层

　　这篇文章的资料收集整理自各种微软公开的文档通过比较 IIS IIS IIS 这三代 IIS 对请求的处理过程让我们熟悉 ASP NET的底层机制并对请求(request)是怎么从Web服务器传送到ASP NET运行时有所了解通过对底层机制的了解可以让我们对有更深的理解

　　IIS 的请求处理过程

　　对图的解释

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

　　ISAPI 指能够处理各种后缀名的应用程序 ISAPI 是下面单词的简写 Internet Server Application Programe Interface 互联网服务器应用程序接口

　　IIS 模式的特点

　　首先同一台主机上在同一时间只能运行一个 aspnet_wp 进程每个基于虚拟目录的 ASP NET Application 对应一个 Application Domain 也就是说每个 Application 都运行在同一个 Worker Process 中 Application之间的隔离是基于 Application Domain 的而不是基于Process的　　　其次 ASP NET ISAPI 不但负责创建 aspnet_wp Worker Process 而且负责监控该进程如果检测到 aspnet_wp 的 Performance 降低到某个设定的下限 ASP NET ISAPI 会负责结束掉该进程当 aspnet_wp 结束掉之后后续的 Request 会导致ASP NET ISAPI 重新创建新的 aspnet_wp Worker Process

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

　　IIS 的请求处理过程

　　对图的解释

　　IIS x 是通过 InetInfo exe 监听 Request 并把Request分发到Work Process 换句话说在IIS x中对Request的监听和分发是在User Mode中进行在IIS 中这种工作被移植到kernel Mode中进行所有的这一切都是通过一个新的组件 sys 来负责　　　注为了避免用户应用程序访问或者修改关键的操作系统数据 windows提供了两种处理器访问模式用户模式（User Mode）和内核模式（Kernel Mode）一般地用户程序运行在User mode下而操作系统代码运行在Kernel Mode下 Kernel Mode的代码允许访问所有系统内存和所有CPU指令　　　在User Mode下 sys接收到一个基于 aspx 的 request 然后它会根据IIS中的 Metabase 查看该基于该 Request 的 Application 属于哪个Application Pool 如果该Application Pool不存在则创建之否则直接将 request 发到对应Application Pool 的 Queue中　　　每个 Application Pool 对应着一个Worker Process w wp 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 x一样了通过AppManagerAppDomainFactory 的 Create方法为 Application 创建一个Application Domain 通过 ISAPIRuntime 的 ProcessRequest处理Request 进而将流程进入到ASP NET Http Runtime Pipeline

　　IIS 的请求处理过程

　　IIS 站点启动并处理请求的步骤如下图

　　步骤到是处理应用启动启动好后以后就不需要再走这个步骤了

IIS 的请求处理过程

　　上图的个步骤分别如下

　　当客户端浏览器开始HTTP 请求一个WEB 服务器的资源时 HTTP sys 拦截到这个请求 HTTP sys contacts WAS to obtain information from the configuration store

　　 WAS 向配置存储中心请求配置信息 nfig WWW 服务接受到配置信息配置信息指类似应用程序池配置信息站点配置信息等等 WWW 服务使用配置信息去配置 HTTP sys 处理策略 WAS starts a worker process for the application pool to which the request was made

　　 The worker process processes the request and returns a response to HTTP sys

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

　　W WP exe 进程中又是如果处理得呢？？ IIS 的应用程序池的托管管道模式分两种经典和集成这两种模式下处理策略各不相通

　　IIS 以及 IIS 经典模式的托管管道的架构

　　在IIS 之前 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 下图是这个架构的示意图

IIS 的执行架构图以及IIS 应用程序池配置成经典模式的执行架构图

　　IIS 应用程序池的托管管道模式经典模式也是这样的工作原理这种模式是兼容IIS 的方式以减少升级的成本

　　IIS 应用程序池的托管管道模式集成模式

IIS 的执行架构图（集成托管信道模式下的架构）

　　小结

　　IIS 到 IIS 的改进主要是 HTTP sys 的改进

cha138/Article/program/net/201311/13216

知识大全 比较IIS5、IIS6、IIS7的ASP.net请求处理过程

知识大全比较IIS5、IIS6、IIS7的ASP.net请求处理过程