前言：
记录 IIS 相关的笔记还是从公司笔试考核题开始的，问 Application Pool 与 AppDomain 的区别？
促使我对进程池进了知识的学习，所以记录一下学习的笔记。
我们知道现在 .NET 就业来看，80% 的 .NET 程序员都是从事 Web 开发，
如果对微软唯一（现在不唯一了）Web 服务器都不熟的话，那就有点儿尴尬了；（不能被微软宠坏了）
Web 站点性能的好坏不在于 Web 服务器本身，IIS 可以说已经说一款非常强悍的 Web 服务器了。
现在对 IIS 6.0、IIS 8.5 做一些基本知识的整理；
微软早期在 IIS 上，提出进程池的概念，允许多个 Web 站点运行在一个 IIS 进程池（W3WP.exe）上，怎么说有好有坏，
好在他节省了 CPU、内存的开销，坏在他进程池的配置非独立，最大问题是某一个 Web 站点挂了，同一个进程次下的站点都会挂掉。
乃至在 IIS 7+ 以上的版本，默认创建的站点都会是独立的进程池；
Web 服务器其实深入进去也没有什么多神秘的东西，核心取决于你的设计，怎么合理处理请求/响应、并发控制；
// 追评：
所有的 Web 服务器，无非是对网络层和 HTTP 协议层做了相应的解析处理而已。
一、IIS 6.0
早些年，公司还在一直在使用 IIS 6.0，作为微软早期的版本，那各种安全问题源源不断，此处默哀一下苦逼的程序员
什么远程代码执行、上传数据流漏洞、身份认证漏洞.... 导致很多 .NET 开发人员觉得 Web 服务器放在 Windows 下就是不安全。
其实微软背后的团队，已经非常努力的在做补丁和迭代了，
注意：
1、服务器上一定不要关闭 Windows Update。
2、作为一名程序员，有责任关于微软动态、更新稳定的 IIS 版本。
IIS 6.0 由于太老的产品，不做过多的分析。
二、IIS 运行过程
（这样比较好理解，假装自己在写 Web 服务器）
首先，HTTP 请求规范原理、细节不做解释了。
我们都知道 IIS Web 服务器默认监听 80 端口，那么监听的过程总得需要支撑吧，
HTTP.sys 组件，它负责监听所有的 HTTP 请求，监听到请求了以后，
根据请求信息（URL）分配对对应的进程池上（W3WP.exe/Application Pool），进程池完成本次请求处理后进行响应；
// 在上文简单提到了 IIS 进程池，所有的站点都必要依赖与他，而进程池启动后会产生一个独立的 W3WP.exe 进程
1、HTTP.SYS：（Kernel）的一个组件，它负责侦听（Listen）来自于外部的HTTP请求,根据请求的URL将其转发给相应的应用程序池 (Application Pool)。
当此HTTP请求处理完成时，它又负责将处理结果发送出去。
为了提供更好的性能，HTTP.sys 内部建立了一个缓冲区，将最近的HTTP请求处理结果保存起来。
2、Application Pool：IIS 总会保持一个单独的工作进程：应用程序池。所有的处理都发生在这个进程里，包括 ISAPI dl l的执行。
应用程序池它们允许以更小的粒度控制一个指定进程的执行。
你可以为每一个虚拟目录或者整个Web 站点配置应用程序池，这可以使你很容易的把每一个应用程序隔离到各自的进程里，
这样就可以把它与运行在同一台机器上其他程序完全隔离。从 Web 处理的角度看，如果一个进程死掉，至少它不会影响到其它的进程。
当应用程序池接收到 HTTP 请求后，交由在此应用程序池中运行的工作者进程 Worker Process: w3wp.exe 来处理此HTTP请求。
3、Worker Process: 当工作者进程接收到请求后，首先根据后缀找到并加载对应的 ISAPI 扩展 (如:aspx 对应的映射是 aspnet_isapi.dll )，
工作者进程加载完 aspnet_isapi.dl l后，由 aspnet_isapi.dll 负责加载 ASP.NET应用程序的运行环境即CLR (.NET Runtime)。
Worker Proces s运行在非托管环境，而 .NET 中的对象则运行在托管环境之上(CLR)，它们之间的桥梁就是 ISAPI 扩展。
4、WAS（Web Admin Service）：这是一个监控程序，它一方面可以存取放在InetInfo元数据库（Metabase）中的各种信息，
另一方面也负责监控应用程序池（Application Pool）中的工作者进程的工作状态况，必要时它会关闭一个老的工作者进程并创建一个新的取而代之。
看图：
进程池中 经典管道 ISAPI 的作用、生命周期？
集成管道中的乞求处置管道怎么理解？
二、ASP.NET 运行原理（浅析）
看图：
（ AppDomain 运行过程图示）
AppDomain 的作用,相信大家都很了解了吧.这里简明扼要的写几点:
1、一个 AppDomain 中的代码创建的对象不能由另一个 AppDomain 中的代码直接访问（只能使用按引用封送或者按值封送,起到了很好的隔离作用）；
2、AppDomain 可以卸载 CLR 不支持从 AppDomain 中卸载一个程序集的能力，但可以告诉 CLR 卸载一个 AppDomain，
从而达到卸载当前包含在该 AppDomain 内的所有程序集.
3、AppDomain 可以单独保护 当宿主加载一些代码之后,可以保证这些代码不会被破坏（或读取）宿主本身使用的一些重要的数据结构.。
4、AppDomain 可以单独配置 设置主要影响 CLR 在 AppDomain 中加载程序集的方式,涉及搜索路径、版本绑定重定向、卷影复制及加载器的优化。
由以上几点可以看出 AppDomain 确保了 Windows 系统及其中运行的应用程序的健壮性。AppDomain 提供了保护、配置和终止其中每一个应用程序所需的隔离性。
再来看下 ProcessRequest 的过程：
简单分析一下上图
ProcessRequest(HttpWorkerRequest wr)中判断 wr 是否为 null，然后判断管线是否完整，再调用 ProcessRequestNoDemand(wr) 方法，
并判断当前 RequestQueue 是否为 null，接着计算等待时间并更新管线数 CalculateWaitTimeAndUpdatePerfCounter(wr)；
重置 wr 开始时间 wr.ResetStartTime()；调用 ProcessRequestNow(wr) 方法，并调用 ProcessRequestInternal(wr) 方法；
到这里想必能够使大家对ASP.NET管道机制能够有一个简单的回顾.当然还有很多地方没有详细分析。
再来总结一下IIS运行过程及ASP.NET管道机制：
Request→ (Internet ) HTTP.sys 监听
→ WAS (IIS6 web Admin Service /IIS7 (Windows Activation Service) 接收请求
→ (传入)Application Pool's → w3wp.exe(检查URL后缀)
→ (加载)ISAPI扩展[aspnet_isapi.dll] → 注册映射 构造HttpRuntime类
→ProcessRequest方法 HttpContext实例产生(Request,Response,Session and so on…)
HttpRuntime 调用 HttpApplicationFactory加载HttpApplication对象
穿越HttpModule到达HttpHandler
简单用140个字符(即一条微博的字数)概括:
Request→ (Internet ) HTTP.sys →(WAS)→Application Pool's → w3wp.exe→ISAPI→ Map→ (Pipeline)
HttpWorkerRequest→AppDomain→HttpRuntime→ProcessRequest()→ HttpContext(Request,Response)
→ HttpRuntime→HttpApplicationFactory→HttpApplication→ HttpModule→HttpHandler→EndRequest
)
