【引自
Artech的博客】这篇文章大体分为两个部分，第一部分我将谈谈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的处理过程。
一、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。
 |
| 图1 |
上图向我们展示了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的变量。
