今天使用IIS管理器启动网站时，出现“另一个程序正在使用此文件，进程无法访问。”的错误提示。说明 此服务器的tcp 80端口已打开。一般情况下，可能是有另一个WEB服务已启动，它打开了80端口，另一种可能就是某个软件打开了80端口。
如何查看哪个程序打开了tcp 80端口呢？使用“开放端口查看软件Active ports”就可以一目了然了。我查看了一下我的机器情况，如图所示：
Thunder5.exe打开了Tcp 80端口，原来是这个家伙惹的祸，将其关闭。再重启IIS，一切正常。
　　如果在IIS启动之后再开Thunder5.exe，Thunder5仍能正常使用。说明Thunder5.exe发现tcp 80端口已打开就不再使用此端口了。看来启动IIS还得有个顺序，那就是先启动IIS再启动Thunder5.exe。
　　补充：其实Thunder5可以通过设置不让其打开80端口的。这样就不用考虑启动顺序的问题了。具体操作是：Thunder5菜单”工具”->”选项”->”连接” 项，去掉“把80端口和443端口作为接入设备的备用端口” 前面的复选框！

IIS问题(IIS假死、停止， 回收应用程序池)
卸载
a) 把整个IIS卸载
b) 把 %windir%\system32\inetsrv 删除掉
把%windir%\iisX.log删除掉。 X 是(w2k-iis5.log,xp-iis6.log)
也把 \inetpub\ 目录删除掉
（可以在safe-mode里删除）
c) 重装IIS，打上最新补丁
iis6假死的一种解决方法
大家在使用iis6时..如果装了动网论坛.肯定有出现过iis6假死现像..就是asp网页打开慢..但是iis却是正常的..静态网页打开速度一样..这时候..我一直是重启的方法..查了官方的资料结果没有…据官方资料说..win2003很快就要打这个补丁了..是iis6对access驱动支持不理像..也算是一个bug吧..由于我的服务器虚拟主机多..而且大多支持asp..如果一旦假死就 无法运行..在多方面的资料查找下..找到了一个比较简单的方法..具体我测试是通过了..iis6自带数据应用程序池..现在就利用他来解决假死..
首先把bbs设一个单独的目录..然后点击应用程序池..新建应用程序池.输入应用程序池id..
然后把bbs的虚拟目录下面的.就用程序池..选择刚才新建的应用程序池…
然后再回到刚才设好的应用程序池…点击..属性…把回收工作进程数(分钟)及回收工作进程数还有在下列时间回收时间进程勾上..然后在下列时间回收程序池里左边添加..选择一个时间..一般来说..网站到凌晨3点的时候.基本人都很少了..这时回收一下bbs的进程数..就可以解决了iis假死的现像..
当然还可以配置其他信息..比如说iis6的用户名.. 我们可以打开计处机管理..然后打开计算机用户管理..添加一个用户..设置好后..在应用程序池里面..标识..把添加的用户放上去..用用户来测试回收的进程..当然还有..其他配置..其实很简单..只要你好好看一下..就能明白意思…
对于我来说..这种方法可能不太方便..所以我用一个工具来回收应用程序池..这样方便而且快捷..个人用户当然不需要这种工具..我是公司工作..服务器压力挺大..所以都用工具来解决一些问题.所括.iis的备分.及虚拟主机ip的统一修改及端口访问的ip记录..用批处理是一个很简单又方便的方法.所以.把一台服务器做的安全..并不是哪么容易的事..特别是iis..经常去官方网站搜索资料是一个好习惯..还有就是经常性的访问日志..及注册表的用户还有加载运行的程序.及服务也是一个好方法..所以.要学会如何遇到问题如何处理问题!!!!
windows系统官方网站知识数据库:

http://support.microsoft.com/default.aspx?scid=fh;ZH-CN;KBHOWTO

关于WIN2003 IIS6.0无故停止的问题
iis回收应用程序池设置不好，容易造成用户登陆自动退出
这个问题曾经困扰了我半个月时间.一台运行WIN2003 IIS6.0的服务器.不定时出现.ASP不能访问.可是其间.CGI PHP HTM JSP 一切正常.经过多次试验.解决问题如下.
打开IIS 你就会看到应用程序池.默认只有一个应用程序池.你查看应用程序池的属性.会发现他的回收时间.默认多达.1740分钟.就是说.需要在1740分钟后才回收此应用程序池.如果在这个时间内.达到请求的最高限制.那么就会出现ASP假死的情况.这个就是大型网站出现假死的情况.反而.小型网站确不会出现这样的情况.因为他请求少.流量少.还没达到限制数量.
少说费话.怎么解决?;
当然要看你的服务器上拉了多少个网站而定.以下是我的解决方法.
单个网站解决方法.;
(很简单.把应用程序池回收时间缩短到300-600分钟.其间回收过程中.需要占用一点CPU资源.没办法.为了稳定性.再把回收时间设为凌晨5点)
多网站解决方法.
我的服务器目前拉了70个网站左右.我新建六个应用程序池.把每个池回收时间缩小到300分钟.然后再分配每个池10个网站左右(这个分配是要求你的网站访问量所定)如果某个网站.访问量大.就单独给他一个程序池.但是这样做的后果就是需要大内存.一个池现在占用我120M内存左右.反正内存大.没关系.}'
多网站如何分配应用程序池??.打开IIS–查看你要分配的网站属性..查看主目录–在下面你就会看到应用程序池了.分配一个就行了.
以上是我的临床试验.服务器现在稳定的运行中.本来几乎一天就停一次.要我重起IIS才行..

关于IIS 6.0的故事一言难尽，如果你已经在IIS技术上有所投资，IIS 6.0无疑是一个动人的、非听不可的话题。鉴于IIS 6.0和以前版本的差别实在太大了，只用一篇文章很难做到面面俱到，所以本文首先探讨IIS 6.0的安装、体系结构以及由于体系结构方面的差异带 来的全新服务功能，下一篇文章接着介绍IIS 6.0的新特性——其中有些你可能还没有听说过，另外还
有默认配置方面的一些重要变化，这些变化可能会影响到你的迁移计划。
　　一、安装IIS 6.0
　　首先从最基本的说起吧。IIS 6.0包含在Windows Server 2003服务器的四种版本之中：数据中心版，企业版，标准版，Web版。另外，顺便再回答一个最常见的IIS 6.0问题：IIS 6.0不能在Windows XP、2000或NT上运行。
　　安装好Windows 2003之后，马上就可以看到Windows 2003/IIS 6.0的与众不同之处，其中一个关键的变化是，除了Windows 2003 Web版之外，Windows 2003的其余版本默认不再安装IIS。按照微软过去的理念，安装操作系统的同时IIS也自动启动，为许多Web应用提供服务，Windows 2003的做法可谓一大突破。在Windows 2003中，安装IIS有三种途径：利用“管理您的服务器”向导，利用控制面板“添加或删除程序”的“添加/删除Windows组件”功能，或者执行无人值守安装。
　　第一次启动Windows 2003系统时，“管理您的服务器”向导自动启动，如图一所示。
图一
　　选择“添加或删除”角色，在“配置服务器”向导中可以看到一系列可配置的服务器角色，其中就有“应用程序服务器（IIS，ASP.NET）”选项，如图二，选中该选项之后点击“下一步”，向导提供了是否安装ASP.NET和Microsoft FrontPage服务器扩展的选项。可以看到，微软在这里采用了一种新型的“安装任何部件之前总是
征求用户意见”的IIS安装策略，对于微软来说，这是一个彻底的转变，证明微软确实在认真对待安全问题。

图二
　　使用控制面板中的“添加/删除Windows组件”功能还要灵活一些。在向导中选择“应用程序服务器”，再点击“详细信息”，向导显示出一系列组件的清单，其中就有“Internet信息服务（IIS）”选项，还有一些选项是以前的“添加/删除Windows组件”向导没有提供的，表一概括比较了IIS 6.0和IIS 5.0 的主要组件。如果从这里安装IIS 6.0，最后得到的Web服务器可能只支持静态内容（除非在安装期间选中了某些扩展组件）。选中Internet信息服务选项，再点击“详细信息”，可以看到IIS 6.0的子组件，如图三所示。

图三
表一：IIS 6.0和IIS 5.0组件比较
IIS 6.0 IIS 5.0
应用程序服务器 Internet信息服务
应用程序服务器控制台 公用文件
ASP.NET 文档
启用网络COM+访问 文件传输协议（FTP）服务
启用网络DTC访问 FrontPage 2000服务器扩展
Internet信息服务 nternet信息服务管理单元
后台智能传送服务（BITS）服务器扩展 Internet服务管理器（HTML）
BITS管理控制台管理单元 NNTP
BITS服务器扩展ISAPI SMTP
公用文件 万维网服务
文件传输协议（FTP）服务
FrontPage 2002服务器扩展
Internet信息服务管理器
Internet打印
NNTP服务
SMTP服务
万维网服务
Active Server Pages
Internet数据连接器
远程管理（HTML）
远程桌面Web连接
在服务器端的包含文件
WebDAV发布
万维网服务
消息队列
Active Directory集成
公用
下层客户端支持
MSMQ HTTP支持
路由支持
触发器
也许你已经注意到了表一列出的某些新增组件选项，但你注意到IIS 6.0少了什么吗？IIS 6.0中消失不见的最主要的一个项目是文档。在IIS 6.0中，所有文档都以帮助文件的形式发布，不再有IISHelp虚拟目录。在IIS 5.0中，如果从本地访问服务器，默认Web网站自动打开IIS的文档，但在IIS 6.0中，如果打开“

