IIS 架构

1.概述

　　无论是怎样的HTTP请求处理流程，都必须讲究一些必要的“规则”（即遵守一些共同的机制）。

　　1）其中，最重要的一个“规则”就是保证同一台服务器上的各站点、各应用程序的隔离。

　　2）第二个比较重要的“规则”就是，将HTTP请求开放给由开发网站的程序员开发的“应用程序”，由这些“应用程序”进行HTTP请求的处理。
　　　　（当然，在不同的HTTP请求处理机制或者配置下，存在将资源直接返回到客户端的情况）。

　　3）为实现上述两个规则，几个IIS版本，都共同采用了一些相同的方式：

　　　　（1）维护着一份脚本映射扩展表，将请求映射到应用程序池、工作者进程等。

　　　　（2）管道技术是很好的衔接程序员代码的方式。

2.监听

　　无论是怎样的系统，怎样的HTTP请求处理流程，第一步，永远是让某一“进程”监听80端口。

　　在IIS 7处理模型中，监听程序是作为Windows操作系统内核的一部分运行的，叫做HTTP.sys。它接收从网络来的HTTP请求，安全过滤及预处理后，将其传给IIS，交由IIS作更进一步的处理。最后，它又接收IIS处理后的结果，并将结果（响应）返回到客户端的浏览器。

　　HTTP.sys在IIS 6就已经出现。而在比IIS 6更早的版本中，监听程序是Windows Sockets API (Winsock)，它运行在操作系统的用户模式上，并非在内核模式中。

　

　　关于HTTP.sys知识点还有：

　　1）内核模式缓存。HTTP.sys缓存历史响应，当重新遇到相同请求时，直接返回仍然有效的响应，而无需切换到用户模式（IIS处理）。

　　2）维护一个内核模式的请求队列。HTTP.sys直接将请求转发到正确的工作者进程（通过WAS等协助，映射找到相应的工作者进程）。如果没有工作进程可以接受请求，内核模式的请求队列保留该请求，直到工作者进程接收走请求。

　　3）请求的预处理和安全过滤。

　　4）HTTP.sys是IIS的一部分，作为监听的默认选择。在IIS 7及更高版本上，可以不用HTTP.sys监听HTTP请求，可以通过WCF监听适配程序【WCF listener adapter】（比如NetTcpActivator）来完成或者做更多工作。

3.万维网发布服务

　　即：WWW service（World Wide Web Publishing Service）

　　1）WWW service在IIS 6 中的工作情况

　　（1）HTTP管理与配置

　　WWW service从IIS  metabase 读取配置信息，并用这些信息配置和更新HTTP监听程序，HTTP.SYS。此外，WWW service对处理HTTP请求的工作进程进行启动、停止、监控和管理。

　　（2）性能监控

　　WWW service监控性能，并为网站和IIS缓存提供性能计数器。

　　（3）进程管理

　　WWW service管理应用程序池和工作者进程，诸如启动、停止和回收工作者进程。另外，WWW service监控工作者进程的“健康”，以及在配置的时间内调用“快速失败监测”以阻止新工作者进程的启动。

　　2）在IIS 7 中的工作情况

　　在IIS 7 及以上版本，WWW service被分成两部分，其中一部分仍然叫WWW service，而另一部分叫做Windows Process Activation Service (WAS)。这两部分运行在同一个进程中（svchost.exe）。

 

 　　（1）新WWW service作为HTTP监听程序（HTTP.SYS）的监听适配器，主要负责两个工作：

• • 　　在配置改变时，配置和更新HTTP.SYS；
  • 　　在请求加入到请求队列时，通知WAS。

　　（2）WAS管理应用程序池和工作者进程，而不再是WWW service。不同的是，WAS做到了能够同时管理“HTTP应用程序池和工作者进程”与“非HTTP的应用程序池和工作者进程”。WAS判断工作者进程是否正在运行，如果应用程序池中的工作者进程没在运行，则启动工作者进程。

　　WAS读取配置信息有：全局配置信息，协议配置信息（包括HTTP与非HTTP），网站配置信息（比如绑定和应用程序），应用程序配置信息（比如：应用程序启用的协议，所属的应用程序池）。

　　如果ApplicationHost.config改变，WAS接收到通知后，将新的配置信息更新监听适配器上。

