MVC之前的那点事儿系列，是笔者在2012年初阅读MVC3源码的时候整理的，主要讲述的是从HTTP请求道进入MVCHandler之前的内容，包括了原创，翻译，转载，整理等各类型文章，当然也参考了博客园多位大牛的文章，对此表示感谢，这次有时间贴出来，希望对大家有用。
主要内容
本文讲解的是：服务器接受Http Request请求之后，是如何进入.Net CLR，从而进一步操作的。
我们大家都知道，IIS必须先接受请求，然后才能有机会进入CLR，但对请求(request)是怎么从Web服务器传送到ASP.NET运行时的却不甚了解。IIS由于版本的不同，在进入CLR时候方式可能有所不同，本章节将就IIS5/6/7的三本版本的进入方式给予解释，通过对这些底层机制的了解，可以让我们对 ASP.net 有更深的理解。。
IIS 5 的 ASP.net 请求处理过程
IIS5核心特征是：IIS是允许在一个叫InetInfo.exe的进程上的，所以无论是aspx页面还是html页面都是通过这个进程处理的，其中，由于aspx页面扩展名映射到了aspnet ISAPI.DLL上，所以如果页面是aspx的话，aspnet ISAPI.DLL则创建aspnet_wp这个Worker Process，并在初始化的时候加载CLR，所以这是一个托管的环境。
需要注意的几点是：
同一台服务器只能运行一个 aspnet_wp 进程，也就是说所有的ASP.NET Web Application都在同一个Worker Process 中，但是不意味着他们共享同一个context和数据库， ASP.NET里有个AppDomain的概念，每个站点或虚拟目录都对应一个单独的AppDomain，每个AppDomain是隔离的，有自己独立的 context上下文，所以安全没问题，所以我们的结论是：ASP.NET程序是继续AppDomain的，而不是基于Process的。
ASP.NET ISAPI 不但负责创建 aspnet_wp Worker Process，而且负责监控该进程，如果检测到 aspnet_wp 的 Performance 降低到某个设定的下限，ASP.NET ISAPI 将结束掉该进程，在Request来了以后，ASP.NET ISAPI 将重新创建新的 aspnet_wp Worker Process。
由于 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 请求处理过程