http://localhost”，只能看到一个声明网站正在构建之中的页面。

　　另外，在IIS 5.0的IISHelp虚拟目录中有一些错误处理页面，这些错误处理页面以ASP的方式实现。如果你要用到定制的（或者修改过的）帮助文件、错误处理页面，在IIS 6.0网站上必须自己创建该目录。
　　进一步分析IIS 6.0的子组件清单，可以发现：原来在IIS 5.0和IIS 4.0中默认安装的Internet服务管理器（ISM）已经不见了。但是，如果你点击“万维网服务”（IIS 6.0的子组件之一，但图三没有显示出来），再点击“详细信息”，可以发现IIS 6.0的万维网服务还有子组件，如图四所示，其中包括原来的Internet服务器管理器，不过现在已经改名为“远程管理（HTML）”；还有Windows 2003和XP版本的终端服务高级客户端（TSAC）——现在它叫做“远程桌面Web连接”。现在，我们不仅可以方便地添加或删除这两个子组件，对其他子组件也一样，包括：ASP，Internet数据连接器，在服务器端的包含文件，WebDAV发布，当然还有万维网服务。

图四
　　安装IIS 6.0的最后一种方式是无人值守安装。和以前一样，这仍旧是唯一一种能够将工具和默认Web网站安装到其他驱动器（而不是系统驱动器）的安装方式。Windows 2003无人值守安装方式大体上仍和Win 2K一样，都是用Sysocmgr和一个应答文件实施安装。当然，新的特性需要新的参数、选项，有关这方面的详细说明，可以在Windows 2003 Release Candidate 2 （RC2）找到，地址是：http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsnetserver/proddocs/datacenter/gs_installingiis.asp。
　　如果将IIS 5.0或IIS 4.0服务器升级到Windows 2003，IIS 6.0不会被设置成自动启动。也就是说，如果采用升级的方式安装，IIS 6.0默认是禁用的，除非遇到下列情况之一：
　　⑴ 以前的IIS服务器上已经安装了IIS Lockdown工具。
　　⑵ 存在注册子键
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\RetainW3SVCStatus，且它包含一个任意的注册键。例如，你可以创建一个名为EnableIIS6的键，设定它的值为DWORD类型的1。
　　⑶ 在无人值守的升级安装中，应答文件的[InternetServer]部分存在DisableWebServiceOnUpgrade = True/False条目。
　　二、支持服务
　　自IIS 6.0发布以来，它的某些新特性一直是人们关注和议论的焦点，成为众人瞩目的明星，但另一些Internet支持服务虽然不是经常有人说起，却同样值得关注，其中之一就是POP3服务和POP3服务Web管理器。我们无从得知微软为何不在“应用程序服务器”组件清单中列出POP3服务，但是继SMTP服务之后（SMTP服务随同POP3服务一起安装），管理员们盼望POP3服务已经很久了，他们一直在期盼着用一个简单的POP3服务来替代庞大的Microsoft Exchange Server。
　　统一描述、发现和集成协议（Universal Description, Discovery, and Integration，即UDDI）服务是Windows 2003提供的又一种新的功能，它也与IIS有关，但默认不安装（注意，Windows 2003 Web版不能安装UDDI）。UDDI是一种产业标准（即不是微软的发明），能够通过广告发布IIS服务器提供的Web服务——这里“广告”一词的含义与日常生活中的广告不同，它是指一种让客户程序（通常是Web浏览器）获知Web服务（通常是ASP.NET应用）各种细节的方式。UDDI仍在发展之中，但一些企业已经在内部采用UDDI，以便开发者将自己的代码发布给其他协作开发的人。有关UDDI的更多知识，可以在下列网站找到：http://www.uddi-china.org/（中文），http://www.uddi.org（英文），http://www.uddicentral.com（英文）。
　　最后一种重要的支持服务是后台智能传送服务，即 Background Intelligent Transfer Service或BITS。BITS是一种后台文件传输机制和队列管理器，也称作节流传输服务。BITS控制文件请求，减少带宽消耗并改善最终用户的体验。针对IIS启用BITS可保证Web服务器的服务质量，如果没有BITS，当100个用户同时下载一个500 MB的文件，服务器的带宽可能就被消耗殆尽，导致其他访问Web服务的用户频繁地遇到超时错误。如果BITS就象广告说的那样有效，可以料想它将是一种非常实用的服务。Windows 2003发布之后，按照计划，BITS还将移植到Win2K上。关于BITS的更多信息，请参见http://www.microsoft.com/windows.netserver/techinfo/overview/bits.mspx。
　　三、全新的内核
　　从体系结构上看，IIS 5.0和IIS 4.0其实是一样的：它们都是在用户模式下运行的发布Web内容的应用程序，或者在Inetinfo进程之内以System帐户运行，或者在Inetinfo进程之外以IWAM用户运行。虽然在较重的负载下，IIS 5.0也有相当出色的表现；不过从IIS 6.0开始，我们对IIS底层结构的看法应该改变了。为了使IIS不仅能够轻松地支持1000个Web网站，而且能够支持10000个甚至更多的网站，同时还要提高Web服务器的安全性和可靠性，微软放弃了原有的IIS内核，重新构造了一个。
　　另一个促使微软重新构建IIS内核的原因是，微软（以及其他厂商）认识到，Web服务器的性能和可靠性问题绝大部分是由于质量低劣的Web应用造成。IIS 5.0通过带缓冲池的Out of Process容器减轻这类问题。在IIS 5.0中，在Out of Process池中运行的应用一旦崩溃，一般不会波及到IIS本身，因为应用程序在Inetinfo之外的进程中运行，但运行在Out of Process池之内的所有Web应用都会终止——在默认情况下，所有的应用程序都在该池之中运行。在这种情况下，排解故障很不容易，因为要确定哪一个应用程序导致了问题非常困难。IIS 6.0将监听请求、创建和监视Web网站、运行Web服务这些不同的任务隔离了开来，这一新型体系可望解决IIS 5.0存在的问题。从理论上看，新的体系将极大地改善可用性、安全和性能；从实际情况看，根据微软和Beta测试者的报告，新的体系令稳定性和性能有了奇迹般地提高。IIS 6.0的内核体系主要建立在三个组件之上：W3SVC，http.sys，以及W3Core。
　　■ W3SVC
　　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）。
　　由于http.sys是一个操作系统的驱动程序，而不是一个IIS组件，因此该驱动程序的配置在注册表而不是IIS配置数据中进行。当前，还有许多http.sys的注册表设置项目尚无正式的说明文档，它可能意味着微软不鼓励用户修改这些设置，因为这些设置项目将来可能会有变化。http.sys驱动程序的注册表设置项目位于
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP下面，在这里可添加各种注册键（默认配置中不包含这些注册键），诸如：
　　⑴ EnableNonUTF8：如果加入EnableNonUTF8子键，并将它的值设置成0，http.sys只接受UTF-8编码的URL。UTF-8的全称是Universal Character Set（UCS）Transformation Format 8，这是一种字符集标准，标准全文在http://www.ietf.org/rfc/rfc2279.txt，它允许使用多国语言的字符集。默认情况下，EnableNonUTF8的值是1，表示IIS接受UTF-8、ANSI、双字节字符集（DBCS）编码的URL。
　　⑵ PercentUAllowed：当这个子键设置成1时（默认值），http.sys认可那些部分字符用％uNNNN表示的URL，其中NNNN是一组表示实际字符的数字。当PercentUAllowed设置成0时，IIS 6.0将拒绝那些部分字符用这种方式表示的URL。
　　％uNNNN是一种不太常用的Unicode符号，不要将它与常见的UTF-8表示形式混淆。在UTF-8表示形式中，％20表示一个空格，例如http://www.iisanswers.com/new article.htm相当于http://www.iisanswers.com/new％20article.htm，两者之间的转换由IE浏览器自动完成，不管EnableNonUTF8和PercentUAllowed设置成了什么值，IIS 6.0都会接受。
　　这两项设置，再加上其他可以在IIS 6.0文档中找到的设置项目，从一个侧面反映了IIS 6.0在URL解析方面的改进。在IIS 5.0中，一些重大的安全问题与Web服务器解析URL的方式有密切的关系，现在微软终于解决了原先存在的缺陷，同时作出了一些改进，允许管理员更加明确地定义IIS 6.0解析URL的规则。在天生具有国际化特点的Internet上，多国语言并存，这些改进之处尤其具有重要意义。
　　关于Unicode的更多信息，请参见http://www.unicode.org；关于IIS 5.0缺陷的更多信息，请参见 http://www.wiretrip.net/rfp/p/doc.asp/i5/d57.htm。在Windows Server 2003 Resource Kit中可以找到一个帮助配置http.sys的工具。
　　■ W3Core
　　默认情况下，IIS 6.0在工作进程隔离模式下运行，如图五所示。在这种模式中，对于每一个Web应用，IIS 6.0都用一个独立的w3wp.exe的实例来运行它。w3wp.exe也称为工作进程（Worker Process），或W3Core。

