IIS5 IIS6 IIS7区别

ASP.NET是一个非常强大的构建Web应用的平台,它提供了极大的灵活性和能力以致于可以用它来构建所有类型的Web应用。 
绝大多数的人只熟悉高层的框架如: 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。

IIS 7 的 ASP.net 请求处理过程

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

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


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

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

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

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

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

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

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

在IIS7之前,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 7 应用程序池的 托管管道模式 经典 模式也是这样的工作原理。 这种模式是兼容IIS 6 的方式, 以减少升级的成本。

 

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

 

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

       而 IIS 7 完全整合 .NET 之后,架构的处理顺序有了很大的不同(如下图),最主要的原因就是 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认证(Forms Authentication)或输出缓存(Output Cache)等 ASP.NET 2.0 的功能(但须修改 IIS 7 的设定值)。也因为 IIS 7 允许自行以 ASP.NET API 开发并加入模块,因此 ASP.NET 网页开发人员将更容易扩充 IIS 7 和网站应用程序的功能,甚至能自行以 .NET 编写管理 IIS 7 的程序(例如以程控 IIS 7 以建置网站或虚拟目录)。

 

IIS 7 的执行架构图(集成托管信道模式下的架构)

小结

IIS5 到 IIS6 的改进,主要是 HTTP.sys 的改进。

IIS6 到 IIS7 的改进,主要是 ISAPI 的改进。



  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 3
    评论
