微软网站设计,鹤壁市城乡一体化示范区邮编,长沙网络营销外包,手机制作视频[ 转] ASP.NET Process Model之一#xff1a;IIS 和 ASP.NET ISAPI 前几天有一个朋友在MSN上问我“ASP.NET 从最初的接收到Http request到最终生成Response的整个流程到底是怎样的#xff1f;”我觉得这个问题涉及到IIS和ASP.NETASP.NET Runtime的处理模型的问题#xff0c;…[ 转] ASP.NET Process Model之一IIS 和 ASP.NET ISAPI 前几天有一个朋友在MSN上问我“ASP.NET 从最初的接收到Http request到最终生成Response的整个流程到底是怎样的”我觉得这个问题涉及到IIS和ASP.NETASP.NET Runtime的处理模型的问题并不是三言两语就能说清楚的所以决定写这样一篇介绍IIS和ASP.NET Runtime Process Model的文章谈谈我对此的一个粗浅的认识如果有什么不对的地方希望大家及时指正。 这篇文章大体分为两个部分第一部分我将谈谈IIS的两个不同的版本—IIS 5.x 和 IIS 6虽然IIS 7已经Release很长时间了而且较之前两个版本发生了非常大的变化由于本人缺乏对IIS 7深入的了解所以在这里就不再介绍了不过以后我将这方面的内容补上的处理模型IIS如何监听来自外界的Http request如何根据ISAPI Extension Mapping将对于不同Resource的请求分发给不同的ISAPI Extension基于ASP.NET Resource的ASP.NET ISAPI如何将Request传递给ASP.NET Runtime 环境。第二部分将着重介绍在一个托管的ASP.NET Runtime 环境对传入的Http request的处理过程。我们先来看看IIS 5.x和IIS 6的处理过程。 1 一、IIS 5.x based Process Model 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所以这是一个托管的环境。我们接下来将谈论aspnet_wp如何创建aspnet_wp和InetInfo.exe如何进行通信以及简单介绍在aspnet_wp中如何将Request 导入ASP.NET Rutime Pipeline。 我们通过创建虚拟目录将资源Host到IIS下原则上我们可以通过IIS访问置于虚拟目录下的所有Resource这部仅仅包含一些静态资源文件比如图片、纯Html文件、CSS、JS等等也包含一些需要动态执行的文件比如aspxasmx等等我们还可以将Remoting和WCF Service Host到IIS下。对于这些静态的文件IIS直接提取对应的文件将其作为Http Response返回给Client但是对于这些需要进一步处理的动态执行的文件IIS必须将Request进一步传递给对应的处理程序待处理程序执行完毕获得最终的Http Response通过IIS返回给Client。对于IIS来说这些处理程序通过ISAPI Extension来体现。对于基于ASP.NET的Resource其对应的ISAPI Extension为ASP.NET ISAPI通过一个aspnet_isapi.dll承载。IIS的Metadata database维护着一个称为ISAPI Extension Mapping的数据表负责将不同类型的Resource影射到对应的ISAPI Extension。 上图像我们展示了IIS 5.x如何处理一个基于ASP.NET Resource以aspx为例的Http Request的大体流程。首先用户通过Browser请求一个aspx pageBrower向对于得Web Server也就是目标主机的IIS。在上面我们提到过IIS运行在一个称为InetInfo.exe的进程中InetInfo.exe是一个Native Executive并非一个托管的程序。IIS分析Request的目标资源文件的扩展名这里是aspx通过ISAPI Extension Mapping获知对应的ISPAI为ASP.NET ISAPI,于是加载aspnet_isapi.dll。到此为止该Request的处理交由ASP.NET ISAPI,处理。ASP.NET ISAPI会创建一个叫做aspnet_wp.exe的Worker Process如果该进程不存在的话在aspnet_wp.exe初始化的时候会加载CLR从而为ASP.NET Application创建一个托管的运行环境在CLR初始化的使用会加载两个重要的dllAppManagerAppDomainFactory和ISAPIRuntime。通过AppManagerAppDomainFactory的Create方法为Application创建一个Application Domain通过ISAPIRuntime的ProcessRequest处理Request进而将流程拖入到ASP.NET Http Runtime Pipeline的范畴ASP.NET Http Runtime Pipeline对Http Request的处理是一个相对复杂的过程相关的介绍会放在本篇文章的下一部份。在这里我们可以把它看成是一个黑盒它接管Request最终生成Html。 这基本上就是整个处理流程很简单。不过在这里有几点需要特别指出的。 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的变量。 2 二、IIS 6 based Process Model Reliability 和Performance永远是我们从事软件开发不变的主题。作为Host 基于Http Application的IIS来说这两方面就显得尤为重要了。我们从IIS 5.x到IIS 6 的演变不难看出IIS 6在前一个版本基础上所作的改进也是基于这两个方面。在介绍IIS 6的处理模型之前我们先看看IIS 5.x都什么样缺陷 1. 首先从Performance上看IIS和application运行在不同的进程中虽然他们之间采用了基于Named Pipe的异步通信方式但是一个基于进程之间的通信对性能的影响确实不能从根本上解决。 2. 其次从Reliability来考虑一台机器上只能运行一个worker process每个Application运行在同一个进程中虽然基于Application Domain的隔离能提供一定的Reliability但是一旦真个进程崩溃所有的Application都受影响。所以我们有时候需要提供一个基于Process的隔离性。 基于Reliability的改进IIS 6引入了Application Pool。顾名思义Application Pool就是一个application的容器在IIS 6中我们可以创建若干Application Pool在创建Web Application的时候我们为它指定一个既定的application pool。在运行的时候一个Application pool对应一个Worker Processw3wp.exe。也就是说和前一个版本的IIS不同的是对于IIS 6来说同一台机器上可以同时运行多个Worker Process每个Worker Process中的每个Application domain对应一个Application。这样Application之间不但能提供Application Domain级别的隔离你也可以将不同的Application置于不同的Application Pool中从而基于Process级别的隔离。对于Host 一些重要的Application来说这样的方式可以提供很好的Reliability。 在Performance方面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和Kernel Mode以及一些Windows底层的一些内容推荐大家看看《Microsoft Windows Internal》Four Edition Authored by Mark E.Russinovich David A. Solomon。 上图基本上演示了IIS 6整个处理过程。在Kernel Mode下http.sys接收到一个基于aspx的http request然后它会根据IIS中的Metabase查看该基于该Request的Application属于哪个Application Pool如果该Application Pool不存在则创建之。否则直接将request发到对应Application Pool的Queue中。我上面已经说了每个Application Pool对应着一个Worker Processw3wp.exe毫无疑问他是运行在User Mode下的。在IIS Metabase中维护着Application Pool和worker process的Mapping。WASWeb Administrative service根据这样一个mapping将存在于某个Application Pool Queue的request 传递到对应的worker process(如果没有就创建这样一个进程)。在worker process初始化的时候加载ASP.NET ISAPIASP.NET ISAPI进而加载CLR。最后的流程就和IIS 5.x一样了通过AppManagerAppDomainFactory的Create方法为Application创建一个Application Domain通过ISAPIRuntime的ProcessRequest处理Request进而将流程进入到ASP.NET Http Runtime Pipeline。 对IIS Process Model部分就介绍到这里在下部分中我将介绍ASP.NET Http Runtime Pipeline。Reference: The ASP.NET HTTP Runtime ASP.NET Internals – IIS and the Process Model ASP.NET Internals - The bridge between ISAPI and Application Domains Microsoft® Windows® Internals, Fourth Edition: Microsoft Windows Server™ 2003, Windows XP, and Windows 2000 转载于:https://www.cnblogs.com/jenneyblog/archive/2013/03/13/IIS5_and_IIS6_ProcessModel.html