因此，工作进程隔离模式不存在进程内（In-Process）应用程序存在的问题，有效地提高了可靠性和安全性。可靠性的提高是因为一个Web应用的故障不会影响到其他Web应用，也不会影响http.sys，每一个Web应用由W3SVC单独地监视其健康状况。安全性的提高是由于应用程序不再象IIS 5.0和IIS 4.0的进程内应用那
样用System帐户运行，默认情况下，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网站或目录放入应用程序池。

图七
　　四、应用程序池详解
　　前面我们了解了IIS 6.0体系结构的关键组件，下面来看看有关应用程序池的一些问题。应用程序池的“属性”对话框有四页——回收，性能，运行状况，标识，如图六所示。在这些选项页中，最引人注目的恐怕就是“回收”页，使用该选项页可以管理工作进程的回收。在工作进程隔离模式中，
IIS可以配置成定期重新启动应用程序池中的工作进程，从而更好地管理那些有错误的工作进程。这确保了池中的应用程序运行正常，并且可以恢复丢失的系统资源。为了回收工作进程，失败工作进程接收请求的能力将被限制，直到它处理完存储在请求队列中的所有剩余请求。为了排出当前请求，可以给予进程配置限制。同一命名空间组的替换工作进程在旧的工作进程停止前启动，从而防止服务中断。旧的进程完成其未决的请求，然后正常关闭，或者如果在达到了配置的时间限制、请求数、设置的时间计划，或当达到指定的内存用量限制后仍没有关闭，则明确地终止进程。默认情况下，应用程序池每隔1740分钟（29小时）回收一次。
　　W3SVC根据“运行状况”页的选项来判断应用程序池运行是否正常，包括：每隔指定的时间Ping工作进程，时间按秒计，默认值30秒；启动时间限制（工作进程必须在指定的时间内开始）；关闭时间限制（工作进程必须在指定的时间内关闭）；是否启动快速失败保护（如果在指定的时间段内一定数目的工作进程发生失败，则禁用应用程序池）。另外，ISAPI应用程序（包括ASP.NET和asp.dll）可以声明自己不再适合提供服务，要求回收。
　　默认情况下，当IIS 6.0回收一个池时，它会使用一种称为overlapped recycle的回收技术。在这种回收模式下，失败的工作进程仍会保持运行状态，同时创建一个新的工作进程。IIS 6.0把新传入的请求传递给新的工作进程，但不拆除老的工作进程，直至老的工作进程处理完它队列中的请求，或者遇到超时错误。在此期间，TCP/IP连接不会丢失，因为有http.sys保持着连接的有效性。当失败的工作进程超时出错时，下一个请求传递给工作进程的请求是新的请求，因此原来保存在进程中的会话信息就会丢失。所有这类回收操作都自动进行，无需管理员干预，而且在大多数情况下，不会造成明显的服务中断现象。如有必要，可以将配置数据属性LogEventOnRecycle的值设置为1，指示W3SVC执行回收操作时生成一条事件日志记录。
　　对于那些不能以多个实例运行的应用程序，overlapped recycle回收技术可能引起问题。如果遇到这类问题，可以将配置数据属性DissallowOverlappingRotation的值设置成True（1），关闭某个应用程序池回收操作时的进程“重叠”现象。另外，对于失败的工作进程，有时我们可能不想将它拆除，仍旧保留该进程，以便检测和寻找发生问题的根源，这时可以将配置数据属性OrphanActionExe设置成执行文件的名字，使得工作进程成为“孤儿”时执行文件仍保持运行状态。
　　另一个与应用程序池有关的特性是，IIS 6.0允许将应用程序池配置成一个Web园（Web Garden）。要理解Web园的概念，可以设想这样一种情形：假设有一个IIS 5.0服务器和三个Web网站，每一个Web网站运行着相同的应用程序，如果IIS 5.0能够自动按照圆形循环的模式将请求依次发送给这些功能上等价、实际上分离的Web网站，将负载分离到三个不同的进程，就可以构成一个小型的Web农场（Web Farm）——这就是Web园。
　　在IIS 6.0的Web园中，我们不必创建额外的Web网站，只要指定用于某个应用程序池的工作进程的数量就可以了。具体的配置步骤是：打开应用程序池的“属性”对话框，转到“性能”页，在“Web园”下面的“最大工作进程数”输入框中输入进程数量，如图八。当服务器的负载较小，不需要额外的工作进程时，IIS 6.0在一定的时间后（默认20分钟，可配置）自动缩减实际的工作进程数量；如果负载变大，需要额外的工作进程，IIS 6.0再次增加工作进程数量。这一切操作都自动进行，不需要管理员干预。

图八
　　两个新的配置数据属性——SMPAffinitze和SMPAffinitzeCPUMask——允许配置为工作进程指派的特定处理器：将SMPAffinitized属性设置成true表示应该把分配给应用程序池的特定工作进程指派给特定的CPU，SMPProcessorAffinityMask属性用来配置十六进制的处理器掩码，该十六进制处理器掩码指出应用程序池中的工作进程应该绑定到哪个CPU。
　　写到这里，文章的篇幅似乎已经太长了。本文主要从体系结构的角度介绍IIS 6.0的新特性，并且尽力做到全面，至少要比通常见到的介绍更完善一些。文章的第二部分将涵盖更多的IIS 6.0新特性，你会发现许多新特性正是自己长久以来盼望的。
　　前文介绍了IIS 6.0的安装和Web服务器的新型体系结构。IIS 6.0新特性的数量多得令人惊奇，其中一些特性是如此引人注目，以至于人们的大部分注意力都被它们吸引。在这第二篇介 绍IIS 6.0的文章中，我们不仅将了解这些已成为“明星”的特性，还将关注一下IIS 6.0各种较少有人注意却同样重要的改进之处。
　　一、安全
　　微
软一次又一次地做着同样一件事情——某个软件产品出了问题，饱受人们诟病，于是赶紧发布新的版本将问题解决。例如，发布Windows NT 4.0之后，因稳定性问题而饱受批评；于是微软发布了Windows 2000，新操作系统的稳定性颇受好评，但Win 2K服务器默认安装的IIS 5.0却成了巨大的安全隐患，需要下大力气加以整治才能解决问题。IIS 6.0默认不安装，如果按照缺省方式安装，Web服务器只能提供静态内容服务。因此，从这个角度看，即使以后IIS 6.0应用引擎和组件突然出现了问题，IIS 6.0还是极大地降低了安全风险。另外，Windows Server 2003还有一个新的组策略“禁止安装IIS”，有了该组策略，我们就可以禁止Windows 2003在活动目录（AD）森林中禁止不准备作Web服务器用的机器上安装IIS 6.0，防止网络上出现根本无用的、不安全的IIS 6.0服务器。不过，目前这个组策略只对Windows 2003服务器有效，不能防止Windows XP Pro和Win 2K的机器安装IIS 5.0。
　　当然，由于刚刚安装好的IIS 6.0不支持动态内容，所以出现了第二个人们经常会问的问题：“为什么我的服务器不能运行ASP？”（前文提到，第一个人们经常会问的问题是：“IIS 6.0可以在Win 2K服务器上运行吗”？答案是“不”）。要想在IIS 6.0上运行程序，必须使用IIS 6.0的一种新特性，即Web服务扩展，或Web Service Extension（这个名字似乎意味着它与XML Web服务有某种关系，实际情况并非如此。）
　　如果要为某个程序启用Web服务扩展，首先打开IIS管理器（在“控制面板”→“管理工具”中。以前叫做Internet服务管理器或ISM），如图一，点击“添加一个新的Web服务扩展”，启动向导创建一个新的规则。为规则指定一个名字，然后找到想要启用的执行文件。另外，\system32\inetsrv下有一个iisext.vbs脚本，它也能够配置并管理运行带有IIS 6.0的Windows Server 2003的Web服务扩展、应用程序和单独的文件。管理员可以使用此脚本来启用和列出应用程序；添加和删除应用程序依赖性；启用、禁用和列出 Web 服务扩展；添加、删除、启用、禁用和列出单独文件。

