IIS的运行机制

一，VS自带的IIS（IIS Express）和真实的IIS有什么区别？

1，VS带的IIS是IIS的真实精简版本，叫IIS Express，和IIS彻底同样，不一样于Development Server，IIS Express支持包括ISAPI等等插件，除了在链接数上的限制之外，IIS Express也没有图形化的管理界面，并且也不是以服务的形式运行，IIS Express的功能和行为几乎和IIS同样。

2，能够理解为：VS自带的那个是虚拟机

3，IIS配置的网站能够被外网访问，VS只是本地调试

4，IIS是一个系统服务，IIS Express则只是一个临时进程。

5，IIS Express至关于一个IIS的精简版本，它拥有IIS几乎全部的功能，但它没有可视化的管理界面

二，IIS是如何处理基于ASP.NET资源（.aspx .asmx）的请求的？

IIS5x

1>IIS5X运行在进程InetInfo.exe中，该进程寄宿着一个名为World Wide Web Publishing Server(简称W3SVC)的Windows服务。W3SVC的主要功能包括HTTP请求的监听、工做进程和配置管理（经过从MetaBase中加载相关的配置信息）等

2>当检测到某个HTTP 请求时，先根据扩展名判断请求的是不是静态资源(好比.html 、.img 、.txt 、.xml 等)，若是是，则直接将文件内容以HTTP 回复的形式返回:若是是动态资源(好比.aspx 、.asp 、.php 等) ，则经过扩展名从IIS 的脚本映射C Script Map) 中找到相应的ISAPI 动态链接库CDynamic Link Library, DLL) 。

3>ISAPI C Intemet Server Application Programming Interface) 是一套本地的CNative) Win32API，是IIS 和其余动态Web 应用或平台之间的纽带。ISAPI 定义在一个动态链接库CDLL)文件中， ASP.NET ISAPI 对应的DLL 文件名称为aspnet_isapi. dll ，咱们能够在目录"%windir% \Microsoft.NET\Framework\ {version no} \"中找到它。ISAPI 支持ISAPI 扩展CISAPIExtension) 和ISAPI 筛选C ISAPI Filter) ，前者是真正处理HTTP 请求的接口，后者则能够在HTTP 请求真正被处理以前查看、修改、转发或拒绝请求，好比IIS 能够利用ISAPI 筛选进行请求的验证。

4>若是咱们请求的是一个基于ASPNET 的资源类型，好比.aspx 、.asmx 和.svc 等，aspnet isapi. dll 会被加载，而AS卫NETISAPI 扩展会建立ASP.NET 的工做进程(若是该进程还没有启动)。对于IIS 5.x 来讲，该工做进程为aspnet. exeo IIS 进程与工做进程之间经过命名管道CNamed Pipes) 进行通讯。

5>在工做进程初始化过程当中， .NET 运行时(CLR) 被加载进而构建了一个托管的环境。对于某个Web 应用的初次请求， CLR 会为其建立一个应用程序域C Application Domain) 。在应用程序域中， HTTP 运行时C HTTP Runtime) 被加载并用以建立相应的应用。寄宿于IIS 5.x 的全部Web 应用都运行在同一个进程(工做进程aspnet_wp.exe) 的不一样应用程序域中。

IIS6x

1>经过上面的介绍，咱们能够看出IIS 5.x 至少存在着以下两个方面的不足。ISAPI 动态链接库被加载到Inetlnfo.exe 进程中，它和工做进程之间是一种典型的跨进程通讯方式，尽管采用命名管道，可是仍然会带来性能的瓶颈。全部的ASP.NET 应用运行在相同进程C aspnet_ wp.exe) 中的不一样的应用程序域中，基于应用程序域的隔离不能从根本上解决一个应用程序对另外一个程序的影响。在更多的时候，咱们须要不一样的Web 应用运行在不一样的进程中。

2>为了解决第一个问题， IIS 6.0 将ISAPI 动态链接库直接加载到工做进程中:为了解决第二个问题，引入了应用程序池C Application Pool )的机制。咱们能够为一个或多个Web 应用建立应用程序池，因为每个应用程序池对应一个独立的工做进程，从而为运行在不一样应用程序池中的Web 应用提供基于进程的隔离级别。IIS 6.0 的工做进程名称为w3wp.exe 。

3>除了上面两点改进以外， IIS 6.0 还有其余一些值得称道的地方。其中最重要的一点就是建立了一个名为HTTP.SYS 的HTTP 监听器。HTTP.SYS 以驱动程序的形式运行在Windows的内核模式C Kemel Mode) 下，它是Windows 2003 的TCP/IP 网络子系统的一部分，从结构上看它属于TCP 之上的一个网络驱动程序。