　　（3）一分为二

　　将原WWW service一分为二后，可以让你在“HTTP协议网站”与“非HTTP协议网站”上，运用相同的配置和处理模式。

　　另外，如果不需要处理HTTP请求的功能，可以只运行WAS而不运行WWW service。举个例子，只通过WCF监听适配器（比如：NetTcpActivator）管理运行一个不需要监听HTTP请求的Web Service。

　　3) IIS组成

　　到这里，我们知道，IIS几个重要组成部分：协议监听程序，监听适配器，应用程序池和工作者进程的管理者，应用程序池和工作者进程。在HTTP请求处理上`，他们分别对应的是：HTTP.SYS； WWW Service；WAS；W3WP.exe。

组成部分	对应资源
协议监听程序	HTTP.SYS
监听适配器	WWW Service
应用程序池和工作者进程的管理者	WAS
应用程序池	W3WP.exe
工作者进程

　　面对不同的协议请求，可以根据需要启用不同的协议监听程序和监听适配器。

　　在HTTP请求处理上，工作流程可以简单地说成是这样子：配置改变时，被WAS（应用程序池和工作者进程的管理者）读到，并update到WWW Service（监听适配器），WWW Service又将新配置信息配置update到HTTP.SYS（协议监听程序）。HTTP.SYS接收到请求时，将请求直接给了W3WP.exe（工作者进程），工作者进程处理请求后，将响应返回到HTTP.SYS【WWW Service、WAS等不直接接触Http请求】。 

4.模块（Modules）

　　关于模块（Modules），查看本人的另一篇博客：IIS 模块（Modules）。

5．应用程序池

　　应用程序池通过进程边界（非线程边界等）将应用程序隔离开，阻止了同一个服务器上不同的应用程序池中的应用程序之间的相互影响。在IIS 7 及更高版本中，应用程序池仍旧使用IIS 6 工作者进程相同的隔离模式。此外，在IIS 7 及更高版本中，在涉及到托管资源的请求的处理上，还可以配置请求的处理方式：集成模式或者经典模式。

　　在IIS 6 中工作者进程的隔离模式与在IIS 5 中的隔离模式，都是被设置在服务器级别上，所以，这让在同一服务器上同时运行这两种隔离模式成为了可能。而在IIS 7 及更高版本上，集成模式和经典模式被设置在了应用程序池的级别上，这让在同一个服务器上的不同应用程序池中的应用程序，采用不同的请求处理模式。

　　1）集成模式

　　集成处理模式，是将原IIS的请求处理模式与ASP.NET的请求处理模式集成到一个统一的处理模式中。这样做，它有几个好处：

　　（1）在IIS与ASP.NET之间，消除了一些重复的功能，比如身份验证；举个例子，客户端请求一个托管的文件，在集成模式下，服务器调用适当的验证模块；而在之前的IIS版本中，相同的请求，将在IIS和ASP.NET都进行身份验证。

　　（2）托管代码所具有的特性适用了所有的文档类型（Additionally, Integrated mode enables the availability of managed features to all content types.）。举个例子，你可以让“对ASP文件、静态文件以及在网站和应用程序中其他的文件”的请求在处理上使用托管特性ASP.NET Forms authentication 和 Uniform Resource Locator (URL) authorization。

　　（3）在同一个位置管理所有的模块，而不是在IIS上管理一部分功能，在ASP.NET上配置一部分功能。这简化了网站和应用程序的管理。

　　在集成模式下，工作者进程接收到请求后，请求将穿过一组有序的事件。每个事件将调用必要的本地模块和托管模块来处理请求的部分内容，以及产生相应的响应。

　　2）经典模式

　　在经典模式下，IIS 7 及以上版本对请求的处理模式与IIS 6 相同。ASP.NET请求（是ASP.NET请求，即可用ASP.NET进行处理的语法，而不是别的请求）首先按IIS 本地处理步骤进行处理，然后再导入到Aspnet_isapi.dll进行处理，最后，请求返回到IIS以向客户端返回响应。

　　分享的处理模式，导致了处理步骤的重复。

　　将已有的应用程序指定到集成模式，需要测试该应用程序对集成模式的兼容性。如果失败，则需将其指定到经典模式。