13.3.1满足最初的需求：libWWW库
如前所述.libWWW库就是--个用以创建能够在客户机或服务器上运行的应用程序的 软件库。这个库提供由大多数应用程序共享的一些基本功能，如与远程主机建立连接的能 力、理解HTML数据流的能力等。
构建libWWW库的目的是要创建一个小型的、可移植的软件库，以在此基础上创建诸如客户端程序、服务器程序、数据库、Web Spider离线浏览器等基于Web的应用软件。 该软件库从结构上分为5层，如图13.4所示：
通用实用程序层是整个软件库的最低层，在该层上实现了可移植性。该层包括系统的 基本构建块，如网络管理、数据类型（如容器类）以及字符串操作实用程序等。其上面各 层通过调用该层提供的服务就可以实现平台独立性。接入新硬件或适应新软件平台的工作 几乎完全是包括在该层中的，从而使得对每种平台只需在该层上做一次处理。
内核层包括了万维网应用程序的主要功能——网络访问、数据管理与解析、记录日志 等。该层本身不做任何实质性工作.而只是为上层万维网应用程序提供标准接口。实际功能是通过应用程序（指的是 通用实用程序层）注册的插件模块和调用函数提供的。插件（处于通用实用程序层）就是应用程序（指的是 通用实用程序层）在运行时注册的 模块，插件为内核层完成实际的工作——即数据的发送和处理„这些模块通常提供对协议 的支持，处理低层的数据传送，并能够识别数据的格式。插件可以动态修改.这就意味着 可以很容易地添加新功能，甚至更改Web应用程序的实质。
内核层中的调用函数则为应用程序功能的扩展提供了另外一种手段。调用函数是任意的、由应用程序指定的、能够在向协议模块发送请求之前或之后调用的函数。
通用实用程序层和内核层有什么关系呢？通用实用程序层以独立于平台的方式提供 实用功能，这些实用程序能够被用来创建任何网络应用程序„而内核层则是为构逑万维网 应用程序提供了 一个抽象层。
数据流模块层提供了数据流的抽象。在应用程序和网络之间进行的任何数椐传递都使用该抽象。
访问模块层提供了-•组与网络协议相关的模块。libWWW最初支持的标准协议包括超 文本传输协议（HTTP—万维网基本协议)、网络新闻传输协议（NNTP-Usenet消息
所使用的协议）、广域信息服务器（WAIS---个网络化的信息检索系统）、文件传输协
议{FTP}、TELNET、rlogin、Gopher、本地文件系统和TN3270。由于协议模块建立在较底层的抽象上，因此添加新协议模块的工作相对比较简单。
最上面一层由万维网应用程序模块组成。这-层并不是一个实际的应用软件，而是-组对应用软件的编写极有帮助的功能的集合。该应用层中包括高速级存、曰志、代理服 务器（用于协议转换）和网关（例如用来应付安全防火墙）注册、维持历史记录等常用功 能模块。
13*3.2 HbWWW库开发的经验教训
在创建HbWWW库及在此雄础上开发大置应用软件的过程中，积累了 经验教训。这些经验教训都足在开发人员想方设法实现在13.2节中所列的需求——即基于Web的工具应该是异构的、非集中式的、支持在网络上的远程访问等——的过程中得出的。但是， 事实证明，最难实现的需求是能够提供良好的接口。或者说，允许基于Web的应用程序的功能的不断增强成为在HbWWW库开发中左右研制决策的主要力量。它为我们带来了如 卞的经验教训：
•需要采用形式化的应用编程接口（API)。libWWW库向软件构架的其他部分提供 了功能接口.特別是对基于HbWWW库开发的程序更是如此。所以，应该以独立 于语言的方式指定应用编程接口，这是因为UbWWW库的目的是要为在各种平台 上、以各种语言进行应用软件的开发提供支持。
• 功能及表示这些功能的应用编程接口必须是分层的。不同的应用软件需要访问不同抽象层上的服务，这大部分都可以很自然地通过分层来实现„
• 该软件库必须支持动态的、可扩充的特性集=库中的所有特性都 必须是可以更换的，而且必须能够在运行时（即无需重新岿动系统）进行史换。
• 在该库基础上构建的进程必须是线程安全的。Web的应用程序必须支持同时 执行几个功能的能力.这主要是因为有些操作（尤其是通过较慢的网络连接下载 大数据量的文件）可能会花费很长时间。为此，应用软件耑要用几个并发的控制 线程-所以，应用编程接口所提供的功能必须要保证在多线程环境下仍然是安全的。
现在，libWWW痄并没有实现上述所有目标。而且，也不大可能全部实现„例如， libWWW痄的内核层假定了某些服务是必不可少的，因此并不是所有特性都可以动态更换。另外，libWWW库是耍在各种不同平台上运行的，因此它不能依赖于某个单线程模型。因此，libWWW库中采用了伪线程，这些伪线程提供了所需耍的某些（但不是全部）功能。 最后，现在的大多数Web应用软件都不支持动态特性配置，它们耍求必须重新启动机器才 能成功完成某些新服务的注册。
13.4.3早期用HbWWW库构建的客户机/服务器构架
阁13.5表示的是用HbWWW库的服务构建出來的一个典甩的客户机/服务器的部署 视图。还为部署视图的HTTP客户机和服务器组件给出了模块分解视阁。我们将利用这个 实例对HbWWW库做儿点说明。首先，并不是客户机/服务器构架的各个部分都足利用 libWWW痄构迚的。例如，用户接口就是独立的。其次，管理器的名称也并不一定与层的 名称直接对应：尽管访问管理器、协议管理器、数据流管理器很明显与访问层或数据流层有关。但高速缓存管理器使用的却是应用层的服务。在该客户机/服务器构架实例屮.数 据流管现器管理着底层的通信，从而保证了系统的其他部分能够透明地进行网上通信.
用户界面（UI)管理器负责处理客户端用户界面的外观。但是，考虑到万维网系统所 能够处理的资源类型是多种多样的.另一个元素“表示管理器”可以把信息显示委派给外 部程序（浏览器），以浏览系统知晓但用户界面管理器并不直接支持的资源。例如，大多 数浏览Web的用户使刖•个外部程序浏览PostScript成.pdf文件。这种委派是在用户界面 的集成性（可使用户界面风格一致，从而提高易用性）和可扩展性之间进行合理折衷的结果，
用户界面管理器捕获用户以URL形式表示的对信息检索的请求，并将此信息传送给 访问管理器。访问管理器査找并确定所请求的URL是否保存在高速缓存中，并解释基于 历史行为的导航（如“后退”)。如果在高速缓存中保存存该文件，就从高速缓存管理器中 检索该文件，并将其发送给表示管理器，以便在用户界面上或向外部浏览者显示文件的内容。如果在高速缓存中没有要访问的文件.协议管理器确定请求的类型.并调用适当的协 议完成该谪求所需的服务。客户数据流管理器使用该协议向服务器发送访问请求。客户数 据流管理器收到服务器返回的文档形式的响应后，就把此信息传递给表示管理器，最终以适当的形式将其显示出来。表示管理器要查询一个静态的视图控制配胥文件（mimerc. mailcap等)，该配置文件协助实现文档类型到外部浏览者的映射。
HTTP服务器确保了对文件系统的透明访问——我们使用Web就足为了通过它来传送 文件系统中的文档。这种对文件的访问可以由服务器直接处理（对已知资源类型），也可 以通过称作公共网关接口（CGI）的代理来实现„ CG1负责处埋本地服务器不能处理的资 源类型并负责处理服务器功能的扩展，下面将对此进行讲述。在服务器的功能扩展前，可 用的Web服务器实现的是HTTP请求定义的一个子集，该子集包括对文档的访问、对文档 元数据的访问和通过CG1实现的服务器端程序的执行。
当服务器数据流管理器收到访问请求时，要确定请求的类型并解析URL的路径。HTTP 服务器通过查询访问列表来确定发出请求的客户是否有权访问由URL所指向的数据。 HTTP服务器可能会向用户启动一个口令验证会话，以保证只有通过口令验证的用户才能 访问所保护的数掘。如果认证过程顺利完成，HTTP服务器就访问文件系统（该文件系统在服务器系统之外）并将所请求的数据写入输出数据流中。如果要执行个程序，则通过 CG1使用某个进程.程序被执行，由服务器数据流管理器将程序运行的输出结果返回给万 维网客户.
在这两种愔况下，CGI都是服务器提供可扩展性的主要手段。这种扩充的简便易行已 经成为推动Web软件不断演变的最重要的需求之一，CGI是基于Web的应用软件的重要 方面.，下面我们就详细讨论CGI这个话题。
13.3.4公共网关接口
服务器返回的信息大多数都是静态的，只有在其主文件系统上进行修改时才会发生变 化。而使用CG丨脚本则可使服务器动态地向客户返回针对所发出请求的数据。CG1一直用于加强服务器的功能：适用于数据的输入、搜索和单击图像„但CGI最常见的用途则是创 建虚拟文档——即针对用户请求动态合成的文档。例如，当某个用户在Internet上杳找某 个数据时，搜索引擎创建针对该搜索请求的回复，CGI脚木根据这些回复创建.个新的 HTML文档并将其返回给用户„
CGI脚本的使用展现了一个基于libWWW库的构架的灵活性。在图13,5中，CGI位于服务器的外部，CG丨脚本可以用多种语言来编写，其中有些是编译执行的（如C, C++, Fortran),而另外一些（如Perl、Visua丨Basic、AppleScript等）则是解释执行的。使用这些 脚本，开发人员就可以任意地扩展服务器的功能，尤其是产生将经由服务器返回给用户的 信息。
但是，由于这些脚本中可以包括用C、Perl等语言编写的任何功能，所以对于安装了 这些脚本的系统来说.它们表示存在严重的安全漏洞-例如，可以使某个脚本程序（独立 于服务器、以进程方式运行）在主机系统上代替远程用户执行任何命令。服务器端像CGI 这样的脚本的广泛使用是导致安全问题日益突出的重要原因之一。下-节将讨论使用 HTTPS宋解决这-问题。
很可能CGI使万维网构架所具备的最主要的特性是允许用户将自己的信息放到Web 上，而不再仅是获取服务器提供的信息。尽管在最初的万维网项目的原始需求文档中就列有将用户的数据放到Web上这-项，但时至今日也没有完全实现这.功能,,CGI仅允许用 户以与特定应川程序相关的形式将数据放到Web上，例如通过填写表格将数据加入到数祸 库中。
虽然可以用CG1解决HbWWW库原始设计中存在的许多问题——主要是因为它提供 了最迫切需要的处理任怠资源的服务器扩展能力，并允许用户以冇限的方式将数据放到网 络上——但它也有一些显著的缺陷。一个是上面提到的安全性问题：另外个是可移植性。 用 Visua丨Basic，ApplcScript 和 C Shell 编写的 CGI 脚本分别运行在基于Windows.、Macintosh
和UNIX的系统上。这些脚本在不同平台之间的移植足阐难的或不可能的。
13.3.5实现最初的质量目标
表13.2描述了 Web如何实现了其最初的质置目标：远程访问、可互操作性、可扩展 性和可扩充性。
表13.2 Web如何实现了其鼉初的质置目标
13.4基于Web的电子商务构架的演变
Web的不可思议的成功使企业对其产生了极大的兴趣，因此也就通过构架商业周期对 构架产生了前所未有的压力*企业的需求开始支配Web构架。商家对商家 (business-to-business)和商家对消费# (business-丨o~consumer)网站刺激了基于 Web 的软 件中的大多数创新。
Web最初的概念是作为一个文档网，与超文本根保持•致。然而，电子商务把Web 看做是数据网，这些不同的视图导致了一些使人焦虑的因素。例如，把数据“推”给用户 是困难的：更新数据的最常见的技巧就是在指定的期间内重新载入，而非依赖数据变更來 迫使屏蘑更新。另一个就是浏览器上的后退按钮，在某些情况下.这会导致在屏藜上显示的是陈旧的数据。
电子商务的新需求是苛刻的，它与在13.2节中表述的最初需求有很大不同：
• 高性能。一个广受欢迎的网站每天的点击次量一股会有数千万次，用户希望等待 时间很短。如果客户的请求遭到拒绝的话，他们将无法容忍。
• 高可用性。人们希望电子商务网站具有24x7的全天候的可用性。它们永远也不
会关闭，因此停机时间必须最少——大概每年只有几分钟„
• 可扩充性。随着网站访问量的增加.其处理離力也必须提高.从而不仅扩展它们 能够管理的数据量，而且保持一个可接受的客户服务级别。
• 安全性。用户必须确保他们通过Web传送的任何敏感信息的安全性„网站的操作 人员必须确保其系统不会受到攻击（盗取或修改数据、通过提交大量请求使数据 不可用或使系统崩溃，等等)。
• 可修改性。电子商务网站的内容频繁发生变化，很多情况T每天都会发变化， 因此它们的内容必须很容易修改。
这些需求的构架解决方案更多的是关于“系统"构架，而不只是软件构架。系统中的 组件来自商业市场：当然包括Web服务器和Web客户机，此外还有数据席、安全服务器、 应用服务器、代理服务器、交易服务器，等等u
图13.6给出了个现代电子商务系统的典型的参考构架。浏览器/用户交互功能通常 由Web浏览器来执行（它可能是个kiosk, 一个支持Web连接的早期系统或其他支持 Web的设备)。业务规则和应用功能一般由应用服务器和事务服务器来完成„尽管与早期 系统和早期数据库的连接也是很常见的，但数据服务层通常由现代数据庳实现。我们通常 把该模式叫做n层构架（这里n=3）。“层”是可以分配给单独的物理机器的功能划分。
电子商务系统构架的典型实现由许多层组成.每个层由-组一致的软件（一般是定制 的商业组件）和硬件组成。图13.7给出了这样的-个配置，它说明了如何将软件分配给硬件。
该图中标注有阁13.6中的功能元素，以加深这•概念：在典型的电子商务构架中，参 考构架中的中•个功能可以映像到多个层上。在此，图13.5中的两部分是作为元素组件出现 的：分别为Web浏览器（客户机）和Web服务器，这反映了朝着基于组件的系统的演变 方向，其中内部组件的结构不太相关。
现在.我们将对图13.7中的每个元素以及每个元素有助于实现的质量属性进行讨论.
13.4.〗支持可修改性的Web浏览器
最终用户•般通过与Web浏览器交互来启动对信息的请求,，现代Web浏览器以各种 方式支持用户界面的可修改性，自从Web出现以来，大部分都没有发生变化,，浏览器所支 持的用户界面并没有进行硬连接，但它是通过HTML指定的，至少过去是这样的„现在. 有许多其他用于创建复杂用户界面的技术。我们采用某些方法对Web交互程序的标准面板 进行拓宽，以通过浏览器提供全面可编程的交互界面；XML, Flash, ActiveX和Java applel 就其中的几个方法。
13.4.2支持安全性的HTTPS
用户提交了请求后，就必须把该信息传输给目标网站。该传输可以通过HTTP或 ffTTPS进行。HTTPS用于诸如信用卡或身份号这样的敏感信息的传输,inTPS使用 Netscape的安全套接字层作为HTTP卜‘的子协议。它使用一个不同的端口（443而非HTTP 所使用的标准端口 80)以加密的形式来请求TCP/IP服务。SSL使用128位的公钥/私钥对 来加密数据，对于小型交易中数量不大的商业信息交换来说，这种级别的加密已经足够了。
13.4J支持性能的代理服务器
来自单个浏览器的请求可能会首先到达代理服务器。代理服务器的作用是提高稱于 Web的系统的性能。这些服务器将访问频繁的网页商速缓存起来，以使用户不需要访问该 网站就可以得到这些信息。（高速缓存执行“多个副本”战术)。代理服务器的位置-般离 用户很近，通常在同一网络上，因此它们可以保存大量的通信和计算资源.•些公司为限制其员工访问某些网站也使用了代理服务器，在这种情况下，代理服务器所起到的作用有 点像防火墙。
13.4.4支持安全性的路由器和防火墙
来tJ浏览器（或代理服务器）的请求到达位于电子商务提供商的网络上的路由器.该 路由器可能包括-个用于安全性的防火墙（路由器也可能会把HTTP请求传递给单独的防 火墙),，路由器可以实现网络地址转换（NAT),它把外部可见的丨P地址转换为内部的1P 地址，对来自Web服务器的任何返回通信的IP地址进行转换，以使它看起来是来自外部 可见的网站，而非内部的IP地址。NAT是在负载平衡中使用的一种技术，我们将对其进 行简要讨论。
安装防火墙的目的是防止未经授权的信息流或来自外部世界的访问，这是“限制访问”
战术的一个示例。有儿种类型的防火墙，最常见的就是“数据包过滤器”和“应用代理”, 数据包过滤器检奋到来的每个数据包的TCP和IP头，如果检测到了任何不良行为（如试 图通过未经授权的端口连接或发送没有确认的文件类型)，则拒绝该数据包。数据包过滤器防火墙适用于基于Web的通信.因为它们以隔离的方式检杳每个数据包——不试图维持 以前通信的历史。
正如其名字所暗示的那样，应用代理防火墙是特定于应用的（应用层协议）。它们通常理解应用协议， 因此可以根据行为的己知模式对通信进行过滤。例如.应用代理可以拒绝某个HTTP响应， 除非该站点最近收到了 HTTP请求。这些防火墙可能会比数据包过滤器防火墙慢很多.因为他们要在手头保留一定数量的历史信息，因此其处理会更加复杂。
13.4.5支持性能、可扩充性和可用性的负载平衡
在任何重要的电子商务网站中，负载平衡组件都是不可或缺的•部分，因为它支持性 能、可扩充性和可用性。负载平衡器的任务就是在运行Web服务器的计算机池中分配“负 载”——到来的HTTP和HTTPS请求（第5章竹经讲过，负载平衡是根据“引入物理并 发”战术得出的）。负战平衡器可能只是（透明地）把该请求重新定向至另•台计算机，
或者它也可以对Web客户机作出响应，并命令它将该请求复位向至一个不同的服务器。该复位向对最终用户来说是透明的，它导致了通信的•个额外的往返。
在选择把该通信复位向至哪台汁算机时，负载平衡器可能会以一种循环的方式进行选 择.或者是根据它所连接的每台计算机的已知处理或负载特性进行选择.因为负栽平衡器 充当计算机池的代理，因此我们可以向该池中添加计算机，无需改变任何外部接口，这样， 负载平衡器就支持了性能的可扩充性.这就是我们所熟知的横向扩充（添加一个给定资源 的多个实例）。
此外.负载平衡器也可以监视每台计算机的状况，如果一台计算机出现了故障，那么， 把通信复位向至该池中的其他计算机。负载平衡器以这种方式支持了可用性。
13.4.6支持性能的Web服务器
接下来，HTTP或HTTPS请求就到达了 Web服务器。早期的Web膿务器（如13.5节 中所描述的服务器）•般都是单线程的。现在的Web服务器是多线程的，它利用线程池， 可以分派其中的每个线程来处现输入的清求。当大量的持续的HTTP或HTTPS请求（如 信用卡确认）到达时.因为池中的其他线程仍然可以为到来的请求提供服务，因此多线程的服务器不太容易出现瓶颈（因此不会有很长的等待时间）。这就是“引入并发”的性能 战术。
可以用能够同时运行更多线程的更强大的服务器更换现有的服务器.从而实现纵向扩 充（添加一个给定资源的更强大的实例）。
对请求进行分析后，Web服务器将把它发送给可以对其做出响应的应用服务器.•般 是使用数据库的服务來进行此项工作。
第16章将讨论Enterprise JavaBeans,这是Web服务器的•个现代的实现方法。
13.4.7支持可修改性、性能和可扩充性的应用服务器
我们将来自Web服务器的请求转发给应用服务器。应用服务器是--个含义广泛的术语 (有人认为这是-•个定义不良的术语），针对的是在n层构架的中间运行的一类应用—— 业务规则和应用。这些服务器实现业务规则和连接性.它们规定了服务器和客户机的交互 方式。可以通过使用应用服务器把大部分应用功能从旧式的“胖”客户机移到中间层中，而且，它们能够使数据库集中进行数据的存储、检索和分析，而不必担心使用该数据的准 确方式。
位于低端的应用服务器般会提供集成的开发环境（IDE)和运行时服务器。IDE支 持编程模型.如COM (或最近的.NET), CORBA或J2EE (将在第16砍讨论)， —些应用
服务器还支持一组经常使用的服务，以快速创建业务和电子商务应用，如计费、库存、工 作流和客户关系管理。在成本、复杂性和功能方面，上端的就是事务处理和事务监视。事务监视器和处理器与数据库交互，并管理像分布式交易（包柄组合来自多个源的数据)、 排队、交易完整性和工作负载平衡这样的任务（很像早先提到的负战平衡器〉。
13.4.8支持性能、可扩充性和可用性的数据库
最后.对服务的请求到达数据库。在这里，我们将其转换为指令，以添加、修改或检 索信息。现代的数据库构架与在图13.7中表述的整个电子商务系统共享了许多质量属性。它们频繁使用内部复制以实现性能、可扩充性和高可用性。它们可能会使用高速缓存来实 现更快的性能。
13.5实现质量属性
我们描述的所有内容结合起来，能够使基于Web的电f商务系统实现其要求苛刻的质 最目标：安全性、高可用性、可修改性、可扩充性和高性能。衣13.3给出了实现这些目标的方式。
表13.3基于Web的电子商务构架如何实现了其质量目标
13.6当今的构架商业周期
在历经了几个构架商业周期之后，如果仔细考察一下当前的Web,就可以发现若干现象:
• 几个不同类型的组织提供了技术环境。我们可以把这些组织划分为服务提供商和内咨提供商。服务提供商即为Web提供软件——浏览器、服务器、数据库、应用服务器、安全技术（如防火墙〕、交易服务器、网络和路由器"~一的组织。，内容提供商则是为Web提供数据的组织。无论是在软件方面还足在数据方面，日前的 竞争都非常激烈。
•除W3C外，有大量的开放源项目已在Web开发中突出出来.尤苒足Apache项目
• CERN在Web的演变中没有起到什么特殊的作用
•支持Web的语言，尤其是Java,正在改变开发功能和通过Web交付该功能的方 式(第丨8暫给出了 一个如何使用Enterprise JavaBeans构述猫十Web的应用的示例）
•作为分布式开发环境的Web的出现产生了几个新组织和产品例如，UDDI (Universal Description. Discovery. Integration)提供了 Web 服务的分布式基于 Web的注册,以把这些服务作为分布式基于Web应用的构建块。
图13.8给出了 Web当前的构架商业周期。
Web的客户是软件服务器和浏览器提供商以及内容和服务提供阍.最终用户是全球人 .构架商业周期的作用由W3C和其他联盟（如UDD1, Apache project)和其他几家有影响力的公司（如Sun, Microsoft, AOL/Netscape)给出。现在的技术环境中也包括了万维网，这就增加了在质量属性方面对向上兼容性的要求。除此之外，现在的构架商业周期与原始设计时的构架商业周期相同。
在本书的1.1节中我们曾讨论过构架商业周期的循环往复。某个系统的存在为开发组 织和该组织的客户都提供了新的商机。对万维网而言，其开发纽织CERN决定了万维网开发不是其主要工作——CERN是一个研究原子能的组织.其他组织利用了由构架的循环 往复所带来的商机.
13.7小 结
Web之所以是成功的.源于在其构架结构中实现所期望的质量属性的方式，以及在面 临动态的新需求时，重新确立这些结构的方式。Web的成功意味着仅仅在几年内.构架商 业周期已进行了多次反复循环，每一次循环都产生了新的商机、新的湔求和新的技术挑战。 为了说明Web对商业的影响，我们给出了下面的例子：
13.8可进一步参阅的文献
如果读者想了解有关超文本的更多内容，可参阅[Bush 45]和CACM关于超文本的 专刊[CACM 88]。
关于Web的历史及其发展情况的内容可在Web上査阅。我们在编着此书时参考了 [Bemers-Lee 96a ]，[Gray ( http://www.mil.edu/people/mkgray/net )],以及[Zakon (http.VAvww^akon.com/roberi/intemet/timeline)].
关于libWWW的大量详细信息可访问网站http://www.w3.org/pub/lVWW/Li.brary,从 W3C参考库中获得。
如欲获知关于网络安全M题和密码术的讨论.包括Web安全性的所钌方面的内容.请 参见[Stallings 99]。如欲了解电了-商务领域中的竹:题,请参见[Menasce 00]。
如欲获知在轴于Web的应用中所使用的构架样式，请参见[Fielding 96]。[Hassan 00] 对现代Web服务器模式进行了比较，我们可以根据这些内容修改图丨3.5中的客户机/服务 器构架。
可以访问网站 http://www.netcraft.com/survey八来获知 Netcraft 在 2001 年 5 月对 Web 服务器使用情况的调査。
13.9讨论题
(1)我们已经指出了万维网赖以成功的若干个质量属性：可互操作性、可移梢性、远 程访问能力、可扩展性和可扩充性。你认为哪个因素对Web的成功最关键？如果牺牲其中 的某个或某些质蛩属性，Web还会像现在这样成功吗？基于libWWW的应用程序的构架 的质标要求做哪些权衡？
(2)在早期阶段，万维网没有将性能作为其质量目标。对于一个成功的系统来说，这 并不多见。你认为为什么我们认为该系统是成功的？这一点是否体现了计算技术未来发展 的趋势？如果是的话，是什么样的趋势？
(3)在图13.4、图13.5和图13.7所示的构架部分中.你可以i只别出哪些模式和战术？
原文地址：https://www.cnblogs.com/mongotea/p/11986394.html