性能优化指南
在确定哪种容量情况满足需要之后，下一个任务就是加以优化以获得最佳性能。对于企业级 ISA，这意味着设计充足的硬件资源，使系统依赖其 CPU 能力作为可能的瓶颈源。对于单台入门级 ISA Server 计算机，可能的瓶颈源是 Internet 带宽，而不是您选择的处理器。
优化硬件以实现最高的 CPU 使用率
ISA Server 容量依赖 CPU、内存、网络和磁盘硬件资源。每种资源都具有容量限制，只要所有资源的使用都不超过其上限，系统在整体上就能正常运行，从而满足其性能目标。当到达其中某个限制时，性能就会显著下降，从而导致瓶颈。在这种情况下，我们就说系统受到该资源的约束。每个瓶颈在整体系统性能中都具有其症状，可帮助检测没有足够容量的资源。在发现瓶颈之后，可通过向没有足够容量的资源增添容量来消除瓶颈。
从成本的角度看，设计一个受 CPU 资源约束的系统是最高效的。这是因为它是升级成本最昂贵的资源。其他资源短缺不需要多大的成本即可解决：添加另一个磁盘，添加另一个网络适配器，或者增加内存。推荐优化系统的硬件来最大化 CPU 使用率。确保系统在达到全部 CPU 使用率之前不存在性能瓶颈。如果 CPU 能力能够维持预期的负荷，则瓶颈永远不会出现。为此，其他所有资源必须具有足够的容量。以下几个小节描述如何设计每种资源都具有足够容量的、CPU 容量最大化的系统，如何监视每种资源，以及如何对每种资源中的瓶颈进行故障排除。
确定 CPU 和 系统体系结构容量
与服务于众多客户端请求的大多数服务器应用程序一样，ISA Server 性能也得益于更高的 CPU 速度、更大的处理器高速缓存和改进的系统体系结构：
- CPU 速度。与在大多数应用程序中一样，ISA Server 也得益于更快的 CPU。然而，提高 CPU 速度不会保证性能的直线提升。受大量和频繁的内存访问的影响，提高 CPU 速度可能导致在等待 CPU 周期时浪费更多的空闲内存 ；
- L2/L3 高速缓存大小。处理大量的数据需要频繁的内存访问。L2/L3 高速缓存提高了大量内存读取的性能 ；
- 系统体系结构。由于 ISA Server 在网络设备、内存和 CPU 之间传输大量的数据负荷，CPU 周围的系统组件也会影响 ISA Server 的性能。更快的内存前端总线 (FSB) 和更快的 I/O 总线可以提高整体容量。
CPU 瓶颈的特征如下：
/Processor/% Processor Time
性能计数器数值很高，而网络适配器和磁盘 I/O 保持很低的容量。在这样的情况下（这是理想的 CPU 容量最大化的系统），达到 100% 意味着必须提高 CPU 能力，不管是升级为更快的 CPU 还是添加更多的处理器。有关 CPU 扩展选择的信息，请参阅“扩展 ISA Server”。如果 ISA Server 仍然具有很长的响应时间，但是具有很低的 CPU 使用百分比，则瓶颈应在其他地方。
确定内存容量
ISA Server 内存用于：
- 存储网络套接字（主要来自未分页的池）
- 内部数据结构
- 未决的请求对象
在 Web 代理缓存情景中，内存还用于：
由于 ISA Server 要处理众多需要系统未分页内存的并发连接，内存限制因素就是未分页池的大小，而这是由总的内存大小决定的。对于 Microsoft Windows Server 2003 和 Windows 2000 Server，未分页池大小的最低值和最高值如下表所示。
|
最小未分页池大小 |
4 |
8 |
16 |
32 |
64 |
128 |
|
最大未分页池大小 |
50 |
100 |
200 |
256 |
256 |
256 |
在没有启用 Web 缓存时，512 MB 对单处理器计算机来说应该足够了，而 1,024 MB 对于双处理器计算机来说也应该足够了。这些内存空间也可以存储完整的内存工作集容量。
内存没有得到正确优化的最关键证据是 /Memory/Pages/sec （衡量每秒的硬页面错误）在峰值负荷期间很大（大于 10）。如果发生这种情况，第一步行动取决于是否启用了 Web 缓存：
如果禁用了 Web 缓存，必须监视系统中所有进程所使用的内存来确定是否需要更多的物理内存。以下性能计数器将会帮助您：
/Memory/Pages/sec
/Memory/Pool Nonpaged Bytes
/Memory/Pool Paged Bytes
/Process(*)/Working Set
如果启用了 Web 缓存，应首先尝试把内存缓存大小降低到物理内存的 10%。如果仍然发生硬页面错误，则继续执行第一步。
确定网络容量
某个连接上存在的每个网络设备都具有容量限制。这包括客户端和服务器网络适配器、路由器、交换机，以及将它们相互连接起来的集线器。足够的网络容量意味着这其中任何一个网络设备都不会饱和。监视网络活动对于确保所有网络设备上的实际负荷低于它们的最高容量是必不可少的。
在两种一般情况下，网络容量会影响 ISA Server 性能：
- ISA Server 使用 WAN 链路连接到 Internet。在大多数情况下，Internet 连接带宽设定了流量的上限。过渡使用 Internet 链路可能在峰值流量期间导致性能降低。
- ISA Server 仅连接到 LAN。在这种情况下，有一个支持最高流量需求的基础结构是很重要的。然而在大多数情况下，由于 100Mbps 和 1Gbps LAN 价格低廉，这并不是一个问题。
为了监视网络活动，可使用性能计数器：
/Network Interface(*)/Bytes Total/sec
如果其值高于任何网络接口的最大带宽的 75%，应考虑增加不足大的网络基础结构的带宽。
确定磁盘存储容量
ISA Server 将磁盘存储用于：
如果两者都被禁用，或者如果没有流量，ISA Server 不会执行任何磁盘 I/O 活动。在典型的 ISA Server 设置中，日志记录是启用的，并被配置为使用 Microsoft Data Engine (MSDE) 日志记录。对于大多数部署，单个磁盘就足以满足最高的日志记录速度。如果启用了 Web 缓存，必须按照“Web 缓存”中的说明来仔细规划磁盘存储容量。
任何磁盘存储系统的限制因素都是每秒的物理磁盘访问量。该数量随这些访问的随机性和物理磁盘的转速而异。通常，该限制介于每秒 100 到 200 次访问之间。用于监视磁盘访问速度的性能计数器为：
/PhysicalDisk(*)/Disk Transfers/sec
如果某个磁盘在一段持续的时间内达到该限制，可以预测系统速度会变慢，这可以通过系统响应时间的延长来注意到这一点。为了消除该瓶颈，直接的解决方案是通过添加更多的物理磁盘来降低磁盘访问量。
磁盘访问率很高的另一个原因是硬页面错误。有关该情况的故障排除信息，请参阅“Web 缓存”。
应用程序和 Web 筛选器
ISA Server 使用应用程序筛选器来执行应用程序级安全检查。应用程序筛选器是注册到特定协议端口的动态链接库 (DLL)。每当把一个数据包发送到该协议端口，它就被传递给应用程序筛选器，后者按照应用程序逻辑来检查该数据包，并根据策略来决定该怎样处理。当没有为某协议指定应用程序筛选器时，数据将进行 TCP 状态筛选。在此级别上，ISA Server 仅检查 TCP/IP 报头信息。
一般情况下，由于以下几个原因，应用程序级筛选要比 TCP 状态筛选需要更多的处理操作：
- 应用程序筛选器检查数据的有效载荷，而 TCP 状态筛选仅检查 TCP/IP 报头信息。应用程序筛选器可以对数据的有效载荷执行其他操作（比如：查看和阻止），或者根据应用程序逻辑更改内容。
- 应用程序筛选器在用户模式空间中运行。传输级筛选在内核模式下进行。这意味着经过整个操作系统网络堆栈传递数据的额外处理开销。
由于应用程序筛选器是防火墙处理扩展程序，它们可能具有性能影响。我们建议：
- 获得所使用的筛选器的性能信息，尽可能对它们进行优化，以实现最高的效率。一个例子是 HTTP Web 筛选器，它可以被配置来检查 HTTP 有效载荷并搜索特定的签名。启用这个特性可以提供额外的处理，从而降低对 ISA Server 计算机的额外需求。
- 在适当的场合，可考虑使用 ISA Server 规则而不是使用筛选器。例如，使用访问规则目标集的站点阻止可能要比执行相同功能的 Web 筛选器更高效。
- 如果开发了一个筛选器，应对其进行优化以实现最佳的性能。这是适用于任何软件的建议，特别是任务关键型防火墙或代理服务器。
- ISA Server 允许对相同的应用程序端口使用应用程序筛选或更低级的 TCP 状态筛选，具体取决于源和目标网络。例如，您可以在应用程序级筛选 Internet 流量，而对其他所有网络之间传递的流量使用传输筛选保护。
日志记录
ISA Server 提供了两种主要的方法来对防火墙活动进行日志记录：
- MSDE 日志记录。该方法是用于防火墙和 Web 活动的默认日志记录方法。ISA Server 将日志记录直接写入 MSDE 数据库，以允许对所记录的数据进行联机高级查询。
- 文件日志记录。使用该方法，ISA Server 按顺序将日志记录写入一个文本文件。
这两种方法比较而言，MSDE 具有更多的特性，但是它使用更多的系统资源。明确地说，在从 MSDE 切换到文件日志记录以后，可以预测处理器使用率总体上会提高 10% 到 20%。
MSDE 日志记录还会消耗更多的磁盘存储资源。对于每 Mb 的数据，MSDE 日志记录大约要访问磁盘两次。文件日志记录要 10 Mb 的数据才需要访问磁盘两次。提高 ISA Server 性能的一种办法是从 MSDE 切换到文件日志记录。仅当存在由饱和的处理器和磁盘访问导致的性能问题时，才推荐使用此办法。
方案
ISA Server 支持广泛的部署和应用方案。下面几个小节描述主要的方案及其性能特征。
部署方案
部署方案指的是 ISA Server 计算机在公司 Intranet 中的位置。出于安全和性能方面的考虑，这些年发展了几种流行的方案，下面几小节将从性能和容量的角度描述每种方案。
Internet 边缘防火墙
具有企业级容量需求的组织可以考虑部署一台 ISA Server 计算机作为专用的边缘防火墙，充当所有公司客户端到 Internet 的安全网关。为了维持内部网络和 Internet 连接之间数百 Mbps 水平的高吞吐率，可以配置 ISA Server 来仅提供数据包级别和状态传输层筛选。
ISA Server 提供的更高级的应用程序级筛选将在第二层防护上启用，第二层防护由后端防火墙 ISA Server 计算机组成。
部门或后端防火墙
企业级组织的下一条防线包括几台作为部门或后端网络防火墙来部署的 ISA Server 计算机，它们对进出受保护的 LAN 的访问提供安全的入站和出站访问控制。具有现有防火墙基础结构的组织可以将当前的高性能防火墙保留在 Internet 边缘，并将复杂的应用程序层筛选卸载到 LAN 边缘的 ISA Server 防火墙。这样允许组织在利用当前的高速 Internet 连接的同时，从 ISA Server 2004 应用程序层筛选功能所提供的独特保护级别中获得好处。
从性能的角度看，部门 ISA Server 防火墙只需维持通过边缘防火墙的总流量的一部分，从而允许运行更消耗资源的安全特性（比如：应用程序筛选器）。
分支机构防火墙
ISA Server 可用于使用站点对站点的 VPN 连接来将分支机构网络安全地连接到总部。在这种部署中，ISA Server 被放置在分支机构中，充当保护分支机构网络的防火墙，又充当把分支机构网络连接到总部网络的 VPN 网关。
一般情况下，相对于应用程序级筛选的 Internet 访问的每个流量单元需要的处理能力，传输级筛选的站点对站点的 VPN 的每个流量单元仅消耗 25% 的处理能力。
注意：在传输级筛选的站点对站点的 VPN 中，应用程序级筛选器不会检查出经过隧道的流量。像其他任何流量一样，站点对站点的 VPN 流量的应用程序级筛选是针对每个协议启用的。
Web 代理方案
Internet 上和当今的公司网络内的大多数流量都是 HTTP。许多协议的流量模式分析表明，HTTP 就网络性能而言是很苛刻的。因此，典型的 Web 流量工作负荷模拟对于衡量任何防火墙的容量和性能特征是切合实际的。
注意：验证网络性能的典型度量指标是每个 TCP 连接交换的事务量。与其他协议相比，HTTP 的典型值（平均为 3 至 5）是很低的。
下表根据 Internet 链路带宽总结了在三种典型单台计算机部署上支持 HTTP 流量的硬件推荐配置。
|
处理器 |
1 |
1 |
2 |
|
处理器类型 |
Pentium III
550 MHz （或更高） |
Pentium 4
2.0–3.0 GHz |
Xeon
2.0–3.0 GHz |
|
内存 |
256 MB |
512 MB |
1 GB |
|
磁盘空间 |
150 MB |
2.5 GB |
5 GB |
|
网络接口 |
10/100 Mbps |
10/100 Mbps |
100/1000 Mbps |
上表中的这些要求针对的是默认的 ISA Server 2004 安装设置，一个策略配置包含数百个规则。这包括所有默认的应用程序和 Web 筛选以及 MSDE 日志记录。下面这些内容适用于上表：
- Internet 链路带宽。带宽数据适用于苛刻的工作负荷，其中 ISA Server 2004 被用作具有完整 HTTP 应用程序层筛选的透明 Web 代理。ISA Server 充当正向或反向 Web 代理，可以使吞吐率加倍，这意味着用于 T3 带宽的最低推荐计算机是单 Pentium 4 处理器计算机，而用于两个 T3 连接的是双处理器计算机。有关各种 Web 代理方案之间的性能差别的详细信息，请参阅“代理方案”。
- 在仅需要状态筛选（不需要更高的应用程序级筛选）的部署中，推荐的硬件将达到 LAN 线速。有关详细信息，请参阅“状态筛选”。
- 在启用 Web 缓存的情况下，根据字节命中率可将 Internet 链路带宽降低 20% 到 30%。有关详细信息，请参阅“Web 缓存”。
- 处理器。 数据是通过模拟数千个 IP 地址上的 HTTP 流量得来的，这些流量使 ISA Server 处理器的负载达到了 70% 到 80% 的使用率。
- 处理器类型。 模拟 IA-32 指令集的具有相近性能的其他处理器也考虑到了。
- 内存。 内存要求没有考虑用于 Web 缓存的内存空间。有关用于 Web 缓存的附加内存的信息，请参阅“Web 缓存”。
- 磁盘空间。 磁盘空间要求指出了推荐用于 ISA Server 日志的空闲磁盘空间量。有关规划 Web 缓存的磁盘空间要求的信息，请参阅“Web 缓存”。
- 网络接口。 网络接口要求针对的是内部网络（没有连接到 Internet 的网络）。
ISA Server 使用内置的 Web 代理应用程序筛选器来保护 HTTP 流量。该应用程序筛选器支持三种不同的方案：用于保护公司用户对 Internet 的出站访问的正向代理和透明代理，以及用于保护 Internet 用户对内部 Web 站点的入站访问的反向代理。接下来的几个小节从性能的角度描述每种方案，并解释如何使用缓存来提高性能。
代理方案
本小节提供正向代理、透明代理和反向代理的方案。
正向代理
在正向代理中，客户端 Web 浏览器知道代理的存在。例如在 Internet Explorer 中，这是通过在 Internet 选项中设置代理服务器或自动检测设置来实现的。当 Web 客户端知道代理时，它们直接打开到代理的连接，并向代理发送针对 Internet 上的位置的请求。（例如，Internet Explorer 在发送 HTTP 1.1 请求时，将会打开两个到代理的连接。）当 ISA Server 接收到针对某服务器的请求时，它会打开一个到该服务器的连接，并将该连接再次用于从其他客户端向相同服务器发出的其他请求。这样就形成了一个星形连接拓扑。
这种方案的性能优势在于，它允许高度重用连接，从而最小化打开的连接的数量以及连接速率。
透明代理
在透明代理中，客户端 Web 浏览器不知道代理的存在。它们以为所发送的信⑹侵苯勇酚傻?Internet 上的服务器的，中间没有代理。明确地说，Web 客户端通过打开与目标 Web 站点的连接来直接访问 Internet 服务器。这样导致了连接速率显著提升，因为在用户请求某个新的服务器上的页面之后，Web 浏览器将关闭它与当前 Web 服务器的连接，然后打开与新的 Web 服务器的新的连接。这是透明代理的典型特征，并对 ISA Server 性能产生影响。通常，透明代理中的客户端连接速率大约要比正向代理中的客户端连接速率高三倍，从而每请求所消耗的处理器周期大约是后者的两倍。
透明代理是很流行的方案，因为它很容易部署，对于拥有异类客户群的 Internet 服务提供商（ISP）尤其如此。由于这个原因，此方案能够显著提高性能。
一般情况下，与正向代理相比，用于透明代理的 ISA Server 需要两倍的 CPU 资源量。
反向代理
反向代理或 Web 发布的工作方式与正向代理相同，只不过方向是入站而不是出站。在该方案中，ISA Server 充当由 Internet 上的客户端访问的 Web 站点。客户端不知道它们正在访问的 Web 站点其实是一个代理。与正向代理一样，由于高效的连接重用，连接数量和连接速率都保持在最低水平。反向代理用于 Web 服务器的安全发布，比如：Internet 信息服务 (IIS)、Outlook Web Access、SharePoint Portal Server 等等。
从性能的角度看，反向代理具有类似正向代理的特征。主要区别在于，从 ISA Server 流向 Internet 用户的大多数流量需要大量的 Internet 连接。正如下一小节将要解释的那样，当启用了 Web 缓存时，正向代理和反向代理具有不同的性能影响。
Web 缓存
Web 缓存是在所有 Web 代理方案中用于改善 ISA Server 性能的特性。但是在对出站方案（正向和透明代理）和入站反向代理方案启用缓存时，对性能改善的影响有所不同。
正向（透明）和反向缓存之间的主要区别在于缓存的用途。正向（和透明）缓存旨在通过把频繁访问的可缓存内容放在靠近用户的地方，从而节省带宽成本和缩短响应时间。反向缓存用于卸载后端 Web 服务器的负荷。反向缓存不会缩短响应时间，反而会增加没有缓存的对象的延迟。
就节省而言，正向缓存节省对 Internet 上的 Web 服务器的访问尝试，即从缓存中满足那些访问尝试，从而节省所需的 Internet 链路带宽。例如，如果缓存字节命中率为 20%，内部链路上的峰值吞吐率为 10 Mbps，Internet 链路上的峰值吞吐率将仅为 8 Mbps。
注意：缓存对象命中率是在代理所提供的全部对象中，从缓存中提供的那一部分对象所占的比率。同样，缓存字节命中率是在代理提供的全部字节中，从缓存中提供的那一部分字节所占的比率。普遍的平均值约为 35% 的对象命中率和 20% 的字节命中率。
反向缓存有助于 Web 服务器的合并，从而同时降低硬件和管理成本。例如，如果 80% 的 Web 站点数据是静态和可缓存的，动态对象需要的 CPU 周期是静态对象的四倍，那么利用反向代理将把 Web 服务器的数量减少 100%。
注意：假设静态对象需要 X 个 CPU 周期，则动态对象需要 4X 个周期。如果 100 个请求中有 80 个是静态的，100 个请求所需要的周期总数为 80X + (100-80)4X = 160X，用于静态内容的请求的 50% 将由 ISA Server 缓存来满足。
正向缓存和反向缓存之间的另一个区别是缓存的工作集的数量。在反向缓存中，客户端空间是无限的，但是服务器空间仅包含几个 Web 站点和相对较少的对象。在大多数情况下，ISA Server 可设计为具有合理的内存和磁盘空间来在缓存中存储所有驻留的可缓存内容，以便仅把动态的不可缓存内容指向驻留的 Web 服务器。更为可取的是，所有缓存都可以保留在内存中，并从内存中提供。
在正向缓存中，服务器空间包含无限个 Web 站点和 Web 对象，因此缓存工作集是无限的。为了容纳这样大的工作集，必须定义很大的磁盘缓存。接下来的几个小节将描述如何规划和优化用于正向和反向缓存的 Web 缓存容量。
优化正向缓存内存和磁盘
在正向缓存中，对象命中率和峰值 HTTP 请求速率用于按照如下公式确定必需的磁盘数量：
例如，如果峰值请求速率为每秒 900 个请求，对象命中率为 35%，则需要四个磁盘。
注意：上述公式中的 100 是个经验值，表示平均的执行物理磁盘（最高每分钟 10,000 转）每秒可提供 100 次 I/O 操作。每分钟 15,000 转的更快的磁盘每秒能够执行 130-140 次 I/O 操作。
推荐使用相同类型和相等容量的专用磁盘。如果使用 RAID 存储子系统，应该将它配置为 RAID-0（无容错）。推荐使用小磁盘，最好不超过 40 GB。
调整缓存内存更加复杂。在缓存方案中，内存用于：
- 未决的请求对象。未决的请求对象与 ISA Server 计算机的客户端连接数量成比例。在大多数情况下，它小于客户端连接数量的 50%。每个未决的请求大约需要 15 KB。对于 10,000 个并发连接，Web 代理内存工作集分配给未决请求对象的空间不超过
50% × 10,000 × 15 KB = ~ 75 MB。
- 缓存目录。缓存目录包含每个缓存对象的一个 32 字节的条目。缓存目录的大小是直接通过缓存的大小和平均响应大小来确定的。例如，包含 7,000,000 个对象（平均每个对象约 ~7 KB）的 50 GB 缓存需要 32 × 7,000,000 = 214 MB。
- 内存缓存。内存缓存的目的是直接从内存满足针对频繁访问的缓存对象的请求，从而减少磁盘缓存读取。但是由于可缓存的内容在正向缓存中是无限的，内存缓存大小对性能的影响有限。
默认情况下，内存缓存是物理总内存的 10%，并且是可配置的。一般情况下，我们推荐使用默认设置，除非出现硬页面错误。硬页面错误可能导致严重的性能下降。当使用了缓存时，解决这种情况的最简单的办法是降低内存缓存的大小。
考虑到该信息，可使用以下过程来调整缓存内存大小：
按前一小节所解释的那样调整磁盘缓存大小。
估计以下各项合计所需要的内存：
未决的请求对象（10% × 15 KB * 估计的峰值连接数）。
缓存目录大小（32 * 缓存中的 URL 数）。
内存缓存大小（默认为总内存的 50%）。
每个连接将需要大约 2 KB 的系统内存，并需要额外的 50 MB 作为起始内存（50 MB + 2 KB * 估计的峰值连接数）。
运行在系统中的其他进程至少需要 100 MB。
监视内存使用并相应地更改内存缓存大小。信息性性能计数器包括：
/ISA Server Cache/Memory Cache Allocated Space (KB)
/ISA Server Cache/Memory URL Retrieve Rate (URL/sec)
/ISA Server Cache/Memory Usage Ratio Percent (%)
/ISA Server Cache/URLs in Cache
/Memory/Pages/sec
/Memory/Pool Nonpaged Bytes
/Memory/Pool Paged Bytes
/Process(WSPSRV)/Working Set
/TCP/Established Connections
优化反向缓存内存和磁盘
在反向缓存中，工作集大小与正向缓存相比要小得多，因此将其全部放在内存里是合乎逻辑的。工作集的大小是缓存所驻留的 Web 站点中的可缓存对象的总量。磁盘和内存缓存大小推荐约为包含所有可缓存对象的工作集大小的两倍，同时考虑到磁盘分配中的碎片和缓存刷新策略。例如，一个 500 MB 的工作集需要 1000 MB 的磁盘缓存和 1,500MB 的内存，并将内存缓存大小设置为 66%。
由于大多数缓存读取都从内存缓存中满足，磁盘上的 I/O 频率是很低的。在大多数情况下，单个物理磁盘就足够了，不会形成瓶颈。
使用 /3GB Boot.ini 开关
对于内存超过 2 GB 的大型系统，Windows Server 2003 和 Windows 2000 Advanced Server 提供了 3GB RAM 的优化特性。该特性将进程内存空间划分为 3 GB 的应用程序内存和 1 GB 的系统内存。该特性使进程能够从用户空间中超过 2 GB 的 RAM 中获益，并通过向 Boot.ini 文件添加开关 /3GB 来启用。（有关详细信息，请参阅 Microsoft 知识库中的文章 Q171793。）
该特性可能对 ISA Server 有好处，特别是对于承载大型网站的反向缓存。然而，使用该特性减小了未分页池（减小到 128 MB 而不是 256 MB）的最大大小，从而减少了最大的并发 TCP 连接数。
Web 身份验证
执行 Web 身份验证的方法有许多种，各对性能有不同的影响。下表总结了每种方法的优点和缺点。
|
基本 |
低 |
每请求 |
低 |
无 |
|
摘要 |
中 |
每次/计数 |
无 |
高 |
|
NTLM |
中 |
每连接 |
无 |
高 |
|
NTLMv2 |
高 |
每连接 |
无 |
高 |
|
Kerberos |
高 |
每连接 |
无 |
中 |
|
安全 ID |
高 |
每浏览器会话 |
无 |
中 |
|
RADIUS 每请求（默认） |
高 |
每请求 |
高 |
无 |
|
RADIUS 每会话 |
中 |
一次 |
无 |
低 |
从性能的角度看，没有每请求的开销并且每批处理的开销很低的验证方案表现最佳 ，决定使用哪种验证方案取决于强度和基础结构。
此外，Web 代理身份验证可在 Web 代理侦听器级或在规则级上进行配置。仅当所有 Web 访问都需要身份验证时才应选择侦听器级。否则就应选择规则级，这意味着根据规则，仅在必要时才执行身份验证。
Web 筛选器
像应用程序筛选器一样，Web 筛选器也可能具有性能影响，具体取决于它们所做的工作。ISA Server 整合了几种执行指定任务的 Web 筛选器。这其中最消耗 CPU 的是 HTTP 筛选器和链路转换筛选器。
HTTP 筛选器检查每个 Web 请求和响应，检查它们是否符合常规的 HTTP 协议用法。该筛选器默认是启用的，其默认配置提供了 HTTP 报头和 URL 的大小限制。其它可用的特性包括按方法、扩展名、报头和 HTTP 有效载荷签名执行阻止操作。当选中时，这些功能不会影响性能，不过签名阻止例外，它需要消耗 10% 以上的 CPU 周期。推荐使用 HTTP 筛选器来保护 Web 流量。
链路转换专门用于 Web 发布方案。它检查 HTML 响应正文，搜索绝对超链接，并将它们改为指向 ISA Server 计算机。默认情况下，链接转换仅扫描 HTTP 报头，而不扫描响应正文，因此不应该会有显著的性能影响。此外，当启用了正文扫描时，它默认仅扫描 HTML 内容，从而导致 CPU 使用率总体上增加 5%。
状态筛选
状态筛选在传输级检查数据，并且是在 ISA Server Firewall Packet Engine 内核模式的驱动程序中实现的。状态筛选计算源和目标 IP 地址、TCP/UDP 标记端口号和选项以及 Internet 控制消息协议 (ICMP) 类型和代码。它使用该信息来确定连接的状态，从而允许符合该状态的数据包，拒绝不符合该状态的数据包。
与应用程序级筛选所需要的资源相比，状态筛选只需少量的资源。在使用 Web 代理筛选时使用 75% CPU 能力的相同 HTTP 流量，在使用状态筛选时仅使用 8% 的 CPU 能力（性能提高了 10 倍）。
VPN
虚拟专用网络 (VPN) 包含两种基本的方案：远程访问 VPN 和站点对站点的 VPN。两种方案都可以使用多种协议，并且可与应用程序筛选或状态筛选协同工作。基于 Internet 协议安全 (IPSec) 的协议还可以利用许多网络适配器中可用的硬件卸载功能，从而提高整体处理器利用率。有些协议还可以利用压缩来提高吞吐率或节省带宽。正如接下来的几个小节所要解释的，所有这些特性均影响性能。
远程访问 VPN
从 Internet 拨入的远程访问客户使用 VPN 远程访问来访问他们的公司网络。远程访问中使用的协议是点对点隧道协议 (PPTP) 和 Internet 协议安全 (IPSec) 上的第 2 层隧道协议 (L2TP)。这两种协议都支持压缩，推荐使用压缩，因为它节省带宽和加密所需的处理能力。
为了确定 ISA Server VPN 服务器的足够容量，首先需要计算出 ISA Server 计算机需要支持的并发远程连接的最大数量。例如，如果预计组织内的员工中建立并发远程连接的人数不超过 5%，并且组织有 5,000 名员工，那么 250 个并发 VPN 远程访问连接就是枰娜萘俊?/FONT>
下表给出了每种硬件平台支持的并发 VPN 远程访问连接的最大数目。这些数据假设即拆即用的 ISA Server 设置整合了 Web 代理筛选、MSDE 日志记录以及同时用于 PPTP 和 L2TP/IPSec 协议的压缩。
|
PPTP |
连接 |
150 |
600 |
760 |
|
PPTP |
带宽 |
2.25 Mbps |
9 Mbps |
11.4 Mbps |
|
L2TP/IPSec |
连接 |
150 |
700 |
850 |
|
L2TP/IPSec |
带宽 |
2.25 Mbps |
10.5 Mbps |
12.75 Mbps |
以下内容适用于上表：
| • |
带宽。带宽数据是所需的 Internet 链路带宽。由于压缩，实际的带宽是上表所示的数据的两倍。
带宽数据假设每个连接的平均吞吐率为 30 Kbps，大致相当于一个 56 KB 的拨号连接。 |
在能够从更高程度上信任 VPN 客户端的部署中，可以禁用应用程序级筛选，从而因为放松安全级别而提高总容量。下表给出了禁用 Web 代理筛选器时的相同数据。
|
PPTP |
连接 |
375 |
1,000 |
|
PPTP |
带宽 |
5.6 Mbps |
15 Mbps |
|
L2TP/IPSec |
连接 |
330 |
1,000 |
|
L2TP/IPSec |
带宽 |
5 Mbps |
15 Mbps |
以下内容适用于上表：
| • |
连接。单 Pentium 4 3 GHz 处理器能够达到上表中所示的最大并发连接数。 |
站点对站点的 VPN
在站点对站点的 VPN 中，从性能和容量角度看，存在两个主要的选择。一种选择是使用 PPTP 或 IPSec 上 的 L2TP。这些协议提供应用程序流量压缩，从而使得可通过站点对站点的链路传输的吞吐量加倍。例如，通过 PPTP 或 L2TP 隧道发送 2MB 的文件实际上仅传递 1 MB。另一种选择是使用 IPSec 隧道，它没有整合压缩。因此与 IPSec 隧道相比，PPTP 和 IPSec 上的 L2TP 实际上节省了 50% 的站点对站点的吞吐量。
在禁用 Web 代理筛选时，对于 15 Mbps 的应用程序流量，IPSec 上的 L2TP 需要单颗 Pentium III 550-MHz 处理器。由于压缩，单方向传递该流量仅需要 7.5 Mbps 的链路容量。单颗 Pentium 4 3GHz 处理器最多能够处理需要 T3 链路容量（45 Mbps）的 90 Mbps 的应用程序流量。当启用了 Web 代理筛选时，一颗 Pentium III 550-MHz 处理器能够维持需要 3.5Mbps Internet 链路带宽的 7 Mbps 应用程序流量，而单颗 Pentium 4 3-GHz 处理器能够处理对应于 17 Mbps Internet 链路带宽的 34 Mbps 的应用程序流量。双 Xeon 3-GHz 处理器能够处理需要 26.5 Mbps 的 Internet 链路带宽的 53 Mbps 的应用程序流量。在相同的 CPU 使用情况下，PPTP 能够多处理大约 15% 到 20% 的吞吐量。
第二种选择是使用 IPSec 隧道，它不支持压缩，意味着 Internet 链路流量与应用程序流量相同。当与状态筛选（启用 Web 代理筛选器）配合工作时，IPSec 隧道能够在单颗 Pentium III 550MHz 处理器上处理 10 Mbps，在单颗 Pentium 4 3GHz 处理器上处理 52 Mbps。当启用 Web 代理筛选时，针对单 Pentium III、单 Pentium 4 和双 Xeon 平台的吞吐量数据分别是 4 Mbps、18 Mbps 和 30 Mbps。
横向扩展 ISA Server
可通过多种方式横向扩展 ISA Server 系统：
- 使用高级网络交换硬件设备。这些交换机通常称为 L3、L4 或 L7 交换机（第 3 层、第 4 层或第 7 层），因为它们基于不同网络层的各种可用信息来提供交换功能。L3 交换基于数据包层的信息（IP），L4 基于传输层信息（TCP），而 L7 基于应用程序数据（HTTP 报头）执行交换。这些层可用的信息能够根据 IP 源或目标地址、TCP 源或目标端口、URL 以及内容类型提供高级的负载平衡。由于交换机是作为硬件设备来实现的，它们具有相对较高的吞吐量，并且高度可用和可靠，但也较为昂贵。大多数交换机都能够检测服务器停机条件，从而允许容错。
- 使用 DNS 循环名称解析。一个服务器群集可在 DNS 中被赋予相同的名称。DNS 通过循环该列表来响应名称查询。这是廉价（无成本）的解决方案，但是具有缺点。一个问题在于，负载不必要地在群集中的服务器之间均匀分布。另一个问题在于，它没有提供容错。
由于 ISA Server 维护着所通过的每个流的状态，所有横向扩展方法都必须支持“粘性 (stickiness)”，以便所有数据都通过 ISA Server 计算机。
扩展用于增加系统的容量。每种扩展方法都具有其优点和缺点，对于 ISA Server 来说，它还取决于具体的方案。在决定要使用哪种扩展方法时，可考虑以下因素：
- 性能因素。 可通过添加另一台计算机来获得的吞吐量。
- 系统成本。 购买系统的初始成本，不是拥有成本。
- 系统管理。 在管理系统方面的复杂程度。这直接影响系统的拥有成本。
- 容错。 系统用于支持高可用性和可靠性的方法。
- 系统增长。 用于增加系统的处理能力的方法。升级成本也是一个重要的考虑。
下面是在决定进行横向扩展时所要权衡的事项：
- 单点故障与容错。 单计算机部署的可用性要比多计算机群集更容易发生硬件故障。系统主板或磁盘控制器故障将导致整个系统崩溃，从而需要修复。这也适用于具有故障的硬件负载平衡器。
- 增长。只要计算机上存在空闲的处理器插槽（或硬件负载平衡交换设备中存在可用的端口），将单计算机解决方案从一个处理器升级到两个处理器是很简单的。在多计算机群集中，添加另外的计算机就更复杂了。
下表总结了各种横向扩展方法。
|
扩展因素 |
2 |
2 |
|
系统成本 |
昂贵 |
无附加成本 |
|
容错 |
取决于交换设备
（大多数都是检测故障计算机并加载其它计算机） |
无 |
参考资料
《2006 年企业、中小企业和远程工作者的带宽需要展望》，Gartner 报告 R-18-3617，2002 年 9 月 30 日
网友评论：（只显示最新10条。评论内容只代表网友观点，与本站立场无关！）