IIS站点和虚拟目录
============
在Web服务器中, ASP.NET和WSS都依赖于IIS来提供底层的对于到达服务器的HTTP请求的监听机制, 并且依靠IIS提供加载和运行工作者进程(worker process)的管理基础架构. 如果要理解WSS的是如何将IIS, ASP.NET, 还有它自己联系到一起协同工作的话, 那么首先就要理解IIS站点和虚拟目录这两个基本概念.
IIS站点(IIS Web Site)提供了一个进入IIS Web服务器基础架构的入口. 每一个IIS站点都被设置为监听和处理到来的, 符合一定标准的HTTP请求. 比如说, 一个IIS站点可以被配置为它只处理发送到某一个IP地址的, 或者发送到某个端口号的请求. 抑或通过一个可以被寻路到Web服务器的指定的host header(主机标头)来确定由哪个IIS站点来处理一个请求. 比如: http://Extranet.Litwareinc.com.
IIS自动地创建并配置一个叫做Default Web Site的IIS站点, 该站点监听那些发送到该web服务器支持的任意IP地址的, 发送到80端口的http请求. 你还可以通过IIS管理工具创建并配置其他的IIS站点.
每一个IIS站点都定义了一个特定的URL空间. 比如说, 标准的Default Web Site定义了一个URL空间, 来处理任何到来的请求, 请求的URL空间符合如下的模式:http://www.Litwareinc.com/* 你可以想象， 无限制个数的URL请求可以在这个空间下被创建出来. IIS将发送目标是这样的URL的请求导向Default Web Site.
任何一个IIS站点有配置使之映射到一个根目录(root directory), 根目录是一个宿主Web服务器上的文件系统的一个物理文件夹. 举例说明, Default Web Site的标准配置下, IIS将它映射到一个位置在C:\Inetpub\wwwroot的文件夹. 在大多数干脆利落的路由(routing)场景下, IIS将HTTP请求映射到根目录的物理文件上. 比如说, IIS会对这个请求 http://www.Litwareinc.com/page1.htm进行响应, 响应的方式是简单地加载起位于c:\Inetpub\wwwroot\page1.htm的物理文件的内容, 并用流(stream)的方式发送给客户端.
关于IIS站点的一个重要的方面是: 它对到来的HTTP请求是否需要认证进行控制, 如果要, 究竟用哪一种方式进行认证. 这都是有IIS说了算. 比如说, default web site也许想被用作一个面向因特网大众的站点. 所以, 它可能会被设置为允许匿名用户访问, 或者支持Basic Authentication. 而另一个IIS站点想要仅仅是由公司内部局域网内的员工访问, 那么可能就不会允许匿名用户访问, 同时支持Windows集成认证, 而不是Basic Authentication.
IIS不仅支持IIS站点中的虚拟目录, 还支持你粗昂见和配置新的虚拟目录(virtual directory). 一个虚拟目录是一个定义了寄存在在父站点URL空间之下的,子URL空间的一个实体. 拿一个IIS站点来说, 有一个虚拟目录被配置给站点作为根目录. IIS站点提供了将根目录定义在任意位置的灵活性. 比如说, 你可以定义Default Web Site的一个虚拟目录, 虚拟目录的URL空间是http://www.Litwareinc.com/Sales. 当你创建这个虚拟目录的时候, 你可以配置使用一个位置在C:\WebApps\Site1的文件系统目录作为它的根目录.
IIS提供了一个管理工具, 叫做Internet Information Services(IIS) Manager. 这个工具允许你检阅, 创建, 和配置当前机器上的IIS站点和虚拟目录. 你可以通过开始菜单| 管理工具| Internet InformationServices(IIS) Manager 来启动它. 如果你还不熟悉这个工具, 你可以把它启动起来, 学学怎样使用它来查看IIS站点和虚拟目录的属性以及如何配置它们.
注意IIS跟踪和保存IIS站点和虚拟目录的配置在一个叫做IIS metabase的存储地点. IIS metabase存在于运行着IIS的前端服务器的文件系统中. 比如说, 当你使用IIS管理工具创建和配置了一个IIS站点, IIS就将你的这些修改作为entry写入到本地的IIS metabase的文件中.
除了IIS管理工具, 你还可以自动化你的创建还有配置IIS站点和虚拟目录的操作过程 如何自动化呢? 方式是通过写脚本, 或者是针对IIS的对象模型进行托管代码的编程. 这个过程通常在web的场环境下进行, 因为我们需要将一模一样的IIS metabase的设置复制到场内所有的web前端服务器上.
ISAPI Extension 和 ISAPI Filters
====================
大多数直接路由的情况下, IIS简单地将进入的请求映射到IIS站点中根目录或者是某个虚拟目录下的物理文件上. 然而, IIS还支持Internet Server Application Programming Interface (ISAPI)编程模型, 提供给你处理更加复杂的路由情况的机会. 特别地, ISAPI编程模型允许你配置IIS站点或虚拟目录, 从而进入的请求可以出发Web服务器上自定义代码的执行.
ISAPI编程模型是由老的IIS版本引入的, 目前还是持续地为你提供在底层为IIS编写组件的能力. ISAPI编程模型由两种主要的组件组成: ISAPI extensions 和 ISAPI filters.
ISAPI extension是一个dll组件, 扮演着到来请求的终点的角色. 一个很基础的理解是: IIS可以将请求映射到一系列的可以激发ISAPI Extension DLL的执行的终点上. ISAPI extension组件必须安装在Web服务器上, 在IIS站点或者是虚拟目录的水平进行配置. 通常的配置涉及由IIS application map决定的, 某一种文件后缀名到某一个ISAPI extension的映射.
当一个ISAPI扩展作为一个终点在服务的时候, ISAPI filter扮演的是一个阻碍着的角色. ISAPI filter是在IIS站点的水平上安装和配置的. 一旦安装, ISAPI filter会阻拦所有的针对某个站点的请求. 一个很基础的理解是: ISAPI filter 可以提供针对任一到来的请求的预处理和后处理. ISAPI filter典型被创建来提供底层的IIS站点服务, 比如说自定义的认证功能, 还有请求的日志记录功能.
Application Pool和IIS工作者进程
====================
IIS提供了一个灵活的基础架构, 灵活的地方在于使用application pool来管理工作者进程. Application pool是一个可以设定的实体, 它允许你控制IIS如何将IIS站点和虚拟目录映射到IIS工作者进程当中. 注意, IIS工作者进程的实例是被一个叫做w3wp.exe的可执行文件加载的. 如下图.
IIS的路由架构是由一个内核级的设备驱动叫做http.sys来控制的. 这个驱动程序监听到来的HTTP请求, 使用IIS metabase中的信息来将w3wp.exe的实例与目标application pool联系起来. 如果http.sys发现了目标application pool并没有一个运行着的w3wp.exe的实例, 那么它就会在处理到来的http request的请求下, 加载一个新的实例.
每个IIS站点和虚拟目录都可以被配置运行在他们自己的孤立的application pool中. 相反地, 你可以为了更好的效率而配置许多不同的IIS站点和虚拟目录, 让它们运行在同一个application pool中. 一项重要的观察是: 你应该考虑在独立性和效率之间进行权衡. 为了达到更好的独立性, 这意味着你必须运行更多w3wp.exe的实例, 但是这样做会损害效率. 为了更高的效率, 你就必须将多个IIS站点和虚拟目录映射到更少数目的IIS工作者进程当中, 然而, 这样却损害了独立性.
每一个application pool都有一个重要的配置选项, 叫做application pool identity. Application pool identity被配置为一个Windows用户账户, 要么是一个Web服务器的本地账户, 要么就是一个Active Directory中的一个directory中的域账户. 当http.sys为某一个application pool加载一个新的w3wp.exe的实例的时候, 他使用application pool identity来初始化一个Windows security token来作为process token. 这很重要, 因为它为IIS工作者进程中运行的代码建立起了"run as"的身份标识.
默认地, 当你创建一个新的application pool的时候, IIS使用本地的Network Service账户作为identity. 然而, 你可以配置application pool identity为任何你想要的账户. 当部署ASP.NET和WSS的站点的时候, 推荐你使用域账户作为application pool identity, 而不是Network Service. 尤其是在web的场环境下, 当你需要同步不同web前端服务器中的application pool identity的时候.