转自：http://www.cnblogs.com/artech/archive/2007/09/09/887528.html
?
??? 前几天有一个朋友在 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等等，也包含一些需要动态执行的文件，比如 aspx， asmx等等，我们还可以将 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 page， Brower向对于得 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初始化的使用会加载两个重要的 dll： AppManagerAppDomainFactory和 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对应一个 Worker Process： w3wp.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整个处理过程。在 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 Process Model部分就介绍到这里，在下部分中，我将介绍
ASP.NET Http Runtime
Pipeline。