MVC源码解析 - 进入CLR

这一篇是转载自汤姆大叔的一篇随笔.

IIS 5 的 ASP.net 请求处理过程

IIS5核心特征是：IIS是允许在一个叫InetInfo.exe的进程上的，所以无论是aspx页面还是html页面都是通过这个进程处理的，其中，由于aspx页面扩展名映射到了aspnet ISAPI.DLL上，所以如果页面是aspx的话，aspnet ISAPI.DLL则创建aspnet_wp这个Worker Process，并在初始化的时候加载CLR，所以这是一个托管的环境。

需要注意的几点是：

1. 同一台服务器只能运行一个 aspnet_wp 进程，也就是说所有的ASP.NET Web Application都在同一个Worker Process 中，但是不意味着他们共享同一个context和数据库， ASP.NET里有个AppDomain的概念，每个站点或虚拟目录都对应一个单独的AppDomain，每个AppDomain是隔离的，有自己独立的context上下文，所以安全没问题，所以我们的结论是：ASP.NET程序是继续AppDomain的，而不是基于Process的。
2. ASP.NET  ISAPI 不但负责创建 aspnet_wp Worker Process，而且负责监控该进程，如果检测到 aspnet_wp 的 Performance 降低到某个设定的下限，ASP.NET  ISAPI 将结束掉该进程，在Request来了以后，ASP.NET ISAPI 将重新创建新的 aspnet_wp Worker Process。
3. 由于 IIS 和 Application 运行在他们各自的进程中，他们之间的通信必须采用特定的通信机制。由于之间的通信是同机器不同进程的通信（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 6 的 ASP.net 请求处理过程

IIS6和IIS5有3个非常不同的地方：接受请求（Http.sys），应用程序池（Application Pool），w3wp.exe Worker Process。

在IIS5里，InetInfo.exe附件监听并处理请求（Request），但在IIS6里，服务器是通过一个新组件Http.sys来接受请求（Request）。

Http.sys接收到http请求的时候，它会根据IIS中的 Metabase 查看该基于该 Request 的 Application 属于哪个Application Pool， 如果该Application Pool不存在，则创建之。否则直接将 request 发到对应Application Pool 的 Queue中。

每个 Application Pool 对应着一个Worker Process：w3wp.exe。在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。

注意：IIS5和IIS6还有一个区别是，在IIS5里ASP.NET ISAPI创建aspnet_wp Worker Process，进而加载CLR，但在IIS6里是w3wp通过Application Pool的map关系运行以后，才加载ASP.NET ISAPI，然后加载CLR。

IIS 7  的 ASP.net 请求处理过程

步骤 1 到 6 ，是处理应用启动，启动好后，以后就不需要再走这个步骤了，上图的8个步骤分别如下：

1. HTTP.sys监听拦截客户端请求开始处理。
2. HTTP.sys通过配置信息联系WAS获取相关信息。
3. WAS 向配置存储中心请求配置信息。applicationHost.config。
4. WWW 服务接受到配置信息，配置信息指类似应用程序池配置信息，站点配置信息等等。
5. WWW 服务使用配置信息去配置 HTTP.sys 处理策略。
6. WAS为这个请求对应的应用程序池（Application Pool）开启W3WP Worker Process。
7. W3WP Worker Process处理以后，将Response返回给HTTP.sys。
8. 客户端接受到Response内容。

W3WP.exe 进程中又是如果处理得呢？？ 取决于IIS 7 的应用程序池托管管道模式是什么，IIS7目前有2个模式： 经典模式和集成模式。两种模式下的处理方式是不一样，看如下区别：

IIS7经典模式：

IIS7的经典模式和IIS6的处理方式是一样的,用户发送HTTP Request请求以后， IIS会先行处理，IIS会根据HTTP Request的类型进行筛选，如果是HTML 静态网页就由 IIS 自行处理，如果不是，就根据具体要求的内容类型，分派给各自的 IIS ISAPI extension；如果要求的内容类型是 ASP.NET，就分派给负责处理 ASP.NET 的 IIS ISAPI extension，也就是 aspnet_isapi.dll，然后再进入CLR。

IIS7集成模式：

IIS7集成模式是一个伟大的改进，已经预加载了CLR（不在依靠之前IIS版本的aspnet_ISPAI.DLL），也就是说所有的HTTP Request请求都要经过ASP.NET来处理（包括html, php等），也因为 ASP.NET 的诸多功能已经成为 IIS 7 的一部份，因此 ASP 程序、PHP 程序或静态 HTML 网页等类型的要求，也能使用像是Forms认证（Forms Authentication）或输出缓存（Output Cache）等 ASP.NET 2.0 的功能（但须修改 IIS 7 的设定值），也因为 IIS 7 允许自行以 ASP.NET API 开发并加入模块，因此 ASP.NET 网页开发人员将更容易扩充 IIS 7 和网站应用程序的功能，甚至能自行以 .NET 编写管理 IIS 7 的程序（例如以程控 IIS 7 以建置网站或虚拟目录）。

总结：

不同的IIS版本进入CLR的方式是不一样的，其中IIS版本之间最大的改变时：

1. IIS5 到 IIS6 的改进，主要是 HTTP.sys 的改进。
2. IIS6 到 IIS7 的改进，主要是 ISAPI 的改进。

转自:

　　MVC之前的那些事

目录已同步