|
W3SVC也许是IIS 6.0体系中最不令人注意的组件，不过这并不说明它不重要。W3SVC的任务是根据配置数据的设置创建和监视工作线程，由工作线程运行Web网站应用。在IIS 5.0中，与IIS 6.0 W3SVC组件最接近的是IIS管理服务，IIS管理服务是Inetinfo的一部分；因此，如果Inetinfo出现问题，IIS管理服务也会出现问题，而且此时的IIS管理服务不能再重新启动Inetinfo或其他故障的应用程序。在IIS 6.0中，W3SVC作为一个独立的进程运行，Web应用的故障不可能波及W3SVC，因为W3SVC之内根本没有第三方的代码运行。W3SVC总是处于运行状态，因此它能够监视Web应用的健康状况，并在必要时采取行动。由于这一策略，服务器能够根据用户指定的参数监视和重新启动应用程序。 ■ http.sys IIS 6.0体系设计中最重大的变化是加入了http.sys驱动程序，http.sys驱动程序的任务是处理HTTP请求，而且它在内核模式下执行操作。不要小看这一改变，将处理HTTP请求的任务从IIS 5.0、IIS 4.0的用户模式改变到IIS 6.0的内核模式标志着新一代IIS服务器的诞生。 在Win 2K和NT 4.0中，IIS在用户模式下运行。运行在用户模式下的应用程序不直接与硬件通信，它们直接调用的是一些标准过程，这些标准过程或者将数据传入内核模式的组件（例如网卡驱动程序，图形子系统），或者调用内核模式组件的函数，以此完成保存文件、设置IP地址、将HTML文件发送到网络之类的任务。 用户模式和内核模式之间的转换是一项开销很大的操作，服务器首先从内核模式的TCP/IP栈将传入的HTTP请求传递给用户模式的Winsock，由Winsock将请求传递给IIS。从内核模式到用户模式的切换很快发生，但不可避免地给处理过程带来瞬间的延迟。当负载较大时，这种延迟不断累加，同时由于这种转换是必不可少的，所以管理员根本没有办法优化处理过程。 IIS 6.0的https.sys内核模式驱动程序极大地减少了用户模式和内核模式之间的切换次数。http.sys监听着HTTP请求，决定由哪一个用户模式的进程来处理该请求，或者是否由驱动程序本身返回用户请求的内容。 IIS 6.0在用户模式下运行，完全依赖内核模式的http.sys作为接收用户请求的服务器引擎。因此，http.sys必须能够在任何时候作出相应，必须具有极高的可靠性。用户代码可能导致进程出错，所以微软把http.sys设计成不执行任何用户代码，这样，即使应用程序出现了故障，也不会影响到IIS 6.0本身，IIS 6.0仍能够照常监听HTTP请求。 如果要从内核模式的缓冲区返回静态的应答，一个高速的、内核模式的、不允许运行应用程序代码的HTTP处理器是十分理想的，它减少了切换到用户模式的昂贵开销，能够从内核模式的缓冲区快速返回应答。IIS 6.0的http.sys就管理着这样一个缓冲区，而且使用了高度优化的启发式缓冲区算法来确定哪些内容要放入缓冲区，例如，http.sys可能只缓冲那些出现了一次以上请求的内容。 由于http.sys直接从应答缓冲区提取静态内容，不必再切换到用户模式，所以与IIS 5.0的性能相比，IIS 6.0的整体性能有了显著提升。根据微软的资料显示，WebBench基准测试表明IIS 6.0返回静态内容的速度要比IIS 5.0快150％。即使以IIS 5.0的隔离模式运行IIS 6.0服务器（这时，IIS 6.0的体系结构与IIS 5.0的相似），同样也能从http.sys驱动程序的应答缓冲区和其他改进之处获益。 另外，微软在http.sys驱动程序中采用了许多优化的算法，使其能够将请求直接转发到适当的工作进程。在IIS 4.0和IIS 5.0中，必须通过多个步骤才能确定进程的哪一个实例拥有了应当接收当前请求的Web应用，但在IIS 6.0中，http.sys注册了所有IIS 6.0应用，赋予每一个进程一个句柄，IIS内部利用这些句柄来标识注册的应用程序要用到的一个或多个名称空间。因此，当http.sys接收到一个HTTP请求，它能够很快地将请求从内核模式的http.sys传递到正确的用户模式的Web应用。 http.sys驱动程序还要执行其他一些任务，其中包括： ⑴ 将传入的URL与各种长度、格式方面的规则进行比较。 ⑵ 管理传入请求的队列。 ⑶ 担负着记录IIS Web网站日志信息的任务（从而提高了记录日志的性能）。 ⑷ 实施带宽限制策略以及支持TCP/IP级的管理。 ⑸ 实现客户证书请求服务（但不支持安全套接字层——SSL）。 ⑵ PercentUAllowed：当这个子键设置成1时（默认值），http.sys认可那些部分字符用％uNNNN表示的URL，其中NNNN是一组表示实际字符的数字。当PercentUAllowed设置成0时，IIS 6.0将拒绝那些部分字符用这种方式表示的URL。 ％uNNNN是一种不太常用的Unicode符号，不要将它与常见的UTF-8表示形式混淆。在UTF-8表示形式中，％20表示一个空格，例 这两项设置，再加上其他可以在IIS 6.0文档中找到的设置项目，从一个侧面反映了IIS 6.0在URL解析方面的改进。在IIS 5.0中，一些重大的安全问题与Web服务器解析URL的方式有密切的关系，现在微软终于解决了原先存在的缺陷，同时作出了一些改进，允许管理员更加明确地定义IIS 6.0解析URL的规则。在天生具有国际化特点的Internet上，多国语言并存，这些改进之处尤其具有重要意义。 关于Unicode的更多信息，请参 ■ W3Core 默认情况下，IIS 6.0在工作进程隔离模式下运行，如图五所示。在这种模式中，对于每一个Web应用，IIS 6.0都用一个独立的w3wp.exe的实例来运行它。w3wp.exe也称为工 如果缓冲区溢出攻击成功入侵了一个Web应用，攻击者只能访问当时运行工作进程的帐户有权访问的资源，默认的网络服务帐户不能写入Inetpub文件夹，执行权限也极其有限，所以象CodeRed蠕虫之类的攻击根本不可能得逞。 某些Web应用，特别是有些Internet Server API（ISAPI）筛选器，在进程外运行时可能会遇到问题。在IIS 5.0和IIS 4.0中，ISAPI筛选器总是在Inetinfo之内运行，它们的设计目标本来就不是在进程外运行，正是由于这个原因，某些筛选器在IIS 6.0的工作进程隔离模式中运行时可能会出现问题——特别地，调用SF_READ_RAW_DATA或SF_SEND_RAW_DATA的筛选器尤其明显。为此，IIS 6.0还提供了第二种操作模式，称为IIS 5.0隔离模式。如果ISAPI筛选器不能在工作进程隔离模式下正常运行，在IIS 5.0隔离模式下应该没有问题。在这第二种操作模式中，应用程序仍旧能够从IIS 6.0的许多改进中获益，例如http.sys驱动程序带来的性能、可靠性的提高。 在IIS 6.0文档中，可以看到一种叫做“应用程序池”的新特性。一个应用程序池包含一个或者一组工作进程，而且应用程序池是可以命名的。应用程序池可以从下列角度理解：在IIS 5.0中，我们可以将应用程序保护设置为低级（IIS进程）、中级（缓冲池）、高级（隔离），这个功能虽然很有用，但如果我们想要在一个池（一个dllhost.exe的实例）中运行两个应用程序，在另一个池（另一个dllhost.exe的实例？）中运行另外两个应用，该怎么办？IIS 5.0没有提供命名dllhost.exe实例的途径，因而也就不能将两个特定的应用放入某个池运行。IIS 6.0的应用程序池允许指定名称，如图七，通过网站“属性”对话框的“主目录”页，可以方便地将Web网站或目录放入应用程序池。 |
http://www.ietf.org/rfc/rfc2279.txt，它允许使用多国语言的字符集。默认情况下，EnableNonUTF8的值是1，表示IIS接受UTF-8、ANSI、双字节字符集（DBCS）编码的URL。 
