使用 Microsoft Windows DNA 平台构建 Web 站点的蓝图
草图，.9 版
Microsoft Corporation
2000 年 1 月
用自解压缩的可执行文件下载本文档的 Microsoft Word 版本。(177K)
摘要： 关于用 Microsoft Windows DNA 技术构建复杂的 Web 站点的培训技术资料，对象为工程师和决策者。
目录
执行摘要
体系结构概述
示例站点
可伸缩性
可用性
安全性
管理与运作
摘要
执行摘要
商务正迅速发展为标准的、基于 Web 的计算模型，其特征为重复且针对任务的系统的松散连接层。很大比例的商务 Web 站点 — 提供联机服务的服务器、应用程序和数据的集合 — 都是用当今的 Microsoft Windows DNA 平台构建的，成为该计算模型的基础。本文档定义了构建 Windows DNA 站点的体系结构。读者可以借用这些信息，设计和构建当今基于 Windows DNA 的站点。
本文档集中讨论如何使用 Microsoft 技术，特别是 Windows DNA 平台，以尽可能有效利用财力和时间的方法，构建可伸缩、可用、安全和可管理的站点的基础结构。强调保持 Web 站点简便灵活的运作和应用程序设计，以及“.com”如何能够成功地以必要而有效的可伸缩性、可用性、安全性和可管理性来部署和运作站点。其次强调当前文档齐全的工具和构建 Web 应用程序组件的方法。另外还从宏观层次检查 Microsoft Windows DNA 解决方案（使用 Microsoft(R) Windows NT(R) 4.0 和/或 Windows 2000）的优点，并逐级进入，以定义如何使用 Microsoft 产品建立站点体系结构中的每一层次。最后，将讨论使用 Microsoft 工具和技术管理 Web 站点。
尽管只是个概述，本文档还是检查了一个成功使用部署的体系结构的示例 Web 站点，它可作为使用 Windows DNA 平台构建的站点的模型。本文档不涉及（除了与可伸缩性、可用性、安全性和可管理性相关时）诸如应用程序设计、开发工具或数据库设计等主题；但是提供涵盖这些领域的相应文档的指针。
“体系结构概述”介绍一些对于大型 Web 站点很重要的体系结构概念。在“示例站点”描述了一个具有代表性的站点并解释了它使用的基础结构和各层。其余章节讨论了站点的四个关键属性 — “可伸缩性”、“可用性”、“安全性”和“可管理性” — 并使用示例站点来说明这些问题。对相关文档的引用贯穿整个文档。
体系结构概述
简介
大型商务站点为动态变化的模型：它们通常一开始很小，但随着需求的增长而指数增长。不仅在支持的独特用户的数量上不断增加，这种增长非常迅速，而且在提供的用户服务的复杂性和集成性方面也不断增长。经投资者的检查，许多站点启动的商务计划的可伸缩性为 10-100 倍，这个数据是可信的。成功的商务站点，通过不断增加向客户机提供逻辑服务的服务器数量（即通过服务器提供其自身的多个实例（克隆）或通过在自身之间均衡工作负荷），以及创建与已有计算机系统相集成的服务来管理这种增长和变化。这种增长的基础为支持高度可用性的坚实的体系结构、安全基础结构和管理基础结构。
体系结构目标
本文档描述的体系结构力图达到四个目标：
- 线性可伸缩性 — 可持续增长以满足用户需求和业务复杂性。
- 持续的服务可用性 — 使用冗余和功能专业化来提高容错能力。
- 数据和基础结构的安全性 — 保护数据和基础结构免受恶意攻击或盗用。
- 管理的简便性和完整性 — 确保运作能够满足增长的需求。
可伸缩性
为了可以扩展，商务 Web 站点将其体系结构分为两部分：前端（客户机可访问的）系统和存储长期永久数据的或商务处理系统所在的后端系统。负荷平衡系统用于将工作分配到每一层的系统中。前端系统通常不保留长期状态。也就是说，前端系统中每次请求的环境通常是暂时的。这种体系结构，通过克隆或复制与无状态负荷平衡系统（使负荷在可用的克隆体之间分配）相耦合的前端系统，扩展其支持的独特用户的数量。我们将克隆体集合中的 IIS 服务器集合称为 Web 群集。在多个后端系统之间分区联机内容同样可以扩展。带状态的或内容敏感的负荷平衡系统则将请求路由到正确的后端系统。通过功能专业化，业务逻辑复杂性以可管理的方式增长。专用的服务器负责专门的服务，包括与遗留或脱机系统的集成。克隆与分区，和功能专业化服务一起，通过单独增长每个服务而使得这些系统具有极大的可伸缩性。
可用性
通过使用多个克隆服务器（所有服务器均为其客户机提供唯一的地址）使得前端系统具有高度可用性和可伸缩性。负荷平衡用于在克隆体之间分配负荷。将故障检测功能置入负荷平衡系统提高了服务的可用性。不再提供服务的克隆体将自动从负荷平衡集合中删除，而剩下的克隆体将继续提供服务。使后端系统具有高度可用性更具挑战性，主要是因为它们维护着数据或状态。它们通过对每个分区使用故障转移群集 (failover clustering) 来实现高度可用。故障转移群集假定应用程序能够在可以访问故障系统的磁盘子系统的其他计算机上继续运行。分割故障转移发生在支持分区请求的主节点故障时，此时分区请求自动切换到二级节点。二级节点必须有权访问与故障节点同样的数据存储，该数据存储也应该是复制的。复制品还可通过在远程位置上成为可用，来提高站点的可用性。可用性在很大程度上还取决于企业级 IT 规则，包括更改控制、严格测试和快速升级以及反馈机制。
安全性
安全性 — 通过为信息的机密性、保密性、完整性和可用性提供充分的保护来管理风险 — 是任何商务站点成功的基本要素。商务站点使用多个安全域，其中包括具有不同安全性需求的系统，每个域均受到网络过滤器或防火墙保护。有三种主要的域，互相用防火墙隔离，它们是：公共网络；DMZ（由军事术语“非军事区域”派生而来），是前端和内容服务器所在之处；以及安全网络，是创建或使用内容的地方，也是管理和存储安全数据的地方。
管理
管理和运作广泛涉及维护商务站点及其服务正常工作所需的基础结构、工具以及管理员和技术人员。许多站点均位于常称作宿主环境的地方。也就是说，这些系统配置有“Internet 服务提供商 (ISP)”或专家宿主服务，这里可提供丰富的 Internet 连通性。因此，系统的管理和监控必须远程完成。在这种体系结构中，我们将描述这种管理网络和网络必须支持的管理功能类型。
体系结构元素
本节要突出的商务 Web 站点的关键体系结构元素包括：客户机系统；负荷平衡的、克隆的前端系统（客户机系统可用访问的）；负荷平衡的、分区的后端系统（前端系统可用访问这里的永久存储）；以及三种拱形体系结构考虑：灾难承受能力、安全域及管理和运作。
大型商务 Web 站点的原理
图 1 展示了商务 Web 站点的概念和基本原理，这些内容将在本节的以下部分详细说明。
图 1. 体系结构的原理
图 1 显示了前端、后端和负荷平衡层的划分，正如本文档所述。防火墙和网段分区为安全原理的关键。
客户机
在这种站点体系结构中，客户机向某服务名称发送请求，该服务名称代表提供给客户机的应用程序。最终用户和客户机软件不知道提供服务的系统的内部运作方式。通常，最终用户键入第一个 URL，例如，http://www.thebiz.com/，然后单击超级链接或完成 Web 页上的表单以便向站点深处导航。
对于范围广泛的 Web 站点，一个重要的决定就是是否在浏览器中支持功能的最低公共集，或是否为不同的浏览器版本提供不同的内容。目前，尽管还有更旧的浏览器在使用，但 HTML 3.2 通常为所支持的最低版本。例如，浏览器可如此分类：支持 HTML 3.2 的，如 Microsoft Internet Explorer 3.0；支持动态 HTML (DHTML) 的，如 Internet Explorer 4.0；以及支持 Extensible Markup Language (XML) 的，如 Internet Explorer 5.0。然后为每个类提供不同的内容。IIS 和工具，能够创建可动态呈现给不同浏览器的页面。
前端系统
前端系统由向 Web 客户机提供核心 Web 服务（如 HTTP/HTTPS、LDAP 和 FTP）的服务器组成。开发人员通常将这些前端系统分为一系列称作克隆体的相同系统的集。它们运行相同的软件，并通过内容复制或高度可用的文件共享访问相同的 Web 内容、HTML 文件、ASP、脚本等。通过克隆体之间的负荷平衡请求，以及通过检测故障克隆体并将其从工作的克隆体中删除，可实现高度可伸缩性和可用性。
克隆体（无状态前端）
克隆是为 Web 站点增加处理能力、网络带宽和存储带宽的良好手段。由于每个克隆体在本地复制存储，因此，所有更新必须应用到所有克隆体上。但是，由于与负荷平衡、故障检测和消除客户机状态的耦合，克隆的确是扩展站点和提高可用性的良好方法。
无状态负荷平衡
负荷平衡层向用户提供一个服务名称并将客户机负荷分配给多个 Web 服务器。这将为服务器集提供可用性、可伸缩性和某种程度的可管理性。负荷平衡手段有多种，包括“Round Robin 域名服务器 (RRDNS)”及各种基于网络的和基于主机的负荷平衡技术。
维护客户机状态
我们不希望在克隆前端系统中维护客户机状态，因为这与透明客户机故障转移和负荷平衡相抵触。在会话间维护客户机状态的基本方法有两种。一种是将客户机状态存储在分区的后端服务器中。（由于客户机状态可以完全分区，因此也易于扩展。但是，需要对每个客户机请求检索该状态）。在会话间维护客户机状态的另一种方法是使用 cookie 和/或 URL。Cookie 是由客户机 Web 浏览器管理的小文件。它们无益于减小带状态服务器的负荷和增加无状态前端系统的实用性。数据还可以存储在 URL 中，并在用户单击显示的 Web 页上的链接时返回。
前端可用性
当在这些前端服务器上运行应用程序代码时，无论是用 Microsoft Visual Basic(R) 或 C++ 等高级语言还是用脚本编写，从不同的 Web 应用程序隔离编程错误是非常重要的。使应用程序代码在 Web 服务器的进程外运行，是相互隔离编程错误和避免 Web 服务器故障的最佳方法。
后端系统
后端系统是维护应用程序数据的数据存储，也是启用与其他维护数据资源的系统的连通性的数据存储。数据可以存储在普通文件、数据库系统（如 Microsoft SQL Server(TM)）或其他应用程序中，如下表所示。
表 1. 数据存储的不同类型
| 文件系统 | 数据库 | 其他 应用程序 |
|
|---|---|---|---|
| 示例 | 文件共享 | SQL | Ad insertion、SAP、Siebel |
| 数据 | HTML、图像、可执行文件、脚本、COM 对象 | 类别、用户信息、日志、帐单信息、价格表 | 库存目录/库存、标语广告、帐目信息 |
使后端系统扩展和具有高度可用性更具挑战性，主要因为它们必须维护数据和状态。一旦单一系统的可伸缩性已经达到，就必须分区数据并使用多台服务器。因此，持续的可伸缩性是通过数据分区和将逻辑数据映射到正确的物理分区的数据相关路由层或带状态负荷平衡系统来实现的。
对于提高的可用性，群集 — 通常由两个访问公共的、复制的或 RAID （独立盘的冗余数组）保护的存储器的节点组成 — 将支持每个分区。当一个节点上的服务失败时，另一个节点将接管分区并提供服务。
分区（带状态的后端系统）
通过复制硬件和软件及在各节点之间划分数据，分区增强了服务能力。通常，数据是按对象分区的，如邮箱、用户帐户或生产线等。在某些应用程序中分区是按时间进行的，例如按天或按季度。也可能用随机分区的方法分布对象。拆分和合并分区需要工具，最好是联机的（不用中断服务），符合系统变化的需要。增加宿主分区的服务器数量，提高了服务的可伸缩性。不过，分区的选择将决定访问模式及其产生的负荷。甚至在分布请求时也要避免出现热点（一个分区接收的请求数量不成比例），这对设计数据分区也很重要。有时这很难避免，而且必须有大型多处理器系统宿主分区。分区故障转移，即服务自动切换到二级节点（退回未完成的事务），可提供持续的分区可用性。
带状态负荷平衡
如果数据按多个数据服务器分区，或开发提供专用功能的服务器来处理特定类型的 Web 请求，必须编写相应的软件将请求路由到相应的数据分区或专用服务器。通常，该应用程序逻辑是由 Web 服务器运行的。其编制目的是确定相关数据的位置，并且根据客户机请求的内容、客户机 ID 或客户机提供的 cookie 将请求路由到数据分区所在的相应服务器。它还知道提供专用功能的服务器位置并将请求发送到那里进行处理。该应用程序软件完成带状态负荷平衡。称其为带状态的原因是，根据客户机状态或请求中的状态才能决定将请求路由至何方。
后端服务的可用性
除了使用故障转移和群集提高可用性外，整个系统体系结构的一个重要因素，就是站点提供某些有限程度服务的能力，甚至在多种服务失效的情况下。例如，用户应该总能通过用户凭据的复制登录至联机邮件服务，然后使用克隆的“简单邮件传输协议 (SMTP)”路由器发送邮件，即使用户的邮件文件是无效的。相类似，在商务站点中用户应该可以浏览目录，即使暂时不能处理事务。这要求系统体系结构设计者要设计出“当个别部件发生故障时工作可靠但性能下降”的服务，以避免由于局部故障而使终端用户感觉为整个站点故障。
灾难承受能力
某些商务 Web 站点需要持续的服务可用性，即使在灾难发生时：他们的全球商务活动依赖于可用的服务。灾难可能是自然灾害（地震、火灾或洪水），也可能是恶意操作（如恐怖活动或心怀不满的员工）的结果。灾难承受系统要求将站点的副本或部分副本放在离主站点足够远的地方，这样，在整个灾难中失去多个站点的概率会小到可承受的程度。在最高级别有两种复制的站点类型。主动站点分担部分负荷。被动站点在发生灾难后才提供服务。在需要快速故障转移的场合通常使用主动站点。被动站点可能只是由租用服务器和远程的、位于备份磁带所在地的连接组成，这些连接可在需要时应用于上述服务器。像这种最小限度的规划应该为任何商务考虑之列。
更新复制的站点，使它们的内容保持一致是很具挑战性的。此处的基本方法是：将内容从中央升级服务器复制到远程站点的升级服务器，更新每个站点的内容。对于只读内容该方法已足够。但是，对于更多的执行事务的高级站点，还需要保持数据库为最新。数据库复制和日志转移通常用于将对数据库的事务性更新转移到远程站点的地方。典型情况下，数据库将出现几分钟不同步。但是，这比站点完全失效要好。
安全域
安全性机制用于保护敏感信息的保密性和机密性，使其免受未经许可的访问；通过防止未经许可的修改或破坏，保护系统和数据的完整性；并通过防止拒绝服务攻击和提供意外或灾难计划，来帮助确保可用性。
安全域是一致的安全性区域，区域之间有定义明确的保护接口。这一概念的应用程序有助于确保在正确的场合应用正确的保护级别。复杂系统（如大型商务站点及其环境）可划分为多个安全域。区域表示任何所希望的划分 — 例如，按地域、按组织、按物理网络或者服务器或按数据类型。对于商务站点，主要的划分方式可适当按照 Internet、站点的 DMZ、安全性、企业和管理网络。域还可能相互交叉或重叠。例如数据库中的信用卡号码可能需要附加保护。附加的安全性控制，如卡号的加密，可提供这种保护。
下面的比喻有助于形象说明安全域。Internet 好象中世纪的城堡及其周边环境：在其城墙之外，很少有法律约束并有各种不拘一格的个性。根据这个城堡模型，用于保护 Web 站点的关键结构元素是在其周围构筑城墙，有重兵把守的主城门禁止闲杂的人进入。需要构建的城墙及城门等效于维护给定安全级的标准。当然，不会有没有保护的后门！对于大型商务站点，城墙称为站点的边界。在网络术语中，表示站点的内部通信设备是专用的并与 Internet 隔离，指定的入口除外。站点的主城门称作防火墙。防火墙将检测每一通信包，确保只允许希望的信息进入。继续这个比喻，城堡中的要塞保护着皇冠宝石。附加的围墙和加锁的门或墙中墙，提供了附加保护。与此类似，商务站点通过提供附加的防火墙和内部网络，保护着非常敏感的数据。
图 2. 防火墙/DMZ
防火墙是一种控制网络中处于不同可信级别的两部分之间的数据流的机制。防火墙的范围可以从数据包过滤器（只允许指定 IP 端口和/或一系列 IP 地址之间的数据通信）到应用程序级防火墙（实际检查数据的内容并决定是否让其通过）。站点通常将过滤数据包的外向防火墙和过滤协议和端口层数据的内向防火墙结合使用。
保护站点的安全性很复杂，但防火墙/DMZ 是关键结构组件（实际上是网段中的子网）。对于保证期望的站点保护级别，它是必要但绝不充分的安全性机制。本文档的“安全性”章节专门叙述如何保护站点的安全。
管理基础结构
站点管理系统通常构建在单独的网络上，以确保高度可用。管理系统使用单独网络，还可以减轻管理通信量的后端网络的负荷，从而提高整体性能和响应时间。管理和运作有时也使用后端网络，但对于大型的、高可用度的站点，不建议这样做。
管理系统的核心结构组件为管理控制台、管理服务器和管理代理。所有核心组件均可独立扩展。管理控制台是管理员访问和操纵被管理系统的入口。管理服务器时刻监控着所管理的系统、接收报警和通知、记录事件和性能数据，并作为响应预定事件的第一防线。管理代理为在其驻留的设备内部执行主要管理功能的程序。管理代理与管理服务器使用标准的或专用的协议相互通信。
当系统达到一定的规模和变化率时，Web 站点的管理和运作成为关键因素。管理的简便性、易于配置、持续的健康监控和故障检测可能比添加应用程序功能或新服务更为重要。因此，应用程序工程师必须十分熟悉部署和运行应用程序的操作环境。另外，操作人员还必须十分熟悉克隆和分区方案、管理工具和安全机制，以维持持续可用的、基于 Internet 的服务。
示例站点
简介
本示例站点力求通用，以说明核心结构组件和基础结构。但是，它是我们曾讨论过的许多运行站点的关键结构特性的代表。出于竞争和安全原因，站点所有者通常不愿展示其站点的实际详细内幕。
我们的示例以一个大型站点为例，并展示了拓扑结构和组件冗余。它是一个高度可用系统：紧急服务可拯救大部分故障模式，减轻重大灾难。从 ISP 1 到 ISP N 的每个分组中的服务器均支持所有站点紧急处理功能，因此，即使失去一个 ISP 也不会使站点瘫痪。在大部分灾难情况下，提供不间断的服务需要在多个地理位置 (geoplex) 上复制整个站点。Cisco 的“分布式控制器”通常用于支持 geoplex。遗憾的是，站点复制的成本将超出构建站点的两倍，并且可能导致 Web 应用程序的数据一致性问题。
从该示例可派生出较小的和大得多的站点。较小站点可能不需要在每个群集中有如此多的服务器。不需要很高可用性的站点只要删除冗余的元素，特别是图中从 Internet ISP 1 开始的整个上半部分。没有很高数据库安全性的站点可以在安全网络中删除安全 SQL 群集。另一方面，非常大的站点可以添加下列内容充分地扩展：
- 每个 IIS Web 群集的克隆体。
- Web 群集数量。
- Internet 连接访问点。
- 前端组件，如防火墙。
更进一步，随着网络通信量和要管理的设备数量的增加，管理网络也必须增加规模和复杂性。
图 3. 大型 Web 站点网络拓扑结构示例
在图 3 中，不同的线形、粗细和注释显示了网络不同部分的 IP 地址和连接。特别是：
- 外部（面向 Internet）网络（细）。
- DMZ 网络（中）。
- 安全（内部）网络（粗）。
- 管理网络（细虚线）。
- 群集核心专用网络（细 — 每个群集本地专用）。
- 与企业网的连接（闪电状）。
本节的其他内容将提供示例站点的教程，从 Internet 开始经 DMZ 直到安全网络，包括企业网和管理网络。
Internet
教程从连接一个或多个“Internet 服务提供商 (ISP)”开始。我们的示例列举了多个标记为 ISP 1 - ISP N 的冗余连接。这些连接应该来自不同（物理上独立）的网络。域名服务器（DNS，图 3 中没有展示）提供了域名与一个或多个 TCP/IP 地址之间的正向和反向映射。例如，http://www.microsoft.com/ 当前映射下列地址，每组地址均为一个群集。
| 207.46.130.14 207.46.131.28 |
| 207.46.130.149 207.46.131.30 |
| 207.46.130.150 207.46.131.137 |
如果有多个 IP 地址，DNS 将浏览地址列表来处理对 www.microsoft.com IP 地址的不断查询 — 因此，得名为“Round Robin DNS (RRDNS)”。RRDNS 的缺点是不能检测出 ISP 连接的消失而继续为不再工作的 IP 地址提供服务。但是这并不非常严重，因为用户只需请求重载 Web 页。第三方解决方案，如 Cisco 的 Local Director或 F5 Networks 的 BigIP 提供了动态路由连接的更好解决方案。
DMZ
前端网络上的服务器是面向 Internet 的。防火墙是基本的安全性组件，通过按数据包类型、源和目的地址过滤数据通信量，来提供网络隔离。它们形成了由双向箭头描述的 DMZ（非军事区）边界。
防火墙
路径中的第一个组件就是路由器/防火墙，它们的功能是截然不同的或组合在一个设备中。面向 Internet 的路由器支持“边界网关协议”(http://www.ietf.org/rfc/rfc1654.txt)。高速前端交换机支持到前端 Web 群集中的每台服务器的连接。与路由器/防火墙的交叉连接为在 ISP 连接失效时，或路径上任何组件失效时，提供了另一条路径。
前端网络
前端提供核心 Web 服务，如 HTTP/HTTPS，使用 Microsoft Internet Information Server (IIS) 提供 HTML 和 ASP 页面服务，使用 LDAP（Lightweight Directory Access Protocol）进行用户身份验证。还可以将“站点服务器商业版”装载到前端服务器上，以提供附加的数据库驱动的服务。
前端服务器按服务和功能分组 — 例如 http://www.microsoft.com/、http://search.microsoft.com/、SMTP（电子邮件）或 FTP（下载）。SSL 服务 (HTTPS) 同样是从普通 HTTP 通信中隔离出来的。这使得经过特殊配置的、带有高成本的硬件安全加速器模块的服务器，可支持高速加密功能。更进一步，SSL 会话继承了带状态性，并可能需要特殊的故障转移处理。
在示例站点中运行 Windows 2000 的每个 Web 群集均使用 NLBS（网络负荷平衡服务 — 在 Windows NT 中也称为 Windows 负荷平衡服务）。每个克隆体在每个发布相同内容的 NLBS Web 群集中有相同的配置。这将为无状态 Web 应用程序提供透明的故障转移，与单个服务器相比从根本上提高了服务能力。Web 群集通过添加克隆体分担群集的负荷来支持广阔的可伸缩性。
客户机向使用虚拟 IP 地址的每个 Web 群集提出请求，该虚拟 IP 地址是 NLBS 群集中的所有前端服务器均可以响应的。前端服务器则访问位于后端群集文件共享服务器和后端群集 SQL 服务器上的站点内容。
提供 Web 服务所需的所有 COM 对象，包括从 ASP 页调用的对象，均安装并注册在每个前端服务器上。该站点的 ASP 页可以装载在前端服务器的本地磁盘上，也可以保持在后端群集文件共享服务器上。
每个前端服务器均特殊加强了安全性并连接到三个网络：
- 前端网络 — Internet 访问。
- 后端网络 — 访问 DMZ 服务器，并通过内部防火墙访问安全网络。
- 管理网络 — 支持管理和运作功能。
这种网络隔离，在提高总体可用带宽和冗余的同时提高了安全性。
注意该站点中任何服务器上唯一可公共访问的 IP 地址为 NLBS 虚拟 IP 地址，只有前端服务器才可以响应的这个地址。用于面向 Internet 的 NIC（网络接口卡）的 IP 过滤，可确保只有被支持的功能的正确通信类型和源，才能进入前端服务器。这些网络之间的 IP 转发也已禁用。
后端网络
后端网络通过使用高速、私用的 10.10.1.x LAN 支持所有 DMZ 服务器。这种体系结构可防止从 Internet 直接访问 DMZ 服务器，即使防火墙被突破，因为不允许 Internet 路由器转发指定的 IP 地址范围（请参阅 http://www.ietf.org/rfc/rfc1918.txt 上的 Address Allocation for Private Internets（专用 Internet 的地址分配）），包括范围 10.x.x.x。当使用前端网络时，冗余交换机可提供对所有前端和后端服务器的访问。所有后端交换机共享公共网络，因此后端通信量负荷将成为主动站点的问题，特别是单独的管理网络不能进行记录并且其他前端管理网络还在通信。
后端网络的主要组件为加强了安全性的服务器群集，它们提供对 Web 内容和临时永久状态，如会话内事务性数据（例如购物推车内容），的存储服务。由于所有永久数据随处可得，因此没有必要提供备份工具。通过添加群集和分区数据库可实现可伸缩性。
这些服务器使用了 Windows 2000 上的“Microsoft 群集服务”，实现了带故障转移能力的高度可用性。一个服务器失效不会导致数据服务的失效甚至服务的中断。当失效的服务器恢复联机时，可以继续数据服务。由于硬盘的确会失效，因此使用 RAID 驱动器阵列可提供必要的数据冗余保护。
群集内的文件共享支持文件存储服务。群集上运行的 Microsoft SQL Server 提供数据库服务。每个群集服务器至少使用了四个 NIC：一个用于每个交换机、一个用于专用核心 LAN（应该使用其他专用网络地址，如 192.168.10.x）、一个用于管理 LAN。除服务器物理地址外，群集还具有多个虚拟 IP 地址，以支持群集本身和每个群集服务地址对（用于冗余）。
加强 DMZ 实用程序 DC 的服务器支持所有 DMZ 服务器的本地域帐户、本地 DHCP 和名称服务（WINS，或最好为 DNS）以及本地实用程序文件服务。对内部企业域的单向信任关系，提供了对安全的内部系统的身份验证式访问。
安全网络
另一道防火墙形成了 DMZ 的内部边界，并将所谓的安全网络与后端网络隔离开。防火墙配置成只允许端口与源/目的对之间所要求的通信。安全网络又由一个专用网络（本例中为 10.10.2.0）、一对耦合的交换机、各种服务器和标记为 VPN/路由器的设备组成，这个标记为 VPN/路由器的设备提供了与内部企业网的连接。安全网络在逻辑上为企业网的一部分。安全网络上的服务器通常也是内部企业域的成员，因此域控制器和地址及名称服务器也假定是内部的。
为了支持其他功能，在本节中可能还需要其他服务器。有多种可能的处理方法，然后在安全性数据存储与内部系统之间传输事务性数据。事务的范围是从传统的同步 (MTS — Microsoft Transaction Service) 到异步 (MSMQ - Microsoft Message Queue) 乃至基于批处理或基于电子邮件的存储和转寄。这些内容已超出本文档的范围。
但请注意，对于许多组织来说，Internet 是许多通道中唯一提供用户服务的传送通道，这很重要。以书店或银行为例。大部分业务逻辑和处理发生在内部的现有系统内。Internet 解决方案必须与这些现有系统协作并为其提供服务。
安全数据存储
安全 SQL 群集是可选的，并只为更复杂的事务性站点中所需。它们提供了高度可用性、身份验证数据库的永久存储、长期事务存储，并保证客户信息和帐户数据的机密性。与 DMZ 中的服务器群集不同，这些服务器必须备份，既可以使用直接连接的可移动存储设备，也可以通过企业网进行备份。其他功能与 DMZ 群集类似。为了冗余，每个服务器将重复连接到安全网络的两个交换机上。同样又是通过分区数据库和添加群集，来实现可伸缩性。
升级服务器
升级服务器出现在安全网络部分，尽管它们可能位于企业网或甚至位于 DMZ 中。它们接受和升级来自企业网或外部内容提供商的内容，然后将内容部署到 Web 服务器，以使站点保持一致状态。通常有很多机制可用，包括 Microsoft Content Replication（Microsoft 内容复制系统）和诸如 RoboCopy 等工具。
企业网连通性
示为 VPN/路由器的、将站点与企业网相连的设备实际上是个路由器，如果需要，它可以和 VPN 安全性功能结合，来签署和加密通信。另外，使用 Windows 2000 内置 IPSec 特性也可添加 VPN 功能。这将在根据需求的基础上支持端对端的安全性，这样可以节约 VPN 硬件支持的成本。
就企业数据中心中宿主的站点而言，连接企业网易如反掌。在这种情况下，VPN/路由器直接与企业网相连。
大型商务站点经常由远程的企业数据中心宿主。专用热线经常用来连接站点与企业网，特别是在需要高性能、低响应时间的情况。另外，Internet 本身也可能用于传输，这种情况下使用 VPN 技术确保所有通信的安全非常重要。
管理网络连通性
我们以管理网络的讨论来结束我们的教程，管理网络提供了监控和管理站点的基本功能。为简单起见，我们只演示用 LAN 连接单独管理网络的计算机。这些是用单独的 NIC 实现的。某些站点没有使用单独的管理网络。相反，它们瓦解后端网络上的管理通信。为安全性、网络负荷和管理起见，我们不建议这样做。
与路由器、交换机和防火墙的管理连接没有显示。用于紧急带外 (OOB) 访问的串口拨号连接也没有显示。这并不表示不需要它们。当管理网络（或用于管理的后端网络）不可用时，仍然可以通过这种设置访问每个主机。
摘要
下面章节使用前例的模型，详细讨论本文档所描述的体系结构如何满足这四个目标：
- 线性可伸缩性 — 可持续增长以满足用户需求和业务复杂性。
- 持续服务可用性 — 使用冗余和功能专业化来提高容错能力。
- 数据和基础结构的安全性 — 保护数据和基础结构免受恶意攻击或盗用。
- 管理的简便性和完整性 — 确保运作能够满足增长的需求。
可伸缩性
简介
图 4 例举了站点可伸缩性的两个不同维度。第一个维度，即水平轴，表示在有代表性的一天，访问站点的独特客户机的数量。随着独特客户数量的增加，配置用于支持增加的客户库的系统数量也将增加。典型情况下，支持客户库所需的站点上的内容也必须增加。
第二个维度，即垂直轴，表示站点的业务复杂性程度。我们已经标识了三个主要类别。当然，在它们之间还有许多变种。类别之间通常通过包含下级分类的功能而互为基础。最底层分类，和在业务逻辑复杂方面最简单的，是内容提供商类。上一层的分类，除来内容外还有事务处理，但许多业务处理是脱机完成的。而最上层的分类既有内容还有事务，而且许多业务处理逻辑完全集成在联机处理中。
随着站点在图中从左到右、从下向上移动，站点的运行和应用程序部署的难度明显增加。
图 4. 扩展维度
在本节的其余部分，我们考虑图 4 环境中的可伸缩性。首先，我们关注扩展独特客户和内容，然后再看业务复杂性的增加。
扩展客户和内容
接下来的图 5 和图 6 两个图例，说明了前端系统的数量如何变化，以满足客户不断增长的需求，以及如何增加分区的数据存储的数量来扩展联机内容。
（如果您的浏览器不支持inline frames，请点击这里在单独的页面观看此图）
图 5. 小型站点
上图表示了具有一个 IIS Web 服务器，一个文件或 SQL Server 和一个在 DMZ 内的实用程序服务器的基本站点，它连接安全 SQL Server 或文件服务器和安全升级服务器。下图表示，如图 5 所示的小型站点，应如何扩大才能支持更多客户和更多内容。
（如果您的浏览器不支持inline frames，请点击这里在单独的页面观看此图）
图 6. 扩大的站点
在前端，IIS Web 服务器的数量和这些服务器的 Web 群集的数量有所增加，并使用 NLBS 在它们之间平衡了负荷。在后端，文件服务器和 SQL Server 群集的数量有所增加，因此，逻辑需要包括在前端 Web 服务器中，才能将数据请求路由到正确的后端数据分区。我们下一步再说明这两种技术。
扩展前端系统
增加克隆的 IIS Web 服务器的数量、将其分组为 Web 群集和使用负荷平衡系统，是增加支持的独特客户数量的主要技术。但请注意，这涉及重要的应用程序状态考虑，我们将在后面讨论。
除增加 IIS Web 服务器的数量外，优化 Web 服务器执行的 Web 应用程序代码也很重要（这超出了本文档的范围）。
针对可伸缩性的 Web 前端负荷平衡
负荷平衡以虚拟 IP 地址的形式，向客户机提供了单一的服务名称，然后将客户机分布于提供该服务的服务器集上。
进行负荷平衡有三种主要技术：
- Round Robin DNS (RRDNS)。
- 带有专用的第三方外挂盒的智能 IP 负荷平衡。
- 服务器内部使用 Windows 2000 的 NLBS 的智能 IP 负荷平衡。
RRDNS 是配置“域名服务器 (DNS)”的一种方法，以使 DNS 对主机名的查询在一系列提供相同服务的 IP 地址中顺序分布。这是负荷平衡的基本形式。该方法的优点是：无成本、易于实现，并且不需要变动服务器。缺点是：没有关于单个服务器负荷或可用性的反馈机制，并且由于 DNS 更改的传播延迟导致将请求继续发往故障的服务器，从而没有办法从可用的服务器集中快速删除故障的服务器。
基于服务器的负荷平衡将一组服务器组成 NLBS 群集，然后令群集中的每个服务器根据源的 IP 地址决定是否处理该请求，来完成负荷平衡。如果群集中的一个服务器故障，则群集中的其他成员重新分组并调整源 IP 地址范围的分区。NLBS 的优点是低成本（NLBS 是 Windows 2000 操作系统的一部分），不需要特殊硬件或更改网络基础结构，而且没有单个故障点。目前的限制是服务器不能动态调整负荷，重组是根据服务器故障进行的而不是根据应用程序失效进行的（尽管第三方工具，如 NetIQ 和 Microsoft 的 HTTPMon，可用于削弱这些限制）。
将 RRDNS 与 NLBS 组合可产生更好的扩展和可用的配置。NLBS 群集中的所有节点必须在同一 LAN 子网上，并响应同一 IP 地址。配置不同子网上的多个 NLBS 群集，并将 DNS 配置为在多个 NBLS 群集顺序分布请求，是可能的。这增强了 NLBS 的可伸缩性并避免了 RRDNS 的缺点，因为有多台计算机可用于响应发往每个 NLBS 群集的每个请求。Microsoft.com 便以这种方式工作。
图 7. RRDNS & NLBS：三个独立 LAN 网段，一个域名
应用程序状态考虑
为了向客户机屏蔽服务器故障，请不要将应用程序客户机状态存储在 IIS Web 服务器上。不能动态平衡客户机请求的负荷。最好是将客户机状态存储在数据存储器中，并在需要时，根据 URL 编码数据或客户机 cookie，对每个客户机请求检索客户机状态。带客户机高速缓存的 cookie 也是一种很有效的扩展方法，该方法在每个客户机系统中存储各自客户机的信息，在每个客户机请求中向 Web 服务器发送该信息，并使用该数据将内容专用化或采用其他客户机指定的操作。RFC 2109（“HTTP State Management Mechanism”（HTTP 状态管理机制），可从 www.ietf.org/rfc/rfc2109.txt 中找到）描述了 HTTP cookie 协议。
但是，某些应用程序和协议要求长期的从客户机到服务器的连接。使用“Secure Sockets Layer (SSL)”发送加密数据并验证服务器身份，就是一个主要示例。大部分 IP 负荷平衡产品支持允许应用程序或协议维持与同一服务器的连接机制，以便它们正常工作，尽管没有故障透明性。
扩展后端系统
增加多处理器系统的内存和处理器可扩展后端系统。Windows 2000 Advanced Server 操作系统支持多达 8 CPU 和 8 GB 内存。但是，在某些情况这不再可能，或不希望对单个系统的可用性有如此大的数据依赖性。基于这一点，通过对其服务的数据或提供的逻辑服务进行分区，来扩展后端系统，是十分必要的。我们将此称为分区。与用于扩展前端系统的克隆（复制硬件、软件和数据）不同，分区只复制硬件和软件，而将数据分布在各个节点。对特定数据对象的请求则需要路由到存储相应数据的正确分区。这种由数据决定的路由，需要运行在 Web 服务器上的应用程序软件来完成。可将由数据决定的路由层视为：与无状态负荷平衡相对的带状态负荷平衡，前者用于克隆前端系统的扩展。还需要开发管理分区的拆分和合并的软件，以使负荷均匀分散在所有分区之上，这样可避免任何单个分区成为热点。
但是，这种责任通常落在应用程序工程师头上，他们将数据分散在业务对象上，而随着数据大小和工作量的不断增长，业务对象也将均匀分布在数量不断增加的服务器上。幸运的是，如前所述，许多站点服务按对象分区相对简单。但是，分区对象尺度选择在站点部署完成后很难更改，这使得升级设计决断尤为重要。
扩展的另一个方法是将后端系统提供的服务，分区为向客户机提供服务的功能专业化系统。这通常称为 n 层模型。我们将在下面有关扩展业务复杂性的章节里详细讨论它。
扩展网络基础结构
随着站点通信量（包括从 Internet 和 DMZ 内的内部通信，到企业网络的）的增加，网络基础结构也必须改进。为了支持这种增长的需求，必须增加链接带宽、将集线器升级为交换机以及安装附加网络（例如，增设专用的管理网络，以减轻后端网络的负荷）。
扩展业务复杂性
下图说明了随着集成到系统的业务过程数量的增长和业务过程联机性的增长，对系统安全性和数量的需求也随之增长。最大系统容量 — 系统设计能否随着业务增长而平稳迅速增长 — 通常是任何站点最为关注的。
站点复杂性的三种模型是：“内容提供商”、“脱机事务处理”和“联机事务处理”。
内容提供商。在这个模型中，不需要访问内部网络的事务处理。所有 Web 服务和内容服务器都来自 DMZ 内部。所有内容先装配在升级服务器上，然后再通过复制推入 DMZ 服务器。如前一节所述，通过增加 Web 群集、增加 Web 群集的克隆、增加后端群集服务器，可扩展该模型。
（如果您的浏览器不支持inline frames，请点击这里在单独的页面观看此图）
图 8. “内容提供商”模型
脱机事务处理。本模型同“内容提供商”模型类似，但附加了对内部网络上已有业务应用程序的脱机事务处理访问。在“内容提供商”模型中，复制用于从升级服务器更新 DMZ 服务器内容。为了支持脱机（非实时）事务处理，需要将事务数据从 DMZ 异步传输到内部网络。“Microsoft 消息队列 (MSMQ)”服务可用于可靠传输这些脱机事务。为了支持传统的交付通道，应用程序系统和数据库都要在内部网络上实现。标记为“其他交付通道”的设备代表传统的表达设备，如客户工作站、交互式语音应答单元 (IVRU) 或专用输入设备，如销售点终端或 ATM。该模型的复杂性，随着与内部防火墙后面的内部网络中后端服务器交互数量的增加而增加。MSMQ 既能支持异步通讯又能保证消息可靠传递，所以对这种类型的交互很有用。批量处理请求也是分摊给内部网络发送消息的成本的另一个成功技术。
（如果您的浏览器不支持inline frames，请点击这里在单独的页面观看此图）
图 9. “脱机事务处理”模型
联机事务处理。在此模型中，Web 浏览器真正联机访问驻留在内部网络上的传统应用程序。业务应用程序的功能是在内部网络上实现的，它通常支持多个交付通道。从 DMZ 到内部网络的事务通讯是用标准同步通讯机制实现的。在连接客户机时，与联机业务应用程序集成的需求，大大增加了该模型的复杂性。本模型最为复杂并且难于扩展，因为与内部系统的交互必须同步操作，或至少在客户正与联机服务交互时。这些交互类型需要认真设计，并且尽量减少其数量。例如，购物篮只能用 DMZ 内部的交互来扩大，而且只能在客户请求之后；实际的购买应当使用内部系统。
（如果您的浏览器不支持inline frames，请点击这里在单独的页面观看此图）
图 10. “联机事务处理”模型
可用性
简介
增加站点可用性的主要技术是增加冗余组件。这些冗余组件可用于创建多个通信路径、多个提供相同服务的服务器、以及在事件中替代故障服务器的备用服务器。
考虑下面两图。第一幅在前端系统和后端系统中具有某种高度的可用性。而第二幅具有所有组件和网络链路的冗余。
（如果您的浏览器不支持inline frames，请点击这里在单独的页面观看此图）
图 11. 使用某些冗余的中型站点
在图 11 中，我们有两个 Web 群集，每个都有多个服务器，并且我们有两个服务器群集，每个均配置为使用“Microsoft 群集服务”的故障转移群集。我们在下面的章节中讨论增加服务可用性的基础构件。
（如果您的浏览器不支持inline frames，请点击这里在单独的页面观看此图）
图 12. 使用完全冗余的大型站点
在使用完全冗余的大型站点中，不仅有多个 Web 群集，而且每个服务器都配置为使用“Microsoft 群集服务”的故障转移群集。另外，还有与多个 ISP 的连接和独立的管理网络。
前端系统的可用性
如第四节中关于可伸缩性的描述指出的那样，当克隆技术与 NLBS 负载平衡和无状态 Web 服务器的使用相耦合时，克隆技术可用于提供高度可用的前端 Web 服务。如前所述，如果用 Round Robin DNS 配置多个 NLBS Web 群集，还可使 Web 服务器从网络基础结构故障中恢复。
在“可伸缩性”一节中已阐明了基本的思想，以及附加的要求，即在克隆失败或运行于克隆体的 Web 服务器停止响应时，负载平衡系统必须从 Web 群集删除克隆体直至其修复。NLBS 自动跟踪 Web 群集的运作成员并在其中的某个出现故障时重组。当 Windows 2000 上的 IIS Web 服务器故障时，将自动重新启动。但是当 IIS Web 服务器挂起时，则必须通过监控工具检测。Microsoft 的 HTTPMon 或第三方工具如 NetIQ (http://www.netiq.com/) 都能编写脚本完成这个工作。
网络基础结构的可用性
网络基础结构和站点与 Internet 连接的持续可用至关重要。如示例站点所示，首要技术是通过多个 ISP 拥有多个 Internet 连接。连接应该是不同的；即，从提供者到用户所在地通信工具应使用物理上独立的路径。这样就消除了因断线引起的站点故障 — 这种情况并不罕见。
为获得最大的可用性，还应考虑使用不同的电源和余富的不间断电源。基础结构中的多样性常常是宿主站点的一个主要魅力，其便利在于专门提供了配以多家 ISP 的宿主服务。
在站点内，交换机和路由器应以这样的方式相互连接，即每个服务总有多条路径与之连接。最后，如在“管理与运作”一节中所述，单独的管理网络和带外网络，对于各种网络基础结构故障情况下的管理性能和恢复功能很重要。
后端系统的可用性
通过 “Microsoft 群集服务”可使后端系统高度可用，该服务是为群集上运行的服务提供数据层冗余和故障转移功能的核心技术。“Microsoft 群集服务”使多个 SQL 数据库和文件共享可共享 RAID 设备，这样如果主文件或数据库服务器故障，将有备份服务器自动在线以替代其地位。如 NLBS 一样，利用该系统级服务不需要专门的编程。
数据库和 Web 内容的数据，都需要存储在 RAID 磁盘阵列上进一步保护。如果硬盘发生故障，数据将持续可用，并且运行的硬盘可在不中断服务的情况下和磁盘阵列进行热交换。
后端服务器之间将定期发送称为心跳的消息，来检测故障应用程序或服务器。心跳在专用网络（如群集心跳网络所示）上通过专用 NIC 发送。如果某一台服务器检测到心跳网络通讯故障，它将请求群集状态确认。如果另一台服务器没有响应，则自动将故障服务器的资源（如磁盘设备和 IP 地址）的所有权转移给幸存服务器。然后，在幸存服务器上重新启动故障服务器的工作。如果个别应用程序故障（不是服务器故障），“Microsoft 群集服务”通常将在同一服务器上重新启动该应用程序。如果失败，“Microsoft 群集服务”将转移应用程序资源，然后在另一台服务器上重新启动。
安全性
简介
安全性即通过充分保护信息的机密性、秘密性、完整性和可用性来管理风险。安全性机制和服务，如加密、身份验证、授权、责任和管理，都支持这个目标。由于保护机制永远不会是完美的，所以检测机制（监控和审核）将在可能的入侵发生时产生报警或触发响应（纠正操作）。
安全域概念，如“体系结构概述”中所述，对于保证策略一致性和最经济的安全性控制应用程序是无价的。在域中，安全性如同一条链子，它的力量与其不牢固的链接一样。在整个域的应用一致的控制是必要的，整个域可能包含网络、平台和应用程序层以及域中所有功能和组件。需要在低安全性的域的边界补偿控制将安全性提高到需要的程度。
保护站点的第一步是分析商业风险、被保护系统和数据的自然情况以及可用安全性机制的成本，然后确定最优商业方案。
通常，商业站点应该比只用于浏览的信息站点具有更高的保护。许多商业站点包括多个有不同安全性需要的功能。没有必要对整个站点应用最高安全性的保护。通过把这些复杂的站点分隔为安全域，可以有选择地实现最高安全性保护，这可能是昂贵的。
安全性策略和物理的安全性程序是有效的安全性程序的重要方面。此外，尽管大型站点固有的复杂性或由安全控制附加的复杂性，实现最简单的用户和管理接口是很重要的。复杂性引起错误配置和避免。在可行的场合尽可能实现基于策略的安全管理和配置自动化。由于本文的重点是关于安全的体系结构和技术，因此我们不会进一步讲述这个问题。但是，重要的是注意到有效的安全性不只是一个人和方法问题。如果人们没有意识到安全性需求或认为无关紧要，那么最好的技术也是没有用的。
在本节的其余部分，我们将讨论多种保护机制，包括网络和平台保护。（应用程序保护超出了本文的范围。）接下来我们考虑复杂的 Web 应用程序所需的客户身份验证和授权。
网络保护
DMZ 结构
示例站点说明了防火墙和 DMZ 的应用。MDZ 是在 Internet 和内部系统资源之间提供多层保护的重要体系结构元素。它包含：
- 面向 Internet 的防火墙，它过滤 Internet 通信并将其从 DMZ 中的网络通信分离。
- DMZ 中支持所需服务的特殊功能和高度安全性（加固的）组件，如 Web 或电子邮件服务。
- 面向内部的防火墙，它从安全的内部网络中分离出 DMZ 通信，同时对这些网络中有限数量的加固系统和服务提供可控制的访问。
面向 Internet 的防火墙在实际中广为使用（尽管常以安全性路由器的形式）。允许与公司或其他安全网络进行网络连接的所有 Web 站点，还应该使用内部防火墙，将 DMZ 与内部网络隔离。
对于保护站点 DMZ 是必要的，但在自身内部并不是足够的。DMZ 中的任何组件一旦被突破，均可用于攻击整个站点。敏感的客户和帐户信息以及身份验证/授权数据库，不应放置在 DMZ 中，而应放在安全的内部网络加以保护。性能方面的考虑也许增强了将敏感数据复制到 DMZ 的需要。如“平台保护”一节讨论的，利用其他机制提高数据安全性是必要的。
防火墙类型
防火墙通常在网络协议层发挥功能，并将许可的源/目的 IP 地址和端口（协议，如 HTTP 或 SMTP）之外的所有网络通信排除在外。
最简单的方式是，可从配置了正确的“访问控制列表 (ACL)”的网络路由器建立防火墙。这种安全性路由器实际上经常用作防火墙。它们能过滤不想要的通信（根据协议类型和源及目的地址），并保护 DMZ 不受部分 — 而非全部 — 服务拒绝的攻击。某些站点由于性能原因使用路由器，因为非常复杂的防火墙不能支持所需的吞吐量（有时在每秒上千兆的范围）。低风险站点也可能由于成本原因选择配置安全性路由器。
通过维护通讯状态，数据包屏蔽或带状态的防火墙提供完全的网络层隔离。它们能检测已知的服务拒绝的攻击，并提供附加的安全功能，如网络地址转换（NAT，它完全隐藏内部设备）以及 FTP（动态选择数据传输端口）。常用的防火墙包括 Cisco 的 PIX 或 Check Point 的 Firewall-1。这些设备现在都能支持每秒超过 150 兆的吞吐量。
不过防火墙不是万能的。由于它们一般都在网络层发挥功能，因此不能防止较高协议层的攻击。例如，在不能正确检查进来的字符串的 DMZ 内，应用程序或 Web 服务器很容易受到缓冲区溢出的攻击。这会导致服务的崩溃或恶化，会让解密高手得以控制组件。遗憾的是，这种本事比想象的更为普遍。
防火墙配置
面向 Internet 的防火墙，应该只许访问支持 Web 站点商业功能所需的服务，典型的如 HTTP 和 LDAP，以及不常用的 FTP 和 SMTP 邮件。支持有限的商业对商业或其他远程服务的虚拟专用网络 (VPN) 也可能是需要的。认真审查并禁止开放访问所有的端口，除非有强烈的商业要求必须如此。用于构造防火墙的现用平台（例如，Windows 2000 和 Checkpoint 的 Firewall-1）必须是极其坚固的。
根据支持访问内部数据和系统资源，以及支持和管理 DMZ 组件所需的协议和服务，面向内部的防火墙同样应该对通信进行限制。如果解密高手设法穿过 DMZ，内部防火墙则是保护内部网络的关键信息资源的重要手段。穿越内部防火墙所需的端口和地址的数量及种类，往往比外部防火墙的还多，尤其是通过 DMZ 后端网络来支持管理功能。得以访问内部网络是解密高手的首要目标。限制为只能访问极有限的几组必要端口和目标主机非常重要，这样才能确保 DMZ 中的泄密系统只有有限的机会攻击内部网络。
网络隔离
出于安全性，DMZ 中的内部数据网应该隔离，同时增加带宽。通常每台计算机装配了两块以上网络接口卡 (NIC)。示例站点一节说明了网络分段并进行了一定的讨论。关键原则是：
- 将不同 Internet 通信类型隔离为不同的 Web 群集 — 例如，HTTP、HTTPS 和 FTP。然后，每个群集可配置为拒绝传输服务所需的类型以外的数据。
- 将 Internet 通信与后端通信隔离。这样防止从 Internet 直接访问内部网络，并且允许为每个 NIC 配置过滤器，从而将通信限制为只适合服务器所需的类型。
- 如示例站点中所述，为内部 Web 站点网络使用非路由的网络地址。
- 为了将管理通信与所有其他通信隔离，我们采用了管理