图一
　　在图一中，注意“所有未知ISAPI扩展”和“所有未知CGI扩展”这两种Web服务扩展。默认情况下，这两种扩展是禁用的，意味着除非明确地允许一个应用在IIS 6.0上运行，否则它就不能运行。如果一个用户请求了某个没有启用的文件，IIS 6.0将向用户返回404错误——文件或目录没有找到，同时在W3SVC日志中记录“
404.2文件或目录无法找到：锁定策略禁止该请求”。在IIS 6.0中，404.2和其他子状态代码是W3SVC日志文件的一项可选功能，用来帮助排解故障、疑难（IIS 5.0和IIS 4.0中也有子状态代码，不过不会在日志文件中记录，但可以将它们转到定制的错误页面，便于根据子状态代码执行特殊的处理）。IIS 6.0的子状态代码很有用，它们提供了描述问题的详细信息，例如：403.20，禁止访问：Passport登录失败；403.18，禁止访问：无法在当前应用程序池中执行请求的URL；404.3，文件或目录无法找到：MIME映射策略禁止该请求；500.19，服务器错误：该文件的数据在配置数据库中配置不正确。所有这些错误和其他错误都映射到定制的错误页面，错误页面不会把子状态代码发送给用户，攻击者无法获知具体的错误信息。
　　另一个安全方面的改进之处是IIS 6.0允许指派一个加密服务提供者（Cryptographic Service Provider，CSP），能够将基于硬件的安全套接字层（SSL）加速器集成到IIS 6.0，从而把加密任务从服务器的通用CPU转移到了专门为加密操作而优化的专用设备，有利于提高性能和可靠性。
　　二、配置数据
　　在IIS 5.0和IIS 4.0中，配置数据库采用二进制文件结构，但IIS 6.0放弃了这一做法。IIS 6.0的配置数据由两个XML文件构成：一个是Metabase.xml，包含IIS 6.0服务器的配置信息；另一个是mbschema.xml，包含配置数据的模式定义。IIS管理器提供了一项新的功能，允许保存配置数据副本，只要右击Web网站，然后选择“所有任务”→“将配置保存到一个文件”，然后指定配置数据副本的文件名字和保存路径即可。按照这种方式保存配置数据时，IIS 6.0利用系统的机器码（Machine Key）加密配置数据的某些部分，因此，配置数据的副本只对创建该副本的机器有用。
　　不过，在“将配置保存到一个文件”对话框中，我们可以选中“用密码对配置进行加密”选项，然后指定密码，用密码来保护导出的配置文件。如果提供了密码，IIS 6.0将用密码来替代机器码，以后只要提供同一个密码，就可以将配置数据导入到另一个服务器。另外，我们可以使用命令行脚本iisback.vbs（在systemroot\System32中）创建和管理远程或本地计算机的IIS配置的备份副本，管理员可以使用此脚本工具创建其IIS配置的备份副本，从备份副本还原IIS配置以及列出和删除备份副本。
　　有些时候，我们只要保存某个应用程序池、Web网站或虚拟目录的配置，而不是保存全部的配置信息，这时可以按照如下步骤操作：右击要保持配置信息的对象，选择菜单“所有任务”→“将配置保存到一个文件”，如图二所示，如果准备将配置数据导入到另一个服务器，必须提供加密文件的密码。

图二
　　如果右击一个应用程序池、Web网站组或单个网站，然后选择“新建”→“应用程序池（来自文件）”，或者“新建”→“网站”→“来自文件”，或者“新建”→“虚拟目录（来自文件）”，就可以从保存的配置文件创建新的应用程序池、Web网站或虚拟目录。因此，必要的时候，我们可以只创建和配置一个对象，利用“将配置保存到一个文件”功能导出对象
的配置信息，然后利用“新建”→“虚拟目录（来自文件）”等功能将配置信息导入到多个Web网站。这就是说，我们可以先精心配置一个模板，然后用它来创建和配置新的网站。当然，出现问题时，配置信息副本还可以用来恢复网站的设置。
　　由于IIS 6.0配置信息是可移植的，它还有另外一个好处，这就是方便了升级。假设我们升级时不能直接在Win 2K/IIS 5.0上安装Windows 2003/IIS 6.0，必须换一台机器，这时就要解决如何将IIS 5.0不可移植的配置数据转移到新的IIS 6.0服务器的问题。利用IIS 6.0配置数据的可移植性，解决办法是：首先安装好新的Windows 2003服务器，为原来的Win 2K服务器做一个完整的备份，然后在Win 2K服务器上安装第二个Windows 2003服务器将它升级，导出第二个Windows 2003服务器的配置数据（用密码加密），然后将配置数据导入到新的Windows 2003服务器。新安装的Windows 2003服务器必须作一些调整，例如允许IUSR帐户等，但至少现在不必重新执行全部配置操作了。
　　IIS 6.0的配置数据是标准的文本文件（XML文件），所以可以用记事本之类的文本编辑器打开和编辑。如果修改了IIS 5.0或IIS 4.0的配置数据，有时必须重新启动IIS，如果系统上网站的数量很多，可能需要不少时间，例如ISP的服务器就属于这类情况。为了解决这个问题，IIS 6.0支持一种“运行时允许编辑”功能。“运行时允许编辑”功能按照如下方式启用：在IIS管理器中，右击服务器，选择菜单“属性”，然后选中“允许直接编辑配置数据库”选项，如图三所示。启用了这个功能之后，如果我们用记事本打开配置数据文件，插入一个虚拟目录的配置，然后保存并关闭配置文件，IIS 6.0几乎立即就能根据配置文件的设置作相应的修改，根本无需重新启动。

图三
　　既然允许直接编辑配置文件，因配置文件不合法造成的服务器、应用程序故障也必然增多。为此，IIS 6.0提供了配置文件历史版本目录，即\system32\inetsrv\history，每次修改配置数据或重新启动IIS 6.0，IIS 6.0都会在该目录中保存一份原有的配置数据。
　　三、IIS管理器
　　每次产品重大升级，人们都会试图从用户界面寻找令人激动的新功能。IIS 6.0的管理器确实有了变化，不过改动之处出乎意料地少。
　　其中一个改动之处虽小，但很实用。如果在IIS管理器中右击一个文件夹，现在可以选择“权限”菜单打开文件夹的“安全”对话框。在这个对话
框中可以设置文件夹的NTFS授权，不必再离开IIS管理器。虽然这是一个小小的改动，也许它今年会为全世界所有的IIS管理员总共节省数千小时的工作时间。
　　右击一个Web网站，选择“属性”，转到“目录安全性”页，点击“安全通信”下面的“编辑”按钮，在这里可以找到另一个重要的改动之处——安全通信属性页允许配置SSL、证书信任列表（CTL）、客户证书。在IIS 5.0和IIS 4.0中，除非在Web网站上安装一个证书，否则不能访问该属性页，这一限制令人不快，因为从技术上看，配置CTL、客户证书并不要求服务器上安装了证书，换句话说，在IIS 5.0中我们安装证书的唯一用途可能就是因为用户界面需要它。IIS 6.0改正了这一多余的要求，现在我们不必在Web服务器上安装证书也可以访问和使用该属性页了。
　　四、通配符应用程序
　　如果你熟悉IIS 5.0和IIS 4.0的ISAPI筛选器，可能也熟悉它们的缺点。ISAPI筛选器不仅编写困难，而且由于它们在Inetinfo进程内运行，如果编写时不小心留下了一点错误，很容易导致灾难性的后果，出错的代码可能造成整个IIS崩溃。另外，ISAPI筛选器不能拥有常规ISAPI DLL拥有的功能。当然，不管怎样，在IIS 5.0和IIS 4.0中，ISAPI筛选器仍是一种非常有用的组件，是唯一可以针对所有进入Web服务器或Web网站的请求执行操作的代码。
　　IIS 6.0提供了一种更加灵活的新型机制来提供通常由ISAPI筛选器提供的服务，它就是ISAPI截取器（Interceptor），或者称为通配符应用程序（Wildcard Application）。通配符应用程序的配置方式是：在IIS管理器中右击Web网站，选择菜单“属性”，转到“主目录”页面，点击“应用程序设置”下面的“配置”按钮，出现“应用程序配置”对话框，如图四所示。在对话框的“映射”页中，我们可以将一个或多个ISAPI DLL配置成通配符应用程序。对于每一个接收到的请求，IIS 6.0将调用这里列出的各个通配符应用程序。除了针对所有网站配置通配符应用程序，还可以针对单个网站或在目录层次上配置通配符应用程序。由于这些ISAPI截取器是标准的ISAPI应用程序，它们具有普通ISAPI应用程序具备的所有功能，包括访问消息正文的能力，而不仅仅象ISAPI筛选器那样访问消息头。