4>严格地说， HTTP.SYS 已经不属于IIS 的范畴了，因此HTTP.SYS 的配置信息也没有保存在IIS 的元数据库CMetabase) 中，而是定义在注册表中。HTTP.SYS 的注册表项的路径为HKEY LOCAL MACHINE/SYSTEMlCurrentControlSetlServices/HTTP 0 HTTP.SYS 可以带来以下的好处。

    持续监昕:因为HTTP.SYS 是一个网络驱动程序，始终处于运行状态，对于用户的HTTP请求可以及时做出反应。

    更好的稳定性: HTTP.SYS 运行在操做系统内核模式下，并不执行任何用户代码，因此其自己不会受到Web 应用、工做进程和IIS 进程的影响。内核模式下数据缓存:若是某个资源被频繁请求， HTTP.SYS 会把响应的内容进行缓存，缓存的内容能够直接响应后续的请求。因为这是基于内核模式的缓存，不存在内核模式和用户模式的切换，响应速度将获得极大的改进。

5>下图，体现了IIS 的结构和处理HTTP 请求的流程。与IIS 5.x 不一样， W3SVC 从InetInfo.exe 进程脱离出来(对于IIS 6.0 来讲， InetInfo.exe 基本上能够看做单纯的IIS 管理进程) ，运行在另外一个进程SvcHost. exe 中。不过W3SVC 的基本功能并无发生变化，只是在功能的实现上做了相应的改进。与IIS 5.x 同样，元数据库CMetabase) 依然存在于Inetlnfo.exe 进程中。

6>当HTTP.SYS 监听到用户的HTTP 请求时将其分发给W3SVC ， W3SVC 解析出请求的URL ，并根据从Metabase 获取的URL 与Web 应用之间的映射关系获得目标应用，并进一步获得目标应用运行的应用程序池或工做进程。若是工做进程不存在(还没有建立或被回收) ,则为该请求建立新的工做进程。咱们将工做进程的这种建立方式称为请求式建立。在工做进程的初始化过程当中，相应的ISAPI 动态链接库被加载。对于ASP.NET 应用来讲，被加载的ISAPI. dll 为aspnet_isap i. dllo AS卫NETISAPI 再负责进行CLR 的加载、应用程序域的建立和Web 应用的初始化等操做。

IIS7x

1>IIS 7在请求的监听和分发机制上又进行了革新性的改进，主要体如今对于Windows进程激活服务C Windows Process Activation Service, WAS) 的引入，将原来CIIS 6.0) W3SVC承载的部分功能分流给了WAS 。经过上面的介绍，咱们知道对于IIS 6.0 来讲W3SVC 主要承载着3 大功能。

    HTTP 请求接收:接收HTTP.SYS 监听到的HTTP 请求。

    配置管理:从元数据库CMetabase) 中加载配置信息对相关组件进行配置。   

进程管理:建立、回收、监控工做进程。

2>IIS 7.0 将后两组功能实现到了WAS 中，接收HTTP 请求的任务依然落在W3SVC 头上。WAS 的引入为IIS 7.0 提供了对非HTTP 协议的支持。WAS 经过监听器适配器接口CListenerAdapter Interface) 抽象出不一样协议监听器。具体来讲，除了基于网络驱动的HTTP.SYS 提供HTTP 请求监听功能外还提供了TCP 监听器、命名管道监听器和MSMQ 监昕器以提供基于TCP、命名管道和MSMQ 传输协议的监听支持。

3>与此3 种监听器相对的是3 种监听适配器，它们提供监昕器与WAS 中的监听器适配器接口之间的适配。从这个意义上讲， IIS 7.0 中的W3SVC 更多地为HTTP.SYS 起着监昕适配器的做用。这3 种非HTTP 监听器和监昕适配器定义在程序集SMHost. exe 中，咱们能够在目录%windir%\Microsoft.NET飞Framework\v3.0\Windows Communication Foundation \中找到它们。

4>WCF 提供的这3 种监昕器和监昕适配器最终以Windows 服务的形式体现。虽然它们定义在一个程序集中，咱们依然能够经过服务工做管理器对其进行单独的启动、终止和配置。SMHost. exe 提供了4 个重要的Windows Service 。NetTcpPortSharing: 为WCF 提供TCP 端口共享。关于端口共享在WCF 中的应用，本人拙著<<WCF 全面解析)) C 上册)对此有详细的介绍。NetTcpActivator: 为WAS 提供基于TCP 的激活请求，包含TCP 监昕器和对应的监听适配器。

    NetPipeActivator: 为WAS 提供基于命名管道的激活请求，包含命名管道监昕器和对应的监听适配器。

    NetMsmqActivator: 为WAS 提供基于MSMQ 的激活请求，包含MSMQ 监昕器和对应的监听适配器。

5>揭示了IIS 7.0 的总体构架及整个请求处理流程。不管是从W3SVC 接收到的HTTP 请求，仍是经过WCF 提供的监听适配器接收到的请求，最终都会传递到WAS 。若是相应的工做进程(或者应用程序池)还没有建立，则建立它，不然将请求分发给对应的工做进程进行后续的处理。WAS 在进行请求处理过程当中，经过内置的配置管理模块加载相关的配置信息，并对相关的组件进行配置。与IIS 5.x 和IIS 6.0 基于Metabase 的配置信息存储不一样的是， IIS 7.0 大都将配置信息存放于XML 形式的配置文件中，基本的配置存放在applicationHost. config 中。

 三，代码请求