IIS Web 服务器/ASP.NET 运行原理基本知识概念整理

 前言：

     记录 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 协议层作了相应的解析处理而已。

 

1、IIS 6.0

     早些年，公司还在一直在使用 IIS 6.0，做为微软早期的版本，那各类安全问题源源不断，此处默哀一下苦逼的程序员

     什么远程代码执行、上传数据流漏洞、身份认证漏洞.... 致使不少 .NET 开发人员以为 Web 服务器放在 Windows 下就是不安全。

     其实微软背后的团队，已经很是努力的在作补丁和迭代了，

     注意：

     一、服务器上必定不要关闭 Windows Update。

     二、做为一名程序员，有责任关于微软动态、更新稳定的 IIS 版本。

 

     IIS 6.0 因为太老的产品，不作过多的分析。

 

2、IIS 运行过程

     （这样比较好理解，伪装本身在写 Web 服务器）

 

     首先，HTTP 请求规范原理、细节不作解释了。

     咱们都知道 IIS Web 服务器默认监听 80 端口，那么监听的过程总得须要支撑吧，

     HTTP.sys 组件，它负责监听全部的 HTTP 请求，监听到请求了之后，

     根据请求信息（URL）分配对对应的进程池上（W3WP.exe/Application Pool），进程池完成本次请求处理后进行响应；

     // 在上文简单提到了 IIS 进程池，全部的站点都必要依赖与他，而进程池启动后会产生一个独立的 W3WP.exe 进程

 

     一、HTTP.SYS：（Kernel）的一个组件，它负责侦听（Listen）来自于外部的HTTP请求,根据请求的URL将其转发给相应的应用程序池 (Application Pool)。

          当此HTTP请求处理完成时，它又负责将处理结果发送出去。

          为了提供更好的性能，HTTP.sys 内部创建了一个缓冲区，将最近的HTTP请求处理结果保存起来。

 

     二、Application Pool：IIS 总会保持一个单独的工做进程：应用程序池。全部的处理都发生在这个进程里，包括 ISAPI dl l的执行。

   　　应用程序池它们容许以更小的粒度控制一个指定进程的执行。

   　　你能够为每个虚拟目录或者整个Web 站点配置应用程序池，这可使你很容易的把每个应用程序隔离到各自的进程里，

    　  这样就能够把它与运行在同一台机器上其余程序彻底隔离。从 Web 处理的角度看，若是一个进程死掉，至少它不会影响到其它的进程。

　　  当应用程序池接收到 HTTP 请求后，交由在此应用程序池中运行的工做者进程 Worker Process: w3wp.exe 来处理此HTTP请求。

 

　　三、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 扩展。

 

　　四、WAS（Web Admin Service）：这是一个监控程序，它一方面能够存取放在InetInfo元数据库（Metabase）中的各类信息，

     　 另外一方面也负责监控应用程序池（Application Pool）中的工做者进程的工做状态况，必要时它会关闭一个老的工做者进程并建立一个新的取而代之。

 

　　看图：

       

     

　 进程池中 经典管道 ISAPI 的做用、生命周期？

      集成管道中的乞求处置管道怎么理解？

 

 

2、ASP.NET 运行原理（浅析）

 

     看图：

     

   （ AppDomain 运行过程图示）

 

　AppDomain 的做用,相信你们都很了解了吧.这里简明扼要的写几点:

 

　一、一个 AppDomain 中的代码建立的对象不能由另外一个 AppDomain 中的代码直接访问（只能使用按引用封送或者按值封送,起到了很好的隔离做用）；

 

　二、AppDomain 能够卸载 CLR 不支持从 AppDomain 中卸载一个程序集的能力，但能够告诉 CLR 卸载一个 AppDomain，

     　从而达到卸载当前包含在该 AppDomain 内的全部程序集.

 

　三、AppDomain 能够单独保护 当宿主加载一些代码以后,能够保证这些代码不会被破坏（或读取）宿主自己使用的一些重要的数据结构.。　

 

　四、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