图四
　　通配符应用程序可以做到开发者要做的任何事情，诸如URL定制、验证身份、记录特殊的日志信息、检测攻击企图、创建内容，等等。通配符应用程序结束处理后，它把请求转交给适当的处理引擎（例如处理ASP页面的asp.dll），由处理引擎进一步处理请求。另外，通配符应用程序还可以通过调用为ISAPI应用程序新增的ExecuteURL功能
，将请求传递到同一个应用程序池中的任意页面。
　　新增的ISAPI通配符应用程序为创造性的应用程序设计大开方便之门。例如，IIS 6.0的URL授权功能就是作为一个ISAPI通配符应用程序（urlauth.dll）实现。URL授权功能允许IIS 6.0根据一系列的规则授予对某个URL的访问权，例如用户是否为某个组的成员、地理位置，以及其他在数据库或AD中与用户有关的信息。有关ISAPI通配符应用程序和URL授权的更多信息，请参见IIS 6.0的帮助文档。
　　五、日志功能
　　服务器的日志功能很少成为首要的关注对象，但却是日复一日的服务器管理和监视工作不可或缺的助手。IIS 6.0在日志功能方面有许多重大的改进，但遗憾的是，W3SVC日志事件仍不能以本地时间记录。
　　在IIS 6.0中，记录日志的功能已经改为由http.sys实现，http.sys在内核模式下运行。这一改进加快了日志写入速度，同时避免了多个工作进程争用同一日志文件。某些特殊的情况下，http.sys会遇到错误，这时它应该但却不能将日志信息写入Web网站的日志，例如，工作进程正在被回收，禁止http.sys处理用户请求，或者用户试图连接到服务器，但请求中只提供了IIS所需信息的一部分。如果出现这类情况，http.sys将把事件写入一个新的日志文件httperr.log。
　　在排解故障、优化IIS 6.0的过程中，httperr.log日志文件是十分重要的。默认情况下，httperr.log文件保存在\system32\logfiles目录，但可以修改，修改方法是找到HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters注册子键，在它下面添加一个名为ErrorLoggingDir的字符串值，在ErrorLoggingDir中设置保存日志文件的完整路径。在httperr.log日志文件中可以找到的信息包括：所有的503（服务不可用）错误，空闲连接超时，解析URL时出现的各种错误，最后10个提交给失败的应用程序池的请求。
　　IIS 6.0还拥有一种称为二进制日志的功能，启用这个功能后，IIS 6.0将把Web网站的所有日志信息写入一个二进制格式的日志文件，日志文件的扩展名是.ibl。要启用二进制日志功能，只要把配置文件的W3SVCC/CentralBinaryLoggingEnabled条目设置成ture（1）即可。对于ISP来说，这个功能应该非常有用。ISP的每台机器上可能有1000甚至更多的Web网站，如果每个Web网站每天生成一个日志文件，日志文件的总数很快会达到一个天文数字。微软最近发布的Log Parser 2.0工具能够读取二进制日志文件并生成报告，这个工具可以从http://download.microsoft.com/download/iis50/utility/2.0/nt5xp/en-us/setup.exe下载。Log Parser 2.0还能够读取前面介绍的httperr.log文件并生成报告。
　　从很久以前开始，IIS就允许指定本地服务器上保存日志文件的目录了。不过，虽然IIS 5.0和IIS 4.0的IIS管理器允许在指定日志文件路径的时候输入一个远程服务器的通用命名规范（UNC）的路径，但Web服务器实际上不会把日志保存到远程服务器。只有IIS 6.0才真正支持日志文件路径的UNC路径名。
　　六、网站ID
　　对于IIS服务器来说，唯一标识一个网站的不是网站的名称，而是网站的ID数值。当我们在IIS 5.0和IIS 4.0中创建一个新的网站，Web服务器将下一个可用的数字顺序号指定给网站（即，Web服务器给默认站点指定的数字是1，下一个网站是2，接下来是2、3、4，等等），这个数
字就是网站的唯一ID。如果要访问一个网站的日志文件，首先必须知道该网站的ID，因为日志文件保存在\W3SVC\<网站的ID编号>目录。如果Web服务器上运行着一个以上的网站，仅仅依靠日志文件的路径名称根本无法判断哪一个日志目录属于哪一个网站。另外，无论是在编写管理脚本时，还是在修改配置数据文件时，网站ID都是必不可少的，例如，在IIS配置数据文件中指定ADSI（活动目录服务接口，Active Directory Service Interface）路径时往往要指定正确的网站ID。
　　尽管如此，在IIS 5.0和IIS 4.0中，从IIS管理器无法直接找到网站的ID编号。为此，IIS 6.0的管理器在网站清单中增加了一个新的“标识符”列，该列的内容就是网站的ID编号。不过，即使IIS 6.0 Web服务器上只有二三个网站，网站的ID也可能很大，例如387660891（因此该网站的日志文件路径是\W3SVC\387660891），不必奇怪，IIS 6.0不再按照顺序指定网站的ID了——它根据网站的名字计算出网站的ID。
　　如果你编写了一些脚本程序辅助管理，这些脚本要求使用原有的网站ID顺序生成方式，可以禁用IIS 6.0新式的ID生成方式，具体的操作步骤是：找到HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InetMgr\Parameters注册子键，创建一个REG_DWORD值IncrementalSiteIDCreation，将它设置为2（注意，默认情况下，该键不存在）。
　　七、异步CGI处理
　　IIS 5.0和IIS 4.0以同步方式运行CGI（Common Gateway Interface，通用网关接口）进程，这实际上意味着每次只有一个线程能够访问一个CGI进程，所以IIS 5.0和IIS 4.0对CGI支持的可伸缩性不佳。IIS 6.0能够异步运行CGI进程，所以如果一个线程调用了一个CGI应用程序，它不必再等待CGI进程处理完毕和返回信息。异步CGI改善了IIS服务器运行CGI Web应用程序的性能，使得IIS能够运行更多执行关键任务的基于CGI的应用程序。
　　当Web服务器接收到包含CGI程序名和程序所需参数的URL时，CGI程序开始执行。如果将CGI程序编译为可执行 （.exe）文件，则必须提供包含程序执行权限的目录，以便用户可以运行程序。如果CGI程序以脚本形式（例如Perl脚本）编写，则既可为目录提供执行权限，也可为其提供脚本权限。另外，如果要使用脚本权限，必须将脚本解释程序标记为脚本引擎。
　　必须注意的是，默认情况下，IIS_WPG组不具备启动CGI进程的权限。如果创建了新帐户并将其添加到IIS_WPG组，还必须授予此帐户两种启动CGI进程的用户权限，即“调整进程的内存配额”和“替换进程级令牌”。
　　八、带宽限制
　　在IIS 5.0和IIS 4.0中，Web网站属性对话框的“性能”页允许启用带宽限制功能，指定允许网站占用的最大带宽。不过，这个功能不一定起作用，因为IIS 5.0和IIS 4.0不能直接操作服务器的网卡。
　　IIS 6.0则不同，第一次启用带宽限制功能时，Windows 2003自动安装QoS数据包计划程序供IIS服务器调用。QoS数据包计划程序使得服务器能够控制服务质量（即QoS），因此安装期间Windows 2003将临时地停止所有网络服务。配置好QoS数据包计划程序后，IIS才真正有了担负起控制网站带宽限制所需的驱动程序——对于ISP来说，这无疑是一个好消息。允许设置的最小带宽限制值是1024 Byte/秒。不要忘了检查一下网卡是否在Windows 2003硬件兼容清单（HCL）中，因为只有最新的网卡才支持QoS功能。
　　要配置QoS数据包计划程序，首先必须创建一个组策略控制台。点击“开始”→“运行”，输入“mmc”，然后点击“确定”。在控制台窗口中，选择菜单“文件”→“添加/删除管理单元”，点击“添加”，在“添加独立管理单元”对话框中，选择“组策略对象编辑器”，然后依次点击“添加”、“完成”、“关闭”、“确定”。现在依次扩展控制台中的“本
地计算机策略”、“计算机配置”、“管理模板”、“网络”，显示出“QoS数据包计划程序”，如图五所示。

启用带宽限制之前，请使用系统监视器检查“网络接口”对象中的总字节数/秒或当前带宽计数器。如果希望比较传入和传出流量，请检查发送的字节数/秒和接收的字节数/秒，再比较“网络接口”对象的值和网络连接的总带宽。对于“正常”的负载，服务器使用的带宽不应超过其全部可用带宽的50%。如果服务器有较大的高峰负载，请将正常负载保持在50%以下，剩下的带宽可在高峰期使用。
　　带宽限制可以是针对全局WWW服务的（即对所有网站都有效），也可以是针对单个网站的。设置全局WWW服务最大带宽不会替代已为服务器上的单个网站设定的最大带宽。单个站点根据已设置的最大值来限制带宽，而全局设置限制所有其他未限制带宽的网站。另外，全局WWW服务带宽限制设置不会影响FTP站点或FTP服务。
　　九、默认设置的变化
　　在IIS 6.0中，许多配置项目的默认值已经与IIS 5.0或IIS 4.0的不同。例如，默认的连接超时时间已经从900秒减少到120秒，另外，EnableParentPaths设置默认关闭。还有其他一些新的设置项目也会影响服务器的性能和行为，包括：
　　⑴ 如果某种文件类型没有在MimeMap配置属性中映射，所有对该类文件的请求将被拒绝。
　　⑵ 默认情况下，所有工作进程会在1740分钟后自动回收，回收期间会话信息可能丢失。
　　⑶ 运行CGI应用程序的用户上下文必须是一个IIS_WPG组的成员。
　　⑷ Windows 2003不安装Collaboration Data Objects for Windows NT Server（CDONTS）。微软建议开发者改用CDO for Windows 2000（CDOSYS）对象。
　　⑸ ASP请求默认限制在204800字节之下，每一个域限制在100 KB之下。IIS 5.0和IIS 4.0没有这方面的限制。
　　⑹ 默认情况下，http.sys仅接受标题小于16 KB的请求。
　　本文关于IIS 6.0的介绍就到这里结束，虽然文章很长，但还是不可能做到面面俱到，例如，还没有提及受到广泛关注的Passport验证和摘要验证方面的改进，本文的重点放在一些具有突破性意义的IIS 6.0新特性以及几种较少有人提及的功能，以此证明IIS 6.0改进的广泛性、深入性。从许多方面来看，IIS 6.0的风头甚至盖过了Windows 2003——而且许多人认为，IIS 6.0确实有资格占据舞台的中央。