提取出的文件目录表,仅供参考: ACHG.AS_ ACWEBSVC.DL_ ADMWPROX.DL_ ADROT.DL_ ADSIIS.DL_ ADSUTIL.VB_ AEXP2B.AS_ AEXP4B.AS_ APPS.CH_ APPS.IN_ APPSRV.MS_ APPSTAR2.AN_ APPSTAR3.AN_ APPSTART.AN_ APPS_SP.CH_ APPWIZ.CP_ ASP.DL_ ASP.MF_ ASP.MO_ ASPNETOC.DL_ ASPPERF.DL_ ASPSTD.IN_ AXCTRNM.H2_ AXPERF.IN_ BROWSCAP.DL_ BROWSCAP.IN_ CERTCARC.AS_ CERTCKPN.AS_ CERTDFLT.AS_ CERTFNSH.AS_ CERTLYNX.AS_ CERTMAP.OC_ CERTOBJ.DL_ CERTRMPN.AS_ CERTRQAD.AS_ CERTRQBI.AS_ CERTRQMA.AS_ CERTRQUS.AS_ CERTRQXT.AS_ CERTRSDN.AS_ CERTRSER.AS_ CERTRSIS.AS_ CERTRSOB.AS_ CERTRSPN.AS_ CERTSCES.AS_ CERTWIZ.OC_ CIMWIN32.MF_ CIMWIN32.MO_ CLI.MO_ CLIEGALI.MF_ CLIEGALI.MO_ CLUSWMI.MO_ CNFGPRTS.OC_ COADMIN.DL_ CONTROT.DL_ CONVLOG.EX_ DAVCDATA.EX_ DAVCPROX.DL_ DNSETW.MO_ DNSPROV.MO_ DSPROV.MF_ DSPROV.MO_ EVNTRPRV.MO_ EVTGPROV.MO_ EXSTRACE.DL_ FTP.EX_ FTP.MI_ FTPCTRS.H2_ FTPCTRS.IN_ FTPCTRS2.DL_ FTPMIB.DL_ FTPSVC2.DL_ GZIP.DL_ HNETCFG.MO_ HTTP.MI_ HTTP.SY_ HTTPAPI.DL_ HTTPEXT.DL_ HTTPMIB.DL_ HTTPODBC.DL_ IEINFO5.MO_ IIRSP.SY_ IIS.DL_ IIS.IN_ IIS.MS_ IIS6.CAB IISADMIN.DL_ IISADMIN.MF_ IISADMIN.MO_ IISAPP.VB_ IISBACK.VB_ IISCFG.DL_ IISCLEX4.DL_ IISCNFG.VB_ IISDG.CH_ IISEXT.DL_ IISEXT.VB_ IISFTP.VB_ IISFTPDR.VB_ IISLOG.DL_ IISMAP.DL_ IISMUI.DL_ IISNTS.CH_ IISPWCHG.DL_ IISRES.DL_ IISRESET.EX_ IISRG.CH_ IISRSTAP.DL_ IISRSTAS.EX_ IISRTL.DL_ IISSCHLP.WS_ IISSMMC.CH_ IISSUBA.DL_ IISUI.DL_ IISUIOBJ.DL_ IISUTIL.DL_ IISVDIR.VB_ IISW3ADM.DL_ IISWEB.VB_ IISWMI.DL_ IISWMI.MF_ IISWMI.MO_ IKCH8XX.IN_ ILS.DL_ INETCFG.DL_ INETCOMM.DL_ INETCORP.AD_ INETCPL.CP_ INETCPLC.DL_ INETFIND.XM_ INETINFO.EX_ INETMGR.DL_ INETMGR.EX_ INETMIB1.DL_ INETOPTS.XM_ INETPP.DL_ INETPPUI.DL_ INETPREF.XM_ INETRES.AD_ INETRES.CH_ INETRES.DL_ INETSET.AD_ INETSRCH.XM_ INETSRV.MI_ INFOADMN.DL_ INFOCOMM.DL_ INFOCTRS.DL_ INFOCTRS.H2_ INFOCTRS.IN_ INFOSOFT.DL_ INFOSPBZ.BM_ INFOSPCE.BM_ IPP_0001.AS_ IPP_0002.AS_ IPP_0003.AS_ IPP_0004.AS_ IPP_0005.AS_ IPP_0006.AS_ IPP_0007.AS_ IPP_0010.AS_ IPP_0013.AS_ IPP_0014.AS_ IPP_0015.AS_ ISAPIPS.DL_ ISATQ.DL_ ISCOMLOG.DL_ KRNLPROV.MF_ KRNLPROV.MO_ LICWMI.MF_ LICWMI.MO_ LOGSCRPT.DL_ LOGTEMP.SQ_ LOGUI.OC_ LONSINT.DL_ METADATA.DL_ MSDTCTR.MO_ MSI.MF_ MSI.MO_ MSMQTRC.MO_ NCPROV.MF_ NCPROV.MO_ NEXTLINK.DL_ NLBMPROV.MO_ NNTPADM.DL_ NNTPAPI.DL_ NNTPSNAP.CN_ NNTPSNAP.DL_ NNTPSNAP.HL_ NTEVT.MF_ NTEVT.MO_ P3CMINC.AS_ P3DM.AS_ P3DMDEL.AS_ P3DMLOCK.AS_ P3DMNEW.AS_ P3MB.AS_ P3MBDEL.AS_ P3MBGOTO.AS_ P3MBLOCK.AS_ P3MBNEW.AS_ P3MSPROP.AS_ PAGE1.AS_ POLICMAN.MF_ POLICMAN.MO_ REGEVENT.MF_ REGEVENT.MO_ REPLPROV.MO_ RPCREF.DL_ RSOP.MF_ RSOP.MO_ RWINSTA.EX_ RWNH.DL_ SCERSOP.MO_ SCM.MO_ SCRCONS.MF_ SCRCONS.MO_ SECRCW32.MF_ SECRCW32.MO_ SEO.DL_ SMTPADM.DL_ SMTPAPI.DL_ SMTPCONS.DL_ SMTPCONS.MF_ SMTPCONS.MO_ SMTPSNAP.CN_ SMTPSNAP.DL_ SMTPSNAP.HL_ SNMPREG.MO_ SNMPSMIR.MO_ SSINC.DL_ STAXMEM.DL_ SUBSCRPT.MO_ SVCEXT.DL_ SYSTEM.MO_ TRUSTMON.MO_ TSCFGWMI.MF_ TSCFGWMI.MO_ UIHELPER.DL_ URL.DL_ URLAUTH.DL_ URLMON.DL_ VDS.MF_ VDS.MO_ VSS.MF_ VSS.MO_ W3CACHE.DL_ W3COMLOG.DL_ W3CORE.DL_ W3CORE.MF_ W3CORE.MO_ W3CTRLPS.DL_ W3CTRS.DL_ W3CTRS.H2_ W3CTRS.IN_ W3DT.DL_ W3DT.MF_ W3DT.MO_ W3EXT.DL_ W3ISAPI.DL_ W3ISAPI.MF_ W3ISAPI.MO_ W3SSL.DL_ W3TP.DL_ W3WP.EX_ WAM.DL_ WAMPS.DL_ WAMREG.DL_ WAMREGPS.DL_ WBEMCONS.MF_ WBEMCONS.MO_ WHQLPROV.MO_ WINOLDAP.MO_ WLBSPROV.MF_ WLBSPROV.MO_ WMI.MF_ WMI.MO_ WMIPCIMA.MF_ WMIPCIMA.MO_ WMIPDFS.MF_ WMIPDFS.MO_ WMIPDSKQ.MF_ WMIPDSKQ.MO_ WMIPICMP.MF_ WMIPICMP.MO_ WMIPIPRT.MF_ WMIPIPRT.MO_ WMIPJOBJ.MF_ WMIPJOBJ.MO_ WMIPSESS.MF_ WMIPSESS.MO_ WMITIMEP.MF_ WMITIMEP.MO_

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值