MVC系列(1)进入CLR

MVC之前的那点事儿系列,是笔者在2012年初阅读MVC3源码的时候整理的,主要讲述的是从HTTP请求道进入MVCHandler之前的内容,包括了原创,翻译,转载,整理等各类型文章,当然也参考了博客园多位大牛的文章,对此表示感谢,这次有时间贴出来,希望对大家有用。

主要内容

本文讲解的是:服务器接受Http Request请求之后,是如何进入.Net CLR,从而进一步操作的。

我们大家都知道,IIS必须先接受请求,然后才能有机会进入CLR,但对请求(request)是怎么从Web服务器传送到ASP.NET运行时的却不甚了解。IIS由于版本的不同,在进入CLR时候方式可能有所不同,本章节将就IIS5/6/7的三本版本的进入方式给予解释,通过对这些底层机制的了解,可以让我们对 ASP.net 有更深的理解。。

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

IIS5核心特征是:IIS是允许在一个叫InetInfo.exe的进程上的,所以无论是aspx页面还是html页面都是通过这个进程处理的,其中,由于aspx页面扩展名映射到了aspnet ISAPI.DLL上,所以如果页面是aspx的话,aspnet ISAPI.DLL则创建aspnet_wp这个Worker Process,并在初始化的时候加载CLR,所以这是一个托管的环境。

需要注意的几点是:

同一台服务器只能运行一个 aspnet_wp 进程,也就是说所有的ASP.NET Web Application都在同一个Worker Process 中,但是不意味着他们共享同一个context和数据库, ASP.NET里有个AppDomain的概念,每个站点或虚拟目录都对应一个单独的AppDomain,每个AppDomain是隔离的,有自己独立的 context上下文,所以安全没问题,所以我们的结论是:ASP.NET程序是继续AppDomain的,而不是基于Process的。

ASP.NET  ISAPI 不但负责创建 aspnet_wp Worker Process,而且负责监控该进程,如果检测到 aspnet_wp 的 Performance 降低到某个设定的下限,ASP.NET  ISAPI 将结束掉该进程,在Request来了以后,ASP.NET ISAPI 将重新创建新的 aspnet_wp Worker Process。

由于 IIS 和 Application 运行在他们各自的进程中,他们之间的通信必须采用特定的通信机制。由于之间的通信是同机器不同进程的通信(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 的变量。

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




转载请注明:http://www.shhjfk.com/pxxx/pxxx/21.html