可能的原因1：
win2003 server下的IIS6默认设置下对每个运行在默认应用池中的工作者进程都会经过20多个小时后自动回收该进程，造成保存在该进程中的session丢失。
因为Session,Application等数据默认保存在运行该Web应用程序的工作者进程中,如果回收工作者进程，则会造成丢失。
解决办法：
修改配置，设置为不定时自动回收该工作者进程，比如设置为当超出占用现有物理内存60％后自动回收
该进程。通过使用默认应用程序池，可以确保多个应用程序间互相隔离，保证由于一个应用程序的崩溃不会影响另外的Web应用程序。还可以使一个独立的应用程序运行在一个指定的用户帐号特权之下。
如果使用StateServer方式或者Sql Server数据库方式来保存Session,则不受该设置的影响。
可能的原因2：
系统要运行在负载平衡的 Web 场环境中，而系统配置文件web.config中的Session状态却设置为InProc（即在本地存储会话状态），导至在用户访问量大时，Session常经超时的情况。引起这个现象的原因主要是因为用户通过负载平衡IP来访问WEB应用系统，某段时候在某台服务器保存了Session的会话状态，但在其它的WEB前端服务器中却没有保存Session的会话状态，而随着并发量的增大，负载平衡会当作路由随时访问空闲的服务器，结果空闲的服务器并没有之前保存的Session会话状态。
解决办法：
1.当您在负载平衡的 Web 场环境中运行 ASP.NET Web 应用程序时，一定要使用 SqlServer 或 StateServer 会话状态模式，在项目中我们基于性能考虑并没有选择SqlServer模式来存储Session状态，而是选择一台SessionStateServer 服务器来用户的Session会话状态。我们要在系统配置文件web.config中设置如下：

还要添加一项

2. 我们同时还要在SessionStateServer 服务器中启动ASP.NET State Service服务，具体设置：控制面板>>管理工具>>服务>>ASP.NET State Service，把它设为自动启动即可。
3. 每台前端WEB服务的Microsoft“Internet 信息服务”(IIS)设置
要在 Web 场中的不同 Web 服务器间维护会话状态，Microsoft“Internet 信息服务”(IIS) 配置数据库中 Web 站点的应用程序路径（例如，\LM\W3SVC\2）与 Web 场中所有 Web 服务器必须相同。大小写也必须相同，因为应用程序路径是区分大小写的。在一台 Web 服务器上，承载 ASP.NET 应用程序的 Web 站点的实例 ID 可能是 2（其中应用程序路径是 \LM\W3SVC\2）。在另一台 Web 服务器上，Web 站点的实例 ID 可能是 3（其中应用程序路径是 \LM\W3SVC\3）。因此，Web 场中的 Web 服务器之间的应用程序路径是不同的。我们必须使Web 场Web 站点的实例 ID 相同即可。你可以在IIS中把某一个WEB配置信息保存为一个文件，其他Web 服务器的IIS配置可以来自这一个文件。您如果想知道具体的设置请访问Microsoft Support网站：
补充一些相关资料:
PRB: Session Variables Are Lost If You Use FRAMESET in Internet Explorer 6.0

http://support.microsoft.com/kb/323752/EN-US/#

PRB: Session Data Is Lost When You Use ASP.NET InProc Session State Mode

http://support.microsoft.com/?id=324772

PRB：如果您使用 SqlServer 或 StateServer 会话模式 Web 场中会丢失会话状态

http://support.microsoft.com/default.aspx?scid=kb;zh-cn;325056

ASP.NET Session State FAQ

http://www.eggheadcafe.com/articles/20021016.asp

作者：Patrick Y. Ng
原文地址：http://forums.asp.net/7504/ShowPost.aspx
译者：Tony Qu (来自BluePrint翻译团队)
原文最后一次更新：2004年9月21日
本文被分成两部分：
1.“理解Session State模式”——帮助你理解三种Session State的不同之处
2. FAQ
1.理解Session State模式
存储位置
InProc：session在服务器中以活动对象方式存储（aspnet_wp.exe）
StateServer: session被序列化并保存在单独的aspnet_state.exe的内存中。StateServer能够运行在另一台服务器上
SQLServer: session被序列化并保存在SQL Server中
性能：
InProc：最快，但是session数据越多，web服务器上消耗的内存也越多，它可能影响性能。
StateServer：当存储基本类型（如string,integer等）数据时，在同一个测试环境中它比InProc慢15%。如果你存储大量对象，序列化和反序列化可能影响到性能
SQLServer：当存储基本类型（如string,integer等）数据时，在同一个测试环境中它比InProc慢25%。它也有与StateServer一样的序列化性能问题。
关于Out-of-Proc（OOP，非InProc）模式的性能提示
如果你使用OOP模式（即StateServer或SQLServer），session state中的序列化和反序列化对象将成为你的主要性能消耗之一。对于基本类型，ASP.NET通过一种内部优化方法来完成序列化和反序列化。（基本类型包括所有的数字类型(如Int, Byte, Decimal,String, DateTime, TimeSpan, Guid, IntPtr和UIntPtr等)）
如果你有一个session变量（如一个ArrayList对象），且它不是一个基本类型，ASP.NET将使用BinaryFormatter来进行序列化和反序列化，那可能会相对慢一些。
所以出于性能考虑，最好使用上面列出的基本类型来存储所有的session state数据。例如，如果你需要存储两个东西，名字和地址，在session state中你既可以(方法a)使用两个string session变量来存储它们，也可以（方法b）创建一个内含两个string的类来保存它们，然后把这个类对象保存在一个session变量中。出于性能考虑，你应该选择方法a。
为了进一步理解这个主题，请看FAQ中的一个问题：“序列化和反序列化如何在SqlServer和StateServer模式下工作”
健壮性
InProc：如果工作者进程（aspnet_wp.exe）进行资源回收或者应用程序域(appdomain)重启动，session state就会丢失。这是因为session state是保存在一个应用程序域的内存空间中的。对配置文件（如web.config和machine.config）的修改或者\bin目录的任何改变（例如在你使用VS编译应用程序后产生了一个新的dll）都可能引起重启动，详细请见KB324772。在1.0中，也有一个bug可能引起工作者进程重启动，但这个bug在1.1中已经修复，见KB321792。
如果你使用的是IIS6.0，你可以在IIS Manager中找到Application Pools/DefaultAppPool，其中可以看到回收(Recycling)选项卡与性能(Performace)选项卡中是否有引起IIS工作者进程(w3svc.exe)停止工作的参数。
更多有关应用程序资源回收的内容，可以看我的另一篇FAQ：

http://www.asp.net/Forums/ShowPost.aspx?tabindex=1&PostID=232621

StateServer：解决了InProc模式的session state丢失问题。允许一个webfarm在中央服务器中存储session。只能在State Server上出现失败。
SQLServer：与StateServer相似。session state的数据在SQL Server重启后仍然保留着，你也可以按照KB311209的步骤使用SQL server failover cluster
警告
InProc：它不能在web garden模式下工作，因为在这个模式下会有多个aspnet_wp.exe在同一台机器上运行。建议在使用web garden使切换到State Server或SQL Server。仅在InProc模式下支持Session_End事件。
StateServer
- 在web farm中，请确认在所有的web服务器上有相同的。KB313091描述了如何设置它。
- 请确保你的对象是可序列化的。详见KB312112
- 为了在web farm中的不同web服务器上维护session state，IIS Metabase中的网站应用程序路径（如\LM\W3SVC\2）应该在所有的服务器上保持一致（大小写敏感）。详见KB325056
SQLServer
- 在1.0中有一个bug，如果你在连接字符串中指定integrity security（如”trusted_connection=true”或 “integrated security=sspi”），且你打开了asp.net的身份模拟，它将不会工作。这个问题在KB324479中有描述，不幸的是这份文档中的描述和原因部分是错误的。不过已经有一个QFE fix对它作了修复，这个fix将包含在1.0 sp3中。这个问题在1.1中已经修复了。
- 请确认你的对象是可序列化的，否则你的请求可能被挂住，详见KB312112。SQLServer模式的挂起问题已经在1.1中修复，KB324479的QFE fix也修复了这个问题。1.0 sp3也对这个问题作了修复。
- 为了在web farm中的不同web服务器上维护session state，IIS Metabase中的网站应用程序路径（如\LM\W3SVC\2）应该在所有的服务器上保持一致（大小写敏感）。详见KB325056
其他资源

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/aspnetsessionstate.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/CachingArchch2.asp

http://www.411asp.net/home/tutorial/specific/web/sessions

