各版本IIS下ASP.net请求处理过程区别第1/3页_win服务器

绝大多数的人只熟悉高层的框架如: WebForms 和 WebServices --这些都在ASP.NET层次结构在最高层。

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

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:  指能够处理各种后缀名的应用程序。 ISAPI 是下面单词的简写 :Internet Server Application Programe Interface,互联网服务器应用程序接口。

IIS 5 模式的特点:

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

IIS6 的 ASP.net 请求处理过程

对图的解释:

IIS 5.x 是通过 InetInfo.exe 监听 Request 并把Request分发到Work 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。

当前1/3页 123下一页阅读全文

时间: 2024-10-21 23:29:16

各版本IIS下ASP.net请求处理过程区别第1/3页_win服务器的相关文章

各版本IIS下ASP.net请求处理过程分析第1/3页_win服务器

绝大多数的人只熟悉高层的框架如: WebForms 和 WebServices --这些都在ASP.NET层次结构在最高层. 这篇文章的资料收集整理自各种微软公开的文档,通过比较 IIS5.IIS6.IIS7 这三代 IIS 对请求的处理过程, 让我们熟悉 ASP.NET的底层机制 并对请求(request)是怎么从Web服务器传送到ASP.NET运行时有所了解.通过对底层机制的了解,可以让我们对 ASP.net 有更深的理解. IIS 5 的 ASP.net 请求处理过程 对图的解释: IIS

在IIS上启用Gzip压缩 (HTTP压缩)第1/3页_win服务器

一.摘要        本文总结了如何为使用IIS托管的网站启用Gzip压缩, 从而减少网页网络传输大小, 提高用户显示页面的速度. 二.前言.        本文的知识点是从互联网收集整理, 主要来源于中文wiki. 使用YSlow检测网站启用了哪些优化时, Gzip是十分关键的一项. 启动Gip压缩将立竿见影的减少页面的网络传输大小. 三.HTTP压缩概述        HTTP压缩是在Web服务器和浏览器间传输压缩文本内容的方法.HTTP压缩采用通用的压缩算法如gzip等压缩HTML.Ja

[转贴]IIS5、IIS6、IIS7的ASP.net 请求处理过程比较

原文:http://blog.joycode.com/ghj/archive/2008/07/25/115200.aspx ASP.NET是一个非常强大的构建Web应用的平台,它提供了极大的灵活性和能力以致于可以用它来构建所有类型的Web应用. 绝大多数的人只熟悉高层的框架如: WebForms 和 WebServices --这些都在ASP.NET层次结构在最高层. 这篇文章的资料收集整理自各种微软公开的文档,通过比较 IIS5.IIS6.IIS7 这三代 IIS 对请求的处理过程, 让我们熟

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

ASP.NET是一个非常强大的构建Web应用的平台,它提供了极大的灵活性和能力以致于可以用它来构建所有类型的Web应用. 绝大多数的人只熟悉高层的框架如: WebForms和 WebServices --这些都在ASP.NET层次结构在最高层. 这篇文章的资料收集整理自各种微软公开的文档,通过比较IIS5.IIS6.IIS7这三代IIS对请求的处理过程,让我们熟悉ASP.NET的底层机制并对请求(request)是怎么从Web服务器传送到ASP.NET运行时有所了解.通过对底层机制的了解,可以让

安全维护 IIS下 ASP 站点的高级技巧_服务器

一. 前言 (仅以此文感谢好友bigeagle.不是他,我可能不用这么担心win2000安全问题的.呵呵!) 人说,一朝被蛇咬,十年怕.....,就是这样.2000年初,当我终于摆脱winnt 4.0 server那可怕的补丁之旅,迈向win2000 server时.我终于可以比较放心我的服务器了.但随着SQL SERVER的补丁出现.我知道,与微软的补丁因缘又开始轮回了.但还好.win2000自动化的管理还是让我放心好多,而以前管理winnt后的失眠症状也逐渐消失了.偶尔还能见到我的"梦&qu

windows下使用IIS配置的PHP无法上传文件的解决方法_win服务器

延续<Windows Server 2003中iis配置php>一文 服务器上使用Apache2+PHP正常运行,换成IIS+PHP,先后出现了php.ini的环境变量无法读取,php中验证码无法显示的问题,如今又有人反应无法上传图片的问题. 从IIS替换Apache2的过程仅仅是开启IIS,关闭Apache2,其它的没什么变化,但是却发生了如此多的差异,看样子IIS支持PHP还是有很多要进行修改的. 分析: 根据上面的描述,我怀疑问题出在IIS的权限配置上,IUSR_MACHINE的帐户对u

IIS+FastCGI+PHP5.3+MySQL5.1+Gzip配置图文详细教程_win服务器

说明: 本帖是我经过一天一夜完成的,不同于一般网上文章,除详细的将整个配置过程和 测试过程都详细截图说明外,尤其在FastCGI方面采用微软的"web平台安装程序"来配置,网上相关内容很少,对gzip的设置也很详细,保证按图操 作即可独立完成.另外,还有详细的测试gzip压缩率的方法和比较. 文中对于理论几乎没有阐述,只是对配置过程进行了最详细的介绍,这样 使新手即使不太明白,照本文也可以配置出一样的环境来,本文章的错误及疏漏之处,还请大家指出来,大家在配置中有何问题,我们一起来探讨解

IIS下ASP目录漏洞和IIS分号漏洞(;)的临时解决方法_win服务器

解决方法: 下载 银月服务器工具,使用工具->组件下载器下载ISAPI_Rewrite,解压出来. 把ISAPI_Rewrite中的ISAPI_Rewrite.dll添加为ISAPI,名字为ISAPI_Rewrite,这就是伪静态,做过的不用安装了 下载漏洞补丁包,即下图选择的项目,下载打开! 把ISAPI_Rewrite目录中的httpd.ini替换成补丁包中的httpd.ini. 或者保证ISAPI_Rewrite下面的httpd.ini有下图选择的两行规则也行!这样就能防止这两个IIS漏洞

win8下IIS 8.5下设置404错误页_win服务器

IIS版本:IIS 8.5问题描述 搭建一个测试网站,总共就2个页面(index.php和404.php),默认首页为:index.php 当访问index.php和404.php的时候,IIS服务器能正常响应,说明在IIS 8.5中配置PHP环境没有出现问题.访问index.php 访问404.php 另外,我的错误页配置结果如下: 正常情况下,当访问某个不存在的页面时(比如:127.0.0.1/aaa.php),此时,iis服务器发现aaa.php这个文件并不存在,所以,应该会请求404.p