配置IIS之虚拟目录
什么是IIS虚拟目录?有什么优点？
虚拟目录指在站点下建立一个虚拟子目录，指定一个固定的物理路径做为站点的应用路径。
1、虚拟目录与父级站点共用一个应用程序池,例如：站点TestWeb（c:\Inetpub\wwwroot\ TestWeb）下建立了SubTestA(D:\SubTestA)的虚拟目录.若TestWeb为设定了Framework V2.0，则SubTestA也必须是Framework V2.0的应用程序，否则将给带来Framework不匹配的各种错误。
2、虚拟目录必须将可执行文件（dll等)放置在父级站点的bin目录下。
3、虚拟目录中的web.config文件继承父级站点的web.config.就是说如果父级站点声明过的引用，在虚拟目录下的web.config中不应重复声明
4、虚拟目录中的应用其根目录为父级站点的根目录
5、虚拟目录中的AppSetting.config设置应使用相对路径来进行引用。
IIS中虚拟目录实现的目的是什么？
虚拟目录对应到URL的名称 如 http://zhidao.baidu.com/question/ 中question就是一个虚拟目录
很多时候，上传的文件多了，架设服务器当初设定的主目录所在盘空间往往就不够了，怎么办？这就需要设置虚拟目录。虚拟目录就是将其他目录以映射的方式虚拟到该FTP服务器的主目录下，这样，一个FTP服务器的主目录实质上就可以包括很多不同盘符、不同路径的目录，而不会受到所在盘空间的限制了。当用户登录到主目录下，还可以根据该账户的权限对它进行相应的操作，就像操作主目录下的子目录一样。如果用户被锁定在主目录下，这项功能将允许他们访问主目录之外的其它目录。
主目录设置的权限如果与虚拟目录的权限发生冲突，则以主目录权限为准。比如主目录设置的权限为读取和写入，而虚拟目录的权限只设置为读取，则其权限将会被主目录权限覆盖掉，自动拥有写入权限。
IIS 支持虚拟目录，通过在“服务器属性”对话框中的“目录”标签可以管理虚拟目录。建立虚拟目录对于管理 WEB 站点具有非常重要的意义。首先，虚拟目录隐藏了有关站点目录结构的重要信息。因为在浏览器中，客户通过选择“查看源代码”，很容易就能获取页面的文件路径信息，如果在 WEB 页中使用物理路径，将暴露有关站点目录的重要信息，这容易导致系统受到攻击。其次，只要两台机器具有相同的虚拟目录，你就可以在不对页面代码做任何改动的情况下，将 WEB 页面从一台机器上移到另一台机器。还有就是，当你将 WEB 页面放置于虚拟目录下后，你可以对目录设置不同的属性，如：Read、Excute、Script。读访问表示将目录内容从 IIS 传递到浏览器。而执行访问则可以使在该目录内执行可执行的文件。当你需要使用 ASP 时，就必须将你存放 .asp 文件的目录设置为“Excute（执行）”。作者建议大家在设置 WEB 站点时，将 HTML 文件同 ASP 文件分开放置在不同的目录下，然后将 HTML 子目录设置为“读”，将 ASP 子目录设置为“执行”，这不仅方便了对 WEB 的管理，而且最重要的提高了 ASP 程序的安全性，防止了程序内容被客户所访问。因为在今年 7 月底的时候 IIS 被一些网络高手发现了一个可怕的 bug，那就是，当你在一个站点的 .asp 文件后加上 ::$DATA 后，客户将能在浏览器中看到该 .asp 文件的所有源代码，这对于一个站点来说是非常可怕的。当然微软已经针对这个 bug，编写了补丁，但是为了彻底杜绝这种可能性的发生，作者还一建议大家不要将 .asp 所在的目录设置为可读。
在IIS中添加虚拟目录
虚拟目录就是站点物理路径下的一个文件夹，同一站点可以创建多个虚拟目录，分别存放不同内容的文件。
方法/步骤
-
打开“Internet信息服务（IIS）管理器”，在左侧窗口单击展开目标站点。
-
鼠标右击要添加虚拟目录的站点，在弹出的菜单中选择“添加虚拟目录”选项。
-
在弹出对话框的“别名”文本框中输入虚拟目录名称，然后单击“物理路径”右侧的按钮。
-
在弹出的浏览文件夹对话框中选择虚拟目录的目标文件夹，然后单击“确定”按钮。
-
返回添加虚拟目录对话框，可以看到虚拟目录的物理路径，如果要设置虚拟目录的连接账户，则单击“连接为”按钮。
-
如果要指定特定的连接用户，则选择“特定用户”单选钮，然后单击“设置”按钮，在弹出的对话框中输入用户名和密码；否则保持默认设置，通过应用程序用户连接。
-
返回添加虚拟目录对话框，单击“测试设置”按钮可以测试连接是否通畅，如果不通畅一般是由于文件访问权限导致，可以在虚拟目录指向的文件夹的访问权限中添加连接用户，最后单击“确定”按钮，创建虚拟目录。
-
IIS内虚拟站点配置信息说明
|
Table 3-1.可用于web.config的顶层配置元素
| 元素Element |
含义Purpose |
|---|---|
| |
指定所使用的客户身份验证模式Specify the client authentication mode to use |
| |
允许或者拒绝用户或角色的访问Allow or deny users or roles access |
| |
根据用户代理指定浏览器的能力Specify browser capabilities based on user agent |
| |
定义客户目标Define client targets |
| |
控制同页编译和程序集引用Control page compilation and assembly references |
| |
控制错误页显示和定义自定义的错误页Control error page display and define custom error pages |
| |
设置请求和响应的编码Set the request and response encoding |
| |
添加或移除HTTP处理程序Add or remove HTTP handlers |
| |
添加或移除HTTP模块Add or remove HTTP modules |
| |
控制HTTP请求的处理Control aspects of HTTP request processing |
| |
为该应用程序指定标识Specify impersonation for this application |
| |
控制验证和解密的钥匙Control the validation and decryption key |
| |
设置全局的网页默认属性Set defaults for page attributes globally |
| |
控制工作者进程的行为方式Control the behavior of the worker process |
| |
使用相关的策略文件定义信任等级Define trust levels with associated policy files |
| |
控制会话状态Control session state |
| |
启用应用程序范围的跟踪Enable application-wide tracing |
| |
选择使用的信任等级Select which trust level to use |
| |
指定Web服务的协议和范围Specify Web service protocols and extensions |
| |
添加应用程序专用的数据元素Add application-specific data elements |
1, 配置的四个层次
(1)机器:machine.config:位于$FRAMEWORK\CONFIG($FRAMEWORK一般是c:\winnt\Microsoft.NET\Framework\v1.0.3705)，
是.net必须备的默认配置文件。
web.config用来修改.net默认配置。
(2)站点:web站点根目录下的web.config，影响全站配置
(3)程序:应用程序虚目录根下的web.config，影响全虚目录配置
(3)子目录:虚目录的子目录下的web.config，影响该子目录及其子目录下配置
Figure 3-1. Hierarchy of Configuration Files
[图片]
2，通过location元素简化web.config配置:
Listing 3-2 Using the location Element
3，元素的配置规定:
authentication, sessionState, trust, 和 httpModules(即使在老版本.net允许在子目录中配置，也是不生效的)元素属于应用程序级别的元素，不能配置于子目录下的 web.config。processModel属于机器级别元素，只能用于machine.config。
4，元素的更改生效时间:
一般web.config更改后，会自动重新加载程序，并放弃原进程的会话状态和程序状态。如果是processModel更改，只有终止工作者进程(可手工IIS复位，可撤销aspnet_wp.exe进程，也可因进程意外反弹自身)然后重新启动，才能应用新配置，同时放弃所有运行于该机器上的.net 程序状态，缓存数据和会话状态。
5,IIS与web.config配置
如果使用了IIS，则IIS的安全配置等优秀于.net配置。如此可以只使用IIS默认配置，而在web.config中具体配置。
二，常量配置appSettings
使用appSettings元素的add子元素的key和value属性(键值不分大小写)来存储常量设置。
Listing 3-3 Specifying Application-Specific Configuration Data
/>
程序启动后，配置就载入内存，有访问权限(.net使用HttpForbiddenHandler来控制对.config.cs, .vb, .asax, .resx文件的访问权限，默认下外部程序不可访问配置文件)的程序就可以使用ConfigurationSettings.AppSettings ["DSN"]的方式直接引用配置的值。
Listing 3-4 Retrieving appSettings Configuration Data
<%@ Page Language='C#' %>
<%@ Import Namespace='System.Configuration' %>
三，进程配置processModel
只能在machine.config中使用processModel，其改动只在aspnet_wp.exe进程重启后生效，并由unmanaged (非托管?)的aspnet_isapi.dll(ISAPI扩展dll)读取，而非象其他配置一样由managed mechanism(托管机制?)读取。
Table 3-2. Attributes of the processModel Element
| Attribute |
Values |
Default |
Description |
|---|---|---|---|
| Enable |
true | false |
true |
指定ASP.NET是驻留在外部工作者进程中(true)，还是直接在inetinfo.exe中(false) |
| timeout |
Infinite | HH:MM:SS |
Infinite |
进程的总生命期——超时后进程反弹Total life of a process—process bounced after timeout |
| idleTimeout |
Infinite | HH:MM:SS |
Infinite |
进程的总空闲期——当到达超时时间时进程反弹Total idle life of a process—process bounced when reached |
| shutdownTimeout |
Infinite | HH:MM:SS |
0:00:05 |
在撤消进程之前，给予进程关闭的时间Time given to process to shut down before being killed |
| requestLimit |
Infinite | number |
Infinite |
进程反弹之前，要服务的总需求量Total number of requests to serve before bouncing process |
| requestQueueLimit |
Infinite | number |
5000 |
进程反弹之前．所允许的在队列中等待的请求数量 |
| restartQueueLimit |
Infinite | number |
10 | 进程重启时．在队列中等待的请求量Number of requests kept in queue while process is restarting |
| memoryLimit |
Number |
60 | 进程反弹之前．允许进程使用的物理内存百分数Percentage of physical memory process is allowed to use before bouncing process |
| webGarden |
true | false |
false |
指定进程是否与特定CPU建立密切关系(对于多CPU机器)Whether process should be affinitized with a particular CPU (for multi-CPU machines) |
| cpuMask |
Bitmask |
0xffffffff |
控制ASP.NET工作者进程所用的CPU数 |
| userName |
SYSTEM | MACHINE | username |
MACHINE |
运行工作者进程所需的Windows身份 |
| Password |
AutoGenerate | password |
AutoGenerate |
username的密码Password for username |
| logLevel |
All | None | Errors |
Errors |
登记在事件日志中的事件类型Event types logged to event log |
| clientConnectedCheck |
HH:MM:SS |
0:00:05 |
执行客户连接的检查前．请求保留在队列中的时间Time a request is left in the queue before a client-connected check is performed |
| comAuthenticationLevel |
Default | None | Connect | Call | Pkt | PktIntegrity | PktPrivacy |
Connect |
DCOM的安全性身份验证的级别Level of authentication for DCOM security |
| comImpersonationLevel |
Default | Anonymous | Identify | Impersonate | Delegate |
Impersonate |
COM的安全性身份验证的级别Authentication level for COM security |
| responseRestartDeadlockInterval |
Infinite | HH:MM:SS |
00:09:00 |
由于responseRestart-DeadlockInterval而重启工作者进程所需的等待时间Time to wait between restarting worker process because of responseRestartDeadlockInterval |
| responseDeadlockInterval |
Infinite | HH:MM:SS |
00:03:00 |
在队列中有等待的请求时，为监测死锁而设定的响应超时For deadlock detection, timeout for responses when there are queued requests |
| maxWorkerThreads |
Number |
25 | 线程池中每个CPU的最多工作者线程量 |
| maxIoThreads |
Number |
25 | 线程池中每个CPU的最多I./O线程量Maximum number of I/O threads per CPU in the thread pool |
| serverErrorMessageFile |
File name |
"" | “Server Unavailable"消息的自定义Customization for "Server Unavailable" message |
虽然如上有众多条件能使进程反弹，但默认下只有两个反弹条件：一是程序占用了60%以上的物理内存(该条件由memoryLimit属性来指定)，二是有5000多个请求在队列中等待。常用的反弹条件还有明确的超时时间 (timeout),空闲超时时间(累计空闲时间idleTimeout),工作者进程的服务数量上限(requestLimit)。
可以通过设置webGarden和 cpuMask来设置多cpu的使用方式
Listing 3-5 Specifying Multiple Worker Processes on a Multi-CPU machine
idleTimeout="Infinite"
shutdownTimeout="0:00:05"
requestLimit="Infinite"
requestQueueLimit="5000"
restartQueueLimit="10"
memoryLimit="60"
webGarden="true"//启用该配置后，每个cpu运行一个工作者进程，进程间不能共享会话状态，数据缓存，程序状态
cpuMask="0x00000007"//相当于二进制0...0111屏蔽，则只使用cpu0,cpu1,cpu2，屏蔽其他cpu
userName="machine"
password="AutoGenerate"
logLevel="Errors"
clientConnectedCheck="0:00:05"
comAuthenticationLevel="Connect"
comImpersonationLevel="Impersonate"
responseRestartDeadlockInterval="00:09:00"
responseDeadlockInterval="00:03:00"
maxWorkerThreads="25"
maxIoThreads="25" />
还可以设置maxIoThreads和maxWorkerThreads来控制CPU。(前者一定是I/O(如流或管道)实现端口，后者则是传统非限制流程。由于目前IIS采用异步写已命名管道的方法来处理请求(IIS6直接集成了asp.net，所以不必通过已命名管道而是在工作者线程中直接处理请求)，所以.net主要也在I/O中处理请求。)默认的线程设置是25/CPU，一般已经够用。当需要设置超过25直到100线程时,需要谨慎检查是否有异常。
1, 读取进程信息
使用ProcessModelInfo(两个获得当前或刚终止工作者进程休息的方法，都调用ProcessInfo类)和ProcessInfo(保存工作者进程的信息)两个静态类来读取进程信息
Listing 3-6 ProcessModelInfo and ProcessInfo Classes
public class ProcessModelInfo
{
public static ProcessInfo GetCurrentProcessInfo();
public static ProcessInfo[] GetHistory(int num);
}
public class ProcessInfo
{
public TimeSpan Age {get;}//年龄
public int PeakMemoryUsed {get;}//已使用最大内存数
public int ProcessID {get;}//进程ID
public int RequestCount {get;}//已服务的请求数
public ProcessShutdownReason ShutdownReason {get;}//关闭原因
public DateTime StartTime {get;}//开始时间
public ProcessStatus Status {get;}//状态
}
Figure 3-3. Sample ProcessModelInfo Output
[图片]
2 , IIS6.0进程模型的改变(相对IIS5的隔离方式)
在IIS6.0中，ProcessModel在IIS元数据库中被对等设置代替，现在以XML形式放在metabase.xml文件中，所以忽略了 machine.config中的ProcessModel元素。而且进程不再是ASPNET_wp.exe，而是一个或多个w3wp.exe中，因为已经不限制一个cpu只能一个工作者进程。我们可以配置应用程序池(包含共享相同工作者进程的虚目录集)，通过比ProcessModel更多更灵活的设置来控制进程(循环次数/天，分离虚拟内存极限，实际内存极限，cpu使用监视，cpu过载的回收，应用程序池禁用的错误数量极限，启动和关闭时间限制)。
另外，使用http.sys的内核模式来侦听处理Http请求，而不再是inetinfo.exe。这样就不在进程中而是在系统服务内核中处理Http要求，于是即使用户模式进程出现缺陷甚至崩溃，都不会影响服务内核。
四，附属设置
1，assemblies元素
在web.config中使用@Assembly，可以全局引用GAC部署的应用程序。
Listing 3-7 Adding an Application-wide Reference to a GAC-Deployed Assembly
2，pages元素
在web.config中使用@page指令，可以统一改变应用程序的page默认设置。
Listing 3-8 Using the pages Element
五，读取配置信息
除了通过ConfigurationSettings.AppSettings["xxx"]来访问保存在AppSettings中的值外，通常用 ConfigurationSettings.GetConfig()方法，请求从缓存中读取，如未缓存就请求直接从配置文件读入内存， ConfigurationRecord类使用XmlTextReader类可以直接读取最低层配置的物理xml文件。
Listing 3-9 Reading Configuration Settings
object settings =
ConfigurationSettings.GetConfig("appSettings");
NameValueCollection nvc = settings as NameValueCollection;
if (nvc != null)
{
string val = (string)nvc["xxx"];
}
除了web.config这样的配置的元数据，还有配置的处理程序(解析配置使其获得高扩展性，并在正式读取配置时建立类，同时传送对象的实例建立，开始传送相关配置)。如下图：machine.config中，compilation元素由 CompilationConfigurationHandler类来解析，该类于configSections元素下指定，同时也属于 sectionGroup元素(进一步确定分析范围是 system.web)。另外一个元素appSettings由NameValueFileSectionHandler负责解析，该元素位于配置文件的顶层。
Figure 3-4. Configuration Section Handlers in machine.config
[图片]
每个configSections中的元素都必须实现IConfigurationSectionHandler接口，该接口有一个简单的方法 Create。当配置处理程序的标签被读入时，ConfigurationRecord类(顶层配置文件解析器)调用Create方法。同时，处理程序获得上层配置信息(如果有上层配置的话)和当前HttpConfigurationContext对象(通过输入参数)，以及对 XmlNode的引用(最重要信息，由配置处理程序负责解析)。通常处理程序(函数)会遍历XmlNode的每个子节点和属性，返回一个对象，包含所有状态信息。在缓存上述状态信息后，应用程序就可通过ConfigurationSettings.GetConfig()全局引用该状态信息。
Listing 3-10 IConfigurationSectionHandler Interface
public interface IConfigurationSectionHandler
{
object Create(object parent, object input, XmlNode node);
}
asp.net配置部份的处理程序各自都会在内存中建立一个state retainer(状态保持器)，如CompilerConfiguration类(compilation元素信息)， PagesConfiguration类(pages元素信息 )等。这些配置实例类(都是内部类，不可直接访问，asp.net用它们来设置其创建类中的默认值和其它值)都保存在一个全局的哈希表中，可以用 ConfigurationSettings.GetConfig()来访问该哈希表。
Figure 3-5. In-memory Configuration Settings Layout
[图片]
六，创建自定义的配置处理程序
除了保存在appSettings元素中之外，还可以自定义配置元素。如下:
Listing 3-11 Sample Custom Configuration Element
Courier New
首先，我们要建立用于保存配置状态信息的保存机制。
一种较简单的方法是定义一个类(如AcmeSettings类)，用其中的公有数据成员来保存对应的配置元素。
Listing 3-12 Sample Custom Configuration Settings State Class
// File: AcmeSettings.cs
namespace EssentialAspDotNet.Config
{
public class AcmeSettings
{
public string Font;
public string BackgroundColor;
public bool UnderlineLinks;
public int HorizontalWidth;
public int VerticalWidth;
}
}
然后，我们要建立一个实现IConfigurationSectionHandler接口的类，用于解析配置文件中自定义部份，并将其状态信息保存到acmeSettings类中。
Listing 3-13 Sample Custom Configuration Section Handler
// File: AcmeConfigHandler.cs
namespace EssentialAspDotNet.Config
{
public class AcmeConfigHandler :
IConfigurationSectionHandler
{
public object Create(object parent, object input,
XmlNode node)
{
AcmeSettings aset = new AcmeSettings();
foreach (XmlNode n in node.ChildNodes)
{
switch (n.Name)
{
case ("font"):
aset.Font = n.InnerText;
break;
case ("backgroundColor"):
aset.BackgroundColor = n.InnerText;
break;
case ("underlineLinks"):
aset.UnderlineLinks = bool.Parse(n.InnerText);
break;
case ("horizontalWidth"):
aset.HorizontalWidth = int.Parse(n.InnerText);
break;
case ("verticalWidth"):
aset.VerticalWidth = int.Parse(n.InnerText);
break;
}
}
return aset;
}
}
}
最后要通知，我们要用该类解析配置文件中的acme元素。为此，我们在配置文件的configSections中添加一个section元素，用于读取并解析配置文件。(系统范围的machine.config文件，站点范围和应用程序范围的web.config文件都能添加Section元素)
Listing 3-14 Installing a Custom Configuration Section Handler
/>
现在，应用程序中的所有网页或者代码块，都能使用ConfigurationSettings.GetConfig()方法访问该配置信息，传递我们创建的部份组(section group)和部份名称(section name)，并将结果转变为我们创建的AcmeSettings类。如下:
Listing 3-15 Accessing Custom Configuration Information
// File: TestAcmeSettings.aspx
protected void Page_Load(object src, EventArgs e)
{
AcmeSettings set;
set = ConfigurationSettings.GetConfig("acmeGroup/acme")
as AcmeSettings;
// use set here (like set.Font, set.BackgroundColor,
// etc.)
}
还有一种方法，使用NameValueFileSectionHandler，就不需要自即编写实现 IConfigurationSectionHandler接口的类了，而是重用与appSettings元素一样的类。当然也不能用add元素(带有键 /值对)添加新的配置元素，但也能容易地添加新的配置部份。
Listing 3-16 Adding a Custom Configuration Section with a Prebuilt Handler
PublicKeyToken=b77a5c561934e089"/>//添加了名为myGroup的新的配置的部份
///其type属性引用了NameValueFileSectionHandler类，该类的实例将其键/值对保存在NameValueCollection中供访问。
Listing 3-17 Accessing Custom Configuration Information with NameValueCollection
// File: TestAcmeSettings.aspx
protected void Page_Load(object src, EventArgs e)
{
NameValueCollection set;
set = ConfigurationSettings.GetConfig("myGroup")
as NameValueCollection;
// use set here (like set["Font"],
// set["BackgroundColor"], etc.)
}
七，小结：
ASP.NET使用web.config名字的XML文件取代IIS的元数据库进行配置，machine.config是最顶层的机器配置，而web.config可以放在站点根目录，虚目录根部，子目录等不同层次位置，相应地对其下层发生效用。
另外还可用新的配置元素，appSettings用于保存数据的通用的名/值对，以供应用程序调用。processModel可以精确控制工作者进程。另外还可通过写一个实现IConfigurationSectionHandler接口的类或者使用系统提供的 NameValueFileSectionHandler类，实现自定义配置。
参考资料：https://www.cnblogs.com/zhangxiaolei521/p/5600607.html