2. FAQ问题列表
Q: session state在部分浏览器上工作，而在其他一些上不工作。为什么呢？
Q: 在InProc模式中，为什么我有时会丢失所有的session？
Q: session state在一些web服务器上工作，但是在其他服务器上不工作。
Q: 为什么session state不可用?
Q: 为什么session_end没有触发?
Q: 使用InProc模式时，为什么我的session变量频繁丢失?
Q: 在session超时或删除之后，为什么SessionID保持不变
Q: 为什么SessionID每一次请求都会改变
Q: Session.Abandon()和Session.Clear()有什么区别
Q: session的Timeout属性是一个滑动超时值吗？
Q: 我可以在ASP.NET和ASP之间共享session吗？
Q: 我可以在web应用程序（例如虚拟目录或者IIS的应用程序）间共享session state吗？
Q: 在session state中可以存储哪些类型的对象?
Q: 为什么我的请求在切换到SQLServer模式之后挂住了?
Q: 为什么Response.Redirect和Server.Transfer在Session_End中不工作？
Q: 在Session_End中，我可以获得一个有效的HttpSessionState对象和HttpContext对象吗？
Q: 在web service中如何使用session？
Q：我正在写一个HttpHandler，为什么session stae不工作？
Q: 我正在使用web farm，并且每当我重定向到其他服务器时，session state就会丢失？
Q: 如果使用cookieless，我该如何从一个HTTP页面重定向到一个HTTPS页面？
Q: session state有没有一个锁机制来安排对session的访问顺序？
Q: 我该如何检测一个session过期，然后重定向到另一个页面
Q: 在Session_End中，我尝试使用SQL做一些清理工作，但是失败了，请问为什么?
Q: 我使用的是SQLServer模式，为什么我的session不会过期
Q: 我有一个以htm为扩展名的frameset页面，并且我发觉其中包含的每个帧在第一次请求时都有一个不同的SessionID，这是为什么？
Q: 我将EnableSessionState设置为ReadOnly，但是在InProc模式下，我仍然可以修改session，为什么？
Q: 我将cookieless设置为true，在Redirect之后session变量丢失了，为什么？
Q: 将cookieless设置为true有哪些缺点
Q: 在InProc模式下，我用编程方式改变了session的超时时间，它触发了Session_End，为什么？
Q: 在SQLServer模式下，我可以把session state保存在除tempdb之外的数据库中吗？
Q: 如何防止将未加密的字符串放在我的连接字符串汇总?
Q: 在使用SQLServer模式时，我需要怎样的SQL权限？
Q: 我可以自己写定制的session state模式吗？
Q: 在SQLServer或StateServer模式下，序列化和反序列化如何工作？
Q: 我该如何让我的state server更安全？
Q: 我能否可以使用非global.asax中的处理程序来订阅SessionStateModule.End事件？
Q: 不同的应用程序可以把他们的session state保存在同一个SQL Server上的不同数据库中吗？
Q: session state在部分浏览器上工作，而在其他一些上不工作。为什么呢？
A: 估计你没有使用cookieless,你必须保证你的浏览器支持cookie。请参考这份KB：http://support.microsoft.com/default.aspx?scid=kb;EN-US;q316112
Q: 在InProc模式中，为什么我有时会丢失所有的session？
A: 请见理解session state模式的健壮性部分
Q: session state在一些web服务器上工作，但是在其他服务器上不工作。
A: 可能是机器名的问题，见http://support.microsoft.com/default.aspx?scid=kb;EN-US;q316112
Q: 为什么session state不可用?
A:
- 首先，检查web.config、machine.config和Page标签来确认你启用了session state
参考资料：

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconsessionstate.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconpage.asp

