IIS 内部运行机制.docVIP

IIS 内部运行机制 　　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，