SP
NET是一个非常强大的构建Web应用的平台
它提供了极大的灵活性和能力以致于可以用它来构建所有类型的Web应用
绝大多数的人只熟悉高层的框架如 WebForms 和 WebServices 这些都在ASPNET层次结构在最高层
这篇文章的资料收集整理自各种微软公开的文档通过比较 IISIISIIS 这三代 IIS 对请求的处理过程 让我们熟悉 ASPNET的底层机制 并对请求(request)是怎么从Web服务器传送到ASPNET运行时有所了解通过对底层机制的了解可以让我们对 有更深的理解
IIS 的 请求处理过程
IIS
的请求处理过程
对图的解释
IIS x 一个显着的特征就是 Web Server 和真正的 ASPNET Application 的分离作为 Web Server 的IIS运行在一个名为 InetInfoexe 的进程上InetInfoexe 是一个Native Executive并不是一个托管的程序而我们真正的 ASPNET Application 则是运行在一个叫做 aspnet_wp 的 Worker Process 上面在该进程初始化的时候会加载CLR所以这是一个托管的环境
ISAPI 指能够处理各种后缀名的应用程序 ISAPI 是下面单词的简写 Internet Server Application Programe Interface互联网服务器应用程序接口
IIS 模式的特点
首先同一台主机上在同一时间只能运行一个 aspnet_wp 进程每个基于虚拟目录的 ASPNET Application 对应一个 Application Domain 也就是说每个 Application 都运行在同一个 Worker Process 中Application之间的隔离是基于 Application Domain 的而不是基于Process的
其次ASPNET ISAPI 不但负责创建 aspnet_wp Worker Process而且负责监控该进程如果检测到 aspnet_wp 的 Performance 降低到某个设定的下限ASPNET ISAPI 会负责结束掉该进程当 aspnet_wp 结束掉之后后续的 Request 会导致ASPNET ISAPI 重新创建新的 aspnet_wp Worker Process
最后由于 IIS 和 Application 运行在他们各自的进程中他们之间的通信必须采用特定的通信机制本质上 IIS 所在的 InetInfo 进程和 Worker Process 之间的通信是同一台机器不同进程的通信（local interprocess communications）处于Performance的考虑他们之间采用基于Named pipe的通信机制ASPNET ISAPI和Worker Process之间的通信通过他们之间的一组Pipe实现同样处于Performance的原因ASPNET ISAPI 通过异步的方式将Request 传到Worker Process 并获得 Response但是 Worker Process 则是通过同步的方式向 ASPNET ISAPI 获得一些基于 Server 的变量
IIS 的 请求处理过程
IIS
的 请求处理过程
对图的解释
IIS x 是通过 InetInfoexe 监听 Request 并把Request分发到Work Process换句话说在IIS x中对Request的监听和分发是在User Mode中进行在IIS 中这种工作被移植到kernel Mode中进行所有的这一切都是通过一个新的组件httpsys 来负责
注为了避免用户应用程序访问或者修改关键的操作系统数据windows提供了两种处理器访问模式用户模式（User Mode）和内核模式（Kernel Mode）一般地用户程序运行在User mode下而操作系统代码运行在Kernel Mode下Kernel Mode的代码允许访问所有系统内存和所有CPU指令
在User Mode下httpsys接收到一个基于 aspx 的http request然后它会根据IIS中的 Metabase 查看该基于该 Request 的 Application 属于哪个Application Pool 如果该Application Pool不存在则创建之否则直接将 request 发到对应Application Pool 的 Queue中
每个 Application Pool 对应着一个Worker Processwwpexe毫无疑问他是运行在User Mode下的在IIS Metabase 中维护着 Application Pool 和worker process的MappingWAS（Web Administrative service）根据这样一个mapping将存在于某个Application Pool Queue的request 传递到对应的worker process（如果没有就创建这样一个进程）在 worker process 初始化的时候加载ASPNET ISAPIASPNET ISAPI 进而加载CLR最后的流程就和IIS x一样了通过AppManagerAppDomainFactory 的 Create方法为 Application 创建一个Application Domain通过 ISAPIRuntime 的 ProcessRequest处理Request进而将流程进入到ASPNET Http Runtime Pipeline
IIS 的 请求处理过程
IIS 站点启动并处理请求的步骤如下图
步骤 到 是处理应用启动启动好后以后就不需要再走这个步骤了
IIS
的 请求处理过程
上图的个步骤分别如下
当客户端浏览器开始HTTP 请求一个WEB 服务器的资源时HTTPsys 拦截到这个请求
HTTPsys contacts WAS to obtain information from the configuration store
WAS 向配置存储中心请求配置信息nfig
WWW 服务接受到配置信息配置信息指类似应用程序池配置信息站点配置信息等等
WWW 服务使用配置信息去配置 HTTPsys 处理策略
WAS starts a worker process for the application pool to which the request was made
The worker process processes the request and returns a response to HTTPsys
客户端接受到处理结果信息
WWPexe 进程中又是如果处理得呢？？ IIS 的应用程序池的托管管道模式分两种 经典和集成 这两种模式下处理策略各不相通
IIS 以及 IIS 经典模式的托管管道的架构
在IIS之前ASPNET 是以 IIS ISAPI extension 的方式外加到 IIS其实包括 ASP 以及 PHP也都以相同的方式配置（PHP 在 IIS 采用了两种配置方式除了 IIS ISAPI extension 的方式也包括了 CGI 的方式系统管理者能选择 PHP 程序的执行方式）因此客户端对 IIS 的 HTTP 请求会先经由 IIS 处理然后 IIS 根据要求的内容类型如果是 HTML 静态网页就由 IIS 自行处理如果不是就根据要求的内容类型分派给各自的 IIS ISAPI extension如果要求的内容类型是 ASPNET就分派给负责处理 ASPNET 的 IIS ISAPI extension也就是 aspnet_isapidll下图是这个架构的示意图
IIS
的执行架构图
以及IIS
应用程序池配置成经典模式的执行架构图
IIS 应用程序池的 托管管道模式 经典 模式也是这样的工作原理 这种模式是兼容IIS 的方式 以减少升级的成本
IIS 应用程序池的 托管管道模式 集成模式
IIS
的执行架构图（集成托管信道模式下的架构）
小结
IIS 到 IIS 的改进主要是 HTTPsys 的改进
IIS 到 IIS 的改进主要是 ISAPI 的改进