- 请注意session state并非在任何地方、任何时间都可以使用，它仅在HttpApplication.AcquireRequestState事件之后可用。例如，在 global.asax中的Application_OnAuthenticateRequest处理程序中，session state不可用
- 请确认System.Web.SessionState.SessionStateModule已包含在配置文件的< httpModules>节中。一个常见的例子是，出于性能考虑，SharePoint应用程序会把这个模块从web.config文件中移除，因此导致session不可用
Q: 为什么session_end没有触发?
A: 这是最常见的问题之一
1. 请记住session_end仅在InProc模式中可用
2. 关闭浏览器，session_end是不会触发的。HTTP是一种无状态协议，服务器没有办法知道你的浏览器是否已经关闭。
3. 当有n分钟（n=timeout值）的无操作或调用Session.Abandon时，Session_End才会触发
4. 对于情况1而言，Session_End将由一个后台线程触发，这表示：
a. Session_End中的代码使用工作者进程账号运行，如果你访问如数据库这样的资源时，可能会有权限问题。
b. 如果在Session_End中发生错误，程序不会通知发生了什么
5. 对于情况2而言，为了让Session_End触发，session state必须先存在。这意味着你必须在session state中存储一些数据，并且已经完成了至少一个请求
6. 还是对于情况2而言，Session_End仅在被丢弃的session被找到的时候才会触发。这样的话，如果你在同一个请求中创建并丢弃一个 session，由于session没有被保存，因此也不会被找到，Session_End将不会被调用。这是v1.0和v1.1中的bug。
Q: 使用InProc模式时，为什么我的session变量频繁丢失?
A: 有可能是应用程序资源回收引起的，见http://support.microsoft.com/default.aspx?scid=kb;en-us;Q316148
在v1.0中有一个bug可能会导致工作者进程重启动。在v1.1和v 1.0sp2中已经修复。见http://support.microsoft.com/default.aspx?scid=kb;EN-US;321792
关于应用程序资源回收的详细信息，请见我的另一篇：FAQhttp://www.asp.net/Forums/ShowPost.aspx?tabindex=1&PostID=232621
Q: 在session超时或删除之后，为什么SessionID保持不变
A: 尽管在超时周期之后session state过期，sessionID将一直保持到浏览器session过期为止，也就是说，一个相同的sessionID可以有多次session超时，但是始终对应着一个相同的浏览器实例。
Q: 为什么SessionID每一次请求都会改变
A: 如果你的应用程序从未在session state中存储过数据。在这种情况下，那么每次请求都会创建一个新的session state（ID也是新的），但是不会被存储，因为里面什么数据都没有。
尽管如此，有两种例外可能产生相同的Session ID
- 如果用户使用相同的浏览器实例来请求另一个使用session state的页面，那么你每次获得的Session ID是相同的。详见“在session超时或删除之后，为什么SessionID保持不变？”
- 如果使用了Session_OnStart事件，即使session为空，asp.net也会保存session state。
Q: Session.Abandon()和Session.Clear()有什么区别
A: 主要的区别在于，如果你调用Session.Abandon(), Session_End将被触发（仅在InProcxi下适用），在下一个请求中，Session_Start触发。而Session.Clear()仅仅是清除数据，但没有删除session。
Q: session的Timeout属性是一个滑动超时值吗？
A: Session的Timeout是一个滑动过期时间，意思是一旦你的页面访问session state，过期时间就会向挪。注意，只要页面没有被禁用，在请求时页面就会自动访问session
Q: 我可以在ASP.NET和ASP之间共享session吗？
A：不可以。但是有一篇文章讲到了如何来绕过这个问题：http://www.msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/ConvertToASPNET.asp
当然也有一些第三方解决方案。
Q: 我可以在web应用程序（例如虚拟目录或者IIS的应用程序）间共享session state吗？
A：不能。
Q: 在session state中可以存储哪些类型的对象?
A：这是由你使用的模式决定的
- 如果你使用的是InProc模式，存储在session state中的对象是活对象，那么你就可以存储你创建的任何对象
- 如果你使用的是SQLServer或State Server模式，当处理一个请求时，session state中的对象对象将被序列化和反序列化，所以请确认你的对象都是可序列化的，而它们的类都作了可序列化标记。如果没有，session state将不会成功存储。在v1.0中，有一个bug，当这个问题发生时，如果使用SQLServer模式，请求可能在不知情的情况下被挂起。挂起的问题在v1.1和v1.0 sp3中已经修复。KB324479的QFE fix也包含了对这一问题的修复。
更多信息请见：http://support.microsoft.com/directory/article.asp?ID=KB;EN-US;q312112
Q: 为什么我的请求在切换到SQLServer模式之后挂住了?
A：请看问题“在session state中可以存储哪些类型的对象?”的答案
Q: 为什么Response.Redirect和Server.Transfer在Session_End中不工作？
A：Session_End是在服务器内部触发的，它基于一个内部的计时器。因此，在事件触发时，与任何HttpRequest对象无关。这也是为什么Response.Redirect 和Server.Transfer不工作的原因。
Q: 在Session_End中，我可以获得一个有效的HttpSessionState对象和HttpContext对象吗？
A: 你可以获得httpSessionState对象，你可以使用'Session'来访问该对象。但是你无法访问HttpContext，因为这个事件和请求没有任何关系。
Q: 在web service中如何使用session？
A: 需要在调用方使用一些技巧，你必须保存web服务使用的cookie。请见关于HttpWebClientProtocol.CookieContainer的MSDN文档。
尽管如此，如果你是通过代理对象从你的页面调用web服务，由于架构限制，web服务和你的页面无法共享session state。
如果你通过redirect调用web服务，这是可以完成的
Q：我正在写一个HttpHandler，为什么session stae不工作？
A: 你的HttpHandler接口必须实现标记接口IRequiresSessionState或IReadOnlySessionState，方能使用session state。
Q: 我正在使用web farm，并且每当我重定向到其他服务器时，session state就会丢失？
A: 为了在web farm中的不同服务器之间维护session state，IIS Metabase中的网站应用程序路径(例如 \LM\W3SVC\2)应该在所有的web服务器上保持一致（大小写敏感）。详见KB325056
Q: 如果使用cookieless，我该如何从一个HTTP页面重定向到一个HTTPS页面？
A: 尝试使用下面的代码：
String originalUrl = “/fxtest3/sub/foo2.aspx”;
String modifiedUrl = “https://localhost” + Response.ApplyAppPathModifier(originalUrl);
Response.Redirect(modifiedUrl);
Q: session state有没有一个锁机制来安排对session的访问顺序？
A：session state实现了读写锁定机制：
- 对session state有写权限（如<%@ Page EnableSessionState="True" %> ）的页面或帧将获得这个session的写锁，直到请求结束。
- 对session state有读权限（如<%@ Page EnableSessionState="ReadOnly" %> ）的页面或帧将获得这个session的读锁，直到请求结束。
- 读锁会阻塞写锁；读锁不会阻塞读锁；写锁会阻塞所有的读锁和写锁
- 这也是为什么当两个帧同时拥有session的访问权限时，一个帧必须等待另一帧先完成
Q: 我该如何检测一个session过期，然后重定向到另一个页面
A: 这是经常要遇到的问题，但不幸的是没有很简单的方法来完成它。我们将期待在一个主要版本中实现它。同时，如果你使用cookie，你可以在cookie中存储一个标志，这样你就可以区分新浏览器+新session及旧浏览器+过期session，下面的代码在session过期时会重定向到一个过期页面。
void Session_OnStart(Object sender, EventArgs e) {
HttpContext context = HttpContext.Current;
HttpCookieCollection cookies = context.Request.Cookies;
if (cookies["starttime"] == null) {
HttpCookie cookie = new HttpCookie(“starttime”, DateTime.Now.ToString());
cookie.Path = “/”;
context.Response.Cookies.Add(cookie);
}
else {
context.Response.Redirect(“expired.aspx”);
}
}
Q: 在Session_End中，我尝试使用SQL做一些清理工作，但是失败了，请问为什么?
A: 首先，session_End仅在InProc模式下支持。
第二，Session_End是用运行工作者进程(aspnet_wp.exe)的帐号运行的，这个账号可以在machine.config中指定。因此，在你的Session_End中，如果使用integrity security连接SQL，它将使用工作者进程账号身份连接，这可能会引起登录失败，这要看你的SQL安全设置了。
Q: 我使用的是SQLServer模式，为什么我的session不会过期
A: 在SQLServer模式下，session过期是由SQL Agent使用一个注册任务完成的，请确认你的SQL Agent是否已经运行。
Q: 我有一个以htm为扩展名的frameset页面，并且我发觉其中包含的每个帧在第一次请求时都有一个不同的SessionID，这是为什么？
A: 原因是你的frameset页面是一个htm文件而不是一个aspx页面
在通常情况下，如果一个frameset页为一个aspx文件，当你请求该页面时，会首先发请求给web服务器，你会收到一个asp.net session cookie（其中保存着session id），然后浏览器会为frame发送一个单独的请求，而每个请求将拥有相同的session id。
然而，因为你的页面是一个htm文件，第一个请求就不会获得任何session cookie，因为页面是由asp处理的而非asp.net，然后浏览器会为每个帧发送单独的请求。但是，这次每个单独的请求将不会持有任何 session id，这样的话每个帧将创建自己的session。这也是为什么你在每个帧中看到的session id都不同。最后一个请求将赢得胜利，因为它将覆盖前两个请求写入的cookie。如果你刷新一次，你将看到它们拥有了相同的session id。
这个行为是设计所决定的，简单的解决方法就是将frameset页面改称aspx
Q: 我将EnableSessionState设置为ReadOnly，但是在InProc模式下，我仍然可以修改session，为什么？
A: 尽管那些EnableSessionState被设置为ReadOnly，但是在InProc模式中，用户仍然可以修改session。唯一的区别在于session在请求中不会被锁住，这一限制是设计所决定的。对于这一点没有在msdn中提到我表示抱歉。
Q: 我将cookieless设置为true，在Redirect之后session变量丢失了，为什么？
A: 如果你使用的是cookieless，你必须使用相对路径（如..\hello.aspx），而不是绝对路径（如\foo\bar\hello.aspx）。如果你使用的是绝对路径，ASP.NET不会将session id保存在url中。
Q: 将cookieless设置为true有哪些缺点
A: 设置cookieless=true表示一些潜在的规则，主要有：
1. 你不能在你的页面中使用绝对路径
2. 在http和https之间切换的话，你必须做一些额外的动作
3. 如果你的客户发送了一个链接到一个朋友，URL将包含session id，两个用户可以在同一时间使用相同的session id
Q: 在InProc模式下，我用编程方式改变了session的超时时间，它触发了Session_End，为什么？
A: 这是InProc的一个bug。如果你更改session的timeout值为另一个值，Session_End将被调用（但不会调用Session_Start）。我们期待在v2.0中能够修复这个错误。
Q: 在SQLServer模式下，我可以把session state保存在除tempdb之外的数据库中吗？
A: 是的。见KB311209。
Q: 如何防止将未加密的字符串放在我的连接字符串汇总?
A: 见sql trusted connection或者将连接字符串以加密数据形式保存在注册表中。详情请见，KB329250和KB329290。
Q: 在使用SQLServer模式时，我需要怎样的SQL权限？
A: 调用者需要对下面的存储过程拥有EXEC权限，
dbo.TempGetAppID
dbo.TempGetStateItem
dbo.TempGetStateItemExclusive
dbo.TempReleaseStateItemExclusive
dbo.TempInsertStateItemLong
dbo.TempInsertStateItemShort
dbo.TempUpdateStateItemLong
dbo.TempUpdateStateItemShort
dbo.TempUpdateStateItemShortNullLong
dbo.TempUpdateStateItemLongNullShort
dbo.TempRemoveStateItem
dbo.TempResetTimeout
在v1.1中，你也需要对下面的存储过程拥有EXEC权限
dbo.TempGetStateItem2
dbo.TempGetStateItemExclusive2
请注意存储过程的拥有者必须对session state表（dbo.ASPStateTempSessions和 dbo.ASPStateTempApplications）拥有Select/Insert/Update/Delete 权限。通常，拥有者是执行installsqlstate.sql（或者持久版本，见KB311209）的帐号来安装sql session state需要的表、存储过程、数据库
也请注意，如果你的session state表在tempdb中（默认情况下）如果你对SQL Server进行资源回收，所有在这张表上的权限设置将丢失。
Q: 我可以自己写定制的session state模式吗？
A：（待翻译）
Q: 在SQLServer或StateServer模式下，序列化和反序列化如何工作？
A: （待翻译）
Q: 我该如何让我的state server更安全？
A:如果state server和web server运行在一台机器上，通过设置HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ aspnet_state\Param ters\AllowRemoteConnection的dword项为0，可以让state server仅在本地运行。这样就可以防止远程客户端连见到state server上。这一特性在v1.1中可用，在v1.0 sp3中也有。
state server必须受防火墙保护，以防止外部连接以保证真正安全。默认的端口是TCP 42424，你可以设置HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ aspnet_state\Param ters\Port来改变它。如果是本地模式，除了127.0.0.1以外，屏蔽所有外来连接；如果是远程模式,显式的禁用所有的地址，除了对wev服务器的连接。
使用IPSec是另一种保护state server的方式。
Q: 我能否可以使用非global.asax中的处理程序来订阅SessionStateModule.End事件？
A: 答案是否定的。当SessionStateModule触发End事件时，只有定义在global.asax中的方法才会被触发
这是出于安全原因考虑的才对此进行限制。假设asp.net允许用户使用的其他的处理程序来处理End事件。在这种情况下，用户通常使用一个页面方法作为处理程序，当你在事件订阅时传入处理程序，处理程序将与你的程序运行在的HttpApplication实例关联。请注意， HttpApplication实例会被回收来处理其他请求。这样的话，当End事件触发时，asp.net将调用处理程序，而与之关联的 HttpApplication实例已经被另一个请求所使用，这样的情况将引发各种各样的问题。为了避免这种危险，在v1.0中决定进调用 Global.asax中定义的方法。希望你们都可以忍受这一限制。
Q: 不同的应用程序可以把他们的session state保存在同一个SQL Server上的不同数据库中吗？
A: 答案是肯定的。详情请见：http://support.microsoft.com/default.aspx?scid=kb;EN-US;836680
摘自:冰戈–真诚的平凡 blog
摘自:tonyqus.cn blog