ASP.NET是一个非常强大的构建Web应用的平台，它提供了极大的灵活性和能力以致于可以用它来构建所有类型的Web应用。

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

　　这篇文章的资料收集整理自各种微软公开的文档，通过比较IIS5、IIS6、IIS7这三代IIS对请求的处理过程，让我们熟悉ASP.NET的底层机制并对请求(request)是怎么从Web服务器传送到ASP.NET运行时有所了解。通过对底层机制的了解，可以让我们对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，互联网服务器应用程序接口。

　　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的变量。

　　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。

　　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运行在他们各自的进程中，他们之间的通信必须采用特定