深入剖析WindowsIIS6.0（2）

　　三全新的内核
　　从体系结构上看IIS 和IIS 其实是一样的它们都是在用户模式下运行的发布Web内容的应用程序或者在Inetinfo进程之内以System帐户运行或者在Inetinfo进程之外以IWAM用户运行虽然在较重的负载下IIS 也有相当出色的表现不过从IIS 开始我们对IIS底层结构的看法应该改变了为了使IIS不仅能够轻松地支持个Web网站而且能够支持个甚至更多的网站同时还要提高Web服务器的安全性和可靠性微软放弃了原有的IIS内核重新构造了一个
　　
　　另一个促使微软重新构建IIS内核的原因是微软（以及其他厂商）认识到Web服务器的性能和可靠性问题绝大部分是由于质量低劣的Web应用造成IIS 通过带缓冲池的Out of Process容器减轻这类问题在IIS 中在Out of Process池中运行的应用一旦崩溃一般不会波及到IIS本身因为应用程序在Inetinfo之外的进程中运行但运行在Out of Process池之内的所有Web应用都会终止——在默认情况下所有的应用程序都在该池之中运行在这种情况下排解故障很不容易因为要确定哪一个应用程序导致了问题非常困难IIS 将监听请求创建和监视Web网站运行Web服务这些不同的任务隔离了开来这一新型体系可望解决IIS 存在的问题从理论上看新的体系将极大地改善可用性安全和性能从实际情况看根据微软和Beta测试者的报告新的体系令稳定性和性能有了奇迹般地提高IIS 的内核体系主要建立在三个组件之上WSVChttpsys以及WCore
　　
　　■ WSVC
　　WSVC也许是IIS 体系中最不令人注意的组件不过这并不说明它不重要WSVC的任务是根据配置数据的设置创建和监视工作线程由工作线程运行Web网站应用在IIS 中与IIS WSVC组件最接近的是IIS管理服务IIS管理服务是Inetinfo的一部分因此如果Inetinfo出现问题IIS管理服务也会出现问题而且此时的IIS管理服务不能再重新启动Inetinfo或其他故障的应用程序在IIS 中WSVC作为一个独立的进程运行Web应用的故障不可能波及WSVC因为WSVC之内根本没有第三方的代码运行WSVC总是处于运行状态因此它能够监视Web应用的健康状况并在必要时采取行动由于这一策略服务器能够根据用户指定的参数监视和重新启动应用程序
　　
　　■ httpsys
　　IIS 体系设计中最重大的变化是加入了httpsys驱动程序httpsys驱动程序的任务是处理HTTP请求而且它在内核模式下执行操作不要小看这一改变将处理HTTP请求的任务从IIS IIS 的用户模式改变到IIS 的内核模式标志着新一代IIS服务器的诞生
　　
　　在Win K和NT 中IIS在用户模式下运行运行在用户模式下的应用程序不直接与硬件通信它们直接调用的是一些标准过程这些标准过程或者将数据传入内核模式的组件（例如网卡驱动程序图形子系统）或者调用内核模式组件的函数以此完成保存文件设置IP地址将HTML文件发送到网络之类的任务
　　
　　用户模式和内核模式之间的转换是一项开销很大的操作服务器首先从内核模式的TCP/IP栈将传入的HTTP请求传递给用户模式的Winsock由Winsock将请求传递给IIS从内核模式到用户模式的切换很快发生但不可避免地给处理过程带来瞬间的延迟当负载较大时这种延迟不断累加同时由于这种转换是必不可少的所以管理员根本没有办法优化处理过程
　　
　　IIS 的内核模式驱动程序极大地减少了用户模式和内核模式之间的切换次数httpsys监听着HTTP请求决定由哪一个用户模式的进程来处理该请求或者是否由驱动程序本身返回用户请求的内容
　　
　　IIS 在用户模式下运行完全依赖内核模式的httpsys作为接收用户请求的服务器引擎因此httpsys必须能够在任何时候作出相应必须具有极高的可靠性用户代码可能导致进程出错所以微软把httpsys设计成不执行任何用户代码这样即使应用程序出现了故障也不会影响到IIS 本身IIS 仍能够照常监听HTTP请求
　　
　　如果要从内核模式的缓冲区返回静态的应答一个高速的内核模式的不允许运行应用程序代码的HTTP处理器是十分理想的它减少了切换到用户模式的昂贵开销能够从内核模式的缓冲区快速返回应答IIS 的httpsys就管理着这样一个缓冲区而且使用了高度优化的启发式缓冲区算法来确定哪些内容要放入缓冲区例如httpsys可能只缓冲那些出现了一次以上请求的内容
　　
　　由于httpsys直接从应答缓冲区提取静态内容不必再切换到用户模式所以与IIS 的性能相比IIS 的整体性能有了显著提升根据微软的资料显示WebBench基准测试表明IIS 返回静态内容的速度要比IIS 快％即使以IIS 的隔离模式运行IIS 服务器（这时IIS 的体系结构与IIS 的相似）同样也能从httpsys驱动程序的应答缓冲区和其他改进之处获益
　　
　　另外微软在httpsys驱动程序中采用了许多优化的算法使其能够将请求直接转发到适当的工作进程在IIS 和IIS 中必须通过多个步骤才能确定进程的哪一个实例拥有了应当接收当前请求的Web应用但在IIS 中httpsys注册了所有IIS 应用赋予每一个进程一个句柄IIS内部利用这些句柄来标识注册的应用程序要用到的一个或多个名称空间因此当httpsys接收到一个HTTP请求它能够很快地将请求从内核模式的httpsys传递到正确的用户模式的Web应用
　　
　　httpsys驱动程序还要执行其他一些任务其中包括
　　⑴ 将传入的URL与各种长度格式方面的规则进行比较
　　⑵ 管理传入请求的队列
　　⑶ 担负着记录IIS Web网站日志信息的任务（从而提高了记录日志的性能）
　　⑷ 实施带宽限制策略以及支持TCP/IP级的管理
　　⑸ 实现客户证书请求服务（但不支持安全套接字层——SSL）
　　
　　由于httpsys是一个操作系统的驱动程序而不是一个IIS组件因此该驱动程序的配置在注册表而不是IIS配置数据中进行当前还有许多httpsys的注册表设置项目尚无正式的说明文档它可能意味着微软不鼓励用户修改这些设置因为这些设置项目将来可能会有变化httpsys驱动程序的注册表设置项目位于HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP下面在这里可添加各种注册键（默认配置中不包含这些注册键）诸如
　　⑴ EnableNonUTF如果加入EnableNonUTF子键并将它的值设置成httpsys只接受UTF编码的URLUTF的全称是Universal Character Set（UCS）Transformation Format 这是一种字符集标准标准全文在它允许使用多国语言的字符集默认情况下EnableNonUTF的值是表示IIS接受UTFANSI双字节字符集（DBCS）编码的URL
　　⑵ PercentUAllowed当这个子键设置成时（默认值）httpsys认可那些部分字符用％uNNNN表示的URL其中NNNN是一组表示实际字符的数字当PercentUAllowed设置成时IIS 将拒绝那些部分字符用这种方式表示的URL
　　
　　％uNNNN是一种不太常用的Unicode符号不要将它与常见的UTF表示形式混淆在UTF表示形式中％表示一个空格例如相当于两者之间的转换由IE浏览器自动完成不管EnableNonUTF和PercentUAllowed设置成了什么值IIS 都会接受
　　
　　这两项设置再加上其他可以在IIS 文档中找到的设置项目从一个侧面反映了IIS 在URL解析方面的改进在IIS 中一些重大的安全问题与Web服务器解析URL的方式有密切的关系现在微软终于解决了原先存在的缺陷同时作出了一些改进允许管理员更加明确地定义IIS 解析URL的规则在天生具有国际化特点的Internet上多国语言并存这些改进之处尤其具有重要意义
　　
　　关于Unicode的更多信息请参见关于IIS 缺陷的更多信息请参见 在Windows Server Resource Kit中可以找到一个帮助配置httpsys的工具
　　
　　■ WCore
　　
　　默认情况下IIS 在工作进程隔离模式下运行如图五所示在这种模式中对于每一个Web应用IIS 都用一个独立的wwpexe的实例来运行它wwpexe也称为工作进程（Worker Process）或WCore
　　　
　　图
　　因此工作进程隔离模式不存在进程内（InProcess）应用程序存在的问题有效地提高了可靠性和安全性可靠性的提高是因为一个Web应用的故障不会影响到其他Web应用也不会影响httpsys每一个Web应用由WSVC单独地监视其健康状况安全性的提高是由于应用程序不再象IIS 和IIS 的进程内应用那样用System帐户运行默认情况下wwpexe的所有实例都在一个权限有限的网络服务帐户下运行如图六所示必要时还可以将工作进程配置成用其他用户帐户运行
　　　
　　图
　　如果缓冲区溢出攻击成功入侵了一个Web应用攻击者只能访问当时运行工作进程的帐户有权访问的资源默认的网络服务帐户不能写入Inetpub文件夹执行权限也极其有限所以象CodeRed蠕虫之类的攻击根本不可能得逞
　　某些Web应用特别是有些Internet Server API（ISAPI）筛选器在进程外运行时可能会遇到问题在IIS 和IIS 中ISAPI筛选器总是在Inetinfo之内运行它们