翻译-现代浏览器的架构与发展

A Reference Architecture for Web Browsers.

作者：纪翔 2011-05-28

摘要：

一个领域参考架构抽象出了这个领域的公共子系统以及这些子系统之间的关系。领域参考架构在设计时和维护时可给予你很大的帮助，它可以增强你对系统的理解，帮助你在不同的设计方案之间进行选择和权衡。你也可以使用它充当模板来设计新系统或者重构现存系统。

我们调查了Web浏览器领域的历史并且明确了几个这次演化的主要动机。我们基于两个知名开源浏览器实现开发了这个参考架构，并且使用另外的五种浏览器实现来对这个架构进行验证。
我们讨论了不同代码重用策略的持续影响并且明确了Web浏览器领域的几种基本演化现象。即倏忽（emergent）领域边界，趋同进化，以及开源和闭源两种方式之间的伸缩性。

1 介绍：

一个领域参考架构抽象出了这个领域的公共子系统以及这些子系统之间的关系。领域参考架构会在对系统的理解方面给予你帮助，这些系统中的一部分甚至可能没有自己的架构文档。在设计和实现两种级别中,它还可以通过识别重用区域来充当创建新系统的模板。尽管在很多成熟软件领域都拥有其领域参考架构（如编译器和操作系统领域），可是我们没有发现任何Web浏览器参考架构被提出。

Web浏览器有可能是目前为止使用最为广泛的应用程序软件。它在过去的十五年中经历了明显地演化。今天，Web浏览器运行在各种各样的硬件之上，从手机到平板电脑再到台式机。Web浏览器引领着每年数十亿美金的网络电子商务市场。一个参考架构可以帮助实现者们在实现系统时去理解哪些权衡方案，还能够协助系统维护者们去理解遗留代码。将旧系统的架构与参考架构进行对比可以洞悉到此领域发展趋势。

在本论文中，我们提出了一个Web浏览器的参考架构，它从两个现存的开源系统的源码中推导得来，另外我们使用了另外的五个系统来验证了我们的研究结果。我们会阐述Web浏览器的演化历史是如何影响这份参考架构的，并识别基本现象，这有助与解释当前的趋势。

尽管我们提出的这些观点是关于Web浏览器的，但我们相信我们的许多研究成果能表达更广泛的，能应用与其他领域软件系统的演化模式。

本文组织如下：下一节提供了一个Web浏览器的概览，概述了其历史和演变。然后，我们将描述我们基于两个现有的开源系统源码来开发此参考架构时所使用的过程和工具。接下来，我们提出这个参考架构，并解释它如何来表示那两个被推导的开源系统的共通性。然后我们将展示它如何被映射到五个额外系统的概念架构上，以此来验证我们的参考架构。最后，我们总结了我们在浏览器领域的观点，讨论相关工作，并提出结论。

2 Web浏览器领域
万维网（WWW）是一种处于互联网顶端的通用信息作业空间，网络上的每个资源都通过统一资源标识符（URI）来定义。资源可以是多种不同的形式，包括文档，图像，声音或视频剪辑。文档通常使用超文本标记语言编写的（HTML），它允许作者嵌入超链接到其他文档或者在同一个文档中的不同地方。数据传输通常是通过超文本传输协议（HTTP），一个无状态和匿名的信息交换方式。一个Web浏览器是一个程序，这个程序从远程服务器获取文档然后显示到浏览器窗口中或者是传递这个文档到一个辅助程序中。浏览器允许特定的资源被URL显式的请求,或者隐式传递通过嵌入式超链接（embeddedhyperlinks）。

尽管HTML本身就是一种对于网页编码相对简单的语言，不过其他技术也可能被用来改善视觉表现力和用户体验。层叠样式表（CSS）允许作者添加布局和样式信息到网页，而无需把原来的结构化标记弄复杂。JavaScript,当前被标准化为ECMAScript，是一个用于执行客户端计算的本机环境（译注：本机环境是指浏览器作为宿主所提供的环境）。脚本代码被嵌入到HTML文档中，计算JavaScrip代码后得到相应的求值结果将被应用到静态HTML的结构中去。JavaScript的应用的例子包括：改变元素焦点，变更页面和图像装载行为，并解释鼠标行为。最后，还有一些类型的内容在Web浏览器中不能被直接显示，如MacromediaFlash动画和Java applets. 插件，小扩展由浏览器来加载，用于嵌入这些类型的内容到网页中。

除了获取和显示文档，Web浏览器通常还为用户提供其他有用的特性。例如，大多数浏览器会记录最近访问的网页，并提供一个机制来将你喜欢的网页标记为书签。它们还可能会存储经常被键入的表单值以及用户名和密码。最后，浏览器通常提供辅助功能，以适应低障碍用户，如失明、低视力、听力丧失、运动障碍等。

2.2 历史和演化
虽然关键概念可以追溯到Vannevar Bush在1940年的系统设想，在1990年WWW的描述首次作为提案由TimBerners-Lee在欧洲原子研究中心(CERN)撰写。到1991年，他写了第一个Web浏览器，这个浏览器是图形化的，它还可以作为一个HTML编辑器。大约在同一时间，在美国堪萨斯大学的研究人员已经在一个纯文字超文本浏览器上独立开展工作，这个浏览器称之为Lynx.在1993年，他们改写这个浏览器去支持网络.同年，国家超级计算应用中心（NCSA）发布了一个图形化Web浏览器称之为Mosaic，它允许用户直接浏览穿插着文字的图像。鉴于网络的商业潜力开始增长，NCSA创办了一个称之为Spyglass的分支公司来商业化它的技术，Mosaic的主要开发者MarcAndreesen辞职并创办了自己的公司Netscape(网景)。1994年，Berners-Lee创立了万维网联盟（W3C）来指导网络发展和促进Web技术之间的互操作性。1995年，微软发布InternetExplorer（IE），IE基于从Spyglass授权的代码，引发了与Netscape激烈的竞争，这段时期被称之为“浏览器大战”。微软最终得以占领了市场，随后Netscape在1998年将其浏览器产品以Mozilla的名字开源。

图1显示了几个著名的网络浏览器的不同版本的时间表。



自1998年来，Mozilla出现了一些变化，重用浏览器核心却要向用户级别特性提供替代设计决策。Firefox是一个使用了简化用户界面的独立浏览器，排除了Mozilla集成的邮件，新闻和聊天客户端。Galeon的是用于GNOME桌面环境的浏览器，它与其他GNOME应用程序和技术集成。开源的Konqueror浏览器也同样被重用：Apple已经集成它的核心子系统到OSX Web浏览器，Safari, 并且Apple的修改也转而被其他浏览器重用。InternetExplorer的封闭源代码引擎也出现了被重用的情况：Maxthon, Avant,和NetCaptor都提供额外的功能，像标签页浏览和广告拦截。尽管每个浏览器引擎通常会产生类似结果，不过根据不同的外观和行为，结果也可以是不同的。Netscape8基于Firefox，允许用户在基于IE的渲染和基于Mozilla的渲染之间进行即时切换。


3 推导出一个参考架构
一个系统的概念架构是一种对主要子系统设计的高阶描述。它不会涉及到较低级别的细节（如在类或者过程级别上的描述）。概念架构表示了开发者如何去思考系统并且包含了各个子系统之间的关系，这种关系对于开发者来说是有意义的。一个系统的实体架构是一个主要子系统实现的高阶描述。实体架构可能会由于各种原因而不同于它们的概念架构，例如，实现中的限制可能会要求额外的子系统关系，额外的子系统关系不会影响对系统的整体理解。所有的组件之间的关系都是二元的，它表示某个子系统使用着另外一个子系统。

利用两个成熟浏览器实现中的源码和可用文档，我们推导出一个Web浏览器领域的参考架构。该参考架构表示领域的抽象架构，并由下面的过程来推导：

（1）选择两个成熟的浏览器来推导此参考架构
（2）对于每个浏览器

  （a）基于领域知识和可用文档来提出概念架构
  （b）从源码中抽取出实体架构，并且使用它来改进概念架构
（3）基于多个概念架构中通用的架构部分来提出参考架构
（4）使用其他的浏览器实现来对参考架构进行验证

两个被选择用于推导基准的浏览器是Mozilla和Konqueror，选择它们是因为它们都是成熟的系统，拥有着可观的开发社区和用户基础，提供良好的网络标准支持，并且是完全开源的。IE和Opera满足了前三项需求，但是由于是闭源软件所以并不适合用于研究。


3.1 抽取方法
利用QLDX来将每一个系统的实体架构从它们的源码中抽取出来，QLDX是一个在Waterloo大学开发的逆向工程工具，这个工具用于探索和可视化软件架构。该工具包包括bfx，一个C和C++因子(Fact)提取器，这个工具工作于二进制对象文件之上。jgrok，一个能够计算因子关系的计算器，还有lsedit，一个用于编辑和查看软件格局模型(Landscape)的工具。



提取实体架构的流程如图2所示。首先，使用标准的GNU工具链将系统的源码编译成二进制目标代码，标准的GNU工具链包括make,gcc,binutils和autotools.接下来，使用bfx来抽取出程序因子，一个典型的程序因子文件中包含了那些被定义在程序对象文件中的内部符号，这些内部符号被程序的外部符号引用和解析。然后一个专用jgrok脚本将处理这些程序因子并通过这些因子生成各种对象文件之间的链接关系。如果被研究的系统相对较大，则实体之间关系将由方法和变量传递变为从文件来进行传递，这个过程是通过使用另外一个专用jgrok脚本来实现的。接下来，基于系统的概念架构来创建分层子系统的分解描述（decomposition），这个包容结构将随后被应用到文件等级的程序因子中去，最后一个标准schrma将被添加到这个分解描述中来构造软件格局模型。格局模型是一个系统实体架构的初步版本，它将被lsedit进一步的勘查和调整以达成最终版本。

提取物的大小通常会比编译构件小的多，提取过程几乎是完全自动化的，唯一的手动任务是去手动推导分层子系统分解描述和在lsedit中调整形态图。如果系统比较小或者源码的目录结构与架构结构匹配良好，则这些步骤不会需要很多的工作量。不过如果系统比较大并且架构的结构不能在目录中被直接反映出来，那么开发一个准确的子系统分解描述将涉及到相当多的工作量。

4 一个网络浏览器的参考架构

我们得出的参考架构，如图3所示。它包括八个主要的子系统以及它们之间的依赖关系：



（1）用户界面(UI)子系统是用户和浏览器引擎之间的层，它提供了一些特性象工具条，页面加载进度显示，只能下载的处理，参数，还有打印。这个层有可能与桌面环境相集成来提供浏览器会话管理或者与其它桌面应用程序进行通信。

（2）浏览器引擎(BrowserEngine)子系统是一个可嵌入组件，它提供了到渲染引擎的高层接口。它负责加载一个给定的URI并且支持基本的浏览行为，像前进，后退和刷新等功能。它还提供了钩子用于查看浏览器会话的不同的方面，比如说当前页的读取进度，还有JavaScriptalerts.它还可以查询和操作渲染引擎的设置。

（3）渲染引擎(RenderingEngine)子系统为给定的URL产出可视化的表示，这便是显示HTML和XML文档的能力。渲染引擎也可以使用CSS进行样式定制，以及嵌入其他内容，比如说图像。它计算额外的页布局并且有可能使用“reflow”算法来增量调整一个页中元素的位置。另外，HTML解析器也被包含在这个子系统中。

（4）网络(Network)子系统实现了文件传输协议，如HTTP和FTP。它在不同的字符集之间进行传输，并且解析文件的MIMEtype。它还有可能实现了一个最近被获取资源的缓存。

（5）JavaScript解释器(JavascriptInterpreter)评估JavaScript代码，这些代码可能是被嵌入在网页中。JavaScript是一个面向对象的脚本语言，由Netscape开发。某些JavaScript的功能，如打开一个弹出窗口，可能被浏览器引擎或者渲染引擎禁用，这是处于安全考量。

（6）XML解析器(XML Parser)子系统解析XML文档到一个DOM（Document ObjectModel）树中。它是此架构中被重用频率最高的子系统之一。实际上几乎所有浏览器实现都使用了现有的XML解析器而不是从头开始创建。
 

（7）显示后端(DisplayBackend)子系统提供绘制和元窗体，一套用户界面组件，一套字体。这个子系统与操作系统密切相关。

（8） 数据持久(Data Persistence)子系统将浏览会话相关的不同数据存储到磁盘上。

读者可能会问为什么我们将HTML解析器定义在渲染引擎之中，同时还将XML解析器孤立成一个单独的子系统。回答是：XML解析器是一个通用的，可重用的组件，它拥有标准的，定义良好的接口。与此相反，由于性能方面的原因，HTML解析器通常被紧密的集成到渲染引擎以提供不同的支持等级来支持碎片式的和非标准的HTML内容。这种紧密集成来自于设计决策，而且看起来已经成为各种浏览器的共通特性。

我们研究了两个浏览器，以导出我们的参考架构。之后来展示特们的概念架构是如何映射到参考架构之上的。

4.1 Mozilla

Netscape在1998年开源了Mozilla套件。自那时起系统的大部分已经被重新设计和重写，大量的新功能被添加。Mozilla的主要设计目标是大力支持Web标准，支持多平台以及高速页面渲染。我们研究了版本1.7.3,它由约240万行代码组成。尽管大部分的用户界面使用JavaScript来编写并且一些遗留组件使用C来编写，不过大部分源码是使用C++来编写。我们构建和提取了Linux版本的Mozilla,这个版本使用了GTKtoolkit。



Mozilla概念架构到参考架构的映射关系如图4所示。用户接口被分离成为两个子系统，以便于部分功能可以被其他应用程序重用，比如说Mail或者News客户端。Mozillaprofile机制提供了数据持久化能力，它可以存储如书签之类的高层数据或者是如页缓存之类的底层数据。Mozilla的渲染引擎相比其他的浏览器更大而且更复杂。原因之一在于mozilla能良好的解析和渲染不正确的和畸形的HTML。另一个原因是，渲染引擎还呈现应用程序的跨平台用户界面。用户界面使用平台无关的XUL语言来进行描述，XUL通过专门编写的适配组件转而映射到平台指定的界面库上。这种架构使Mozilla有别于其他直接使用平台制定界面库浏览器，它最大程度的减少了用于支持多平台所需的维护成本。

最近，Mozilla的核心已经被重构为一个公共运行时：XULRunner，XULRunner它暴露渲染引擎，网络，JavaScript解释器，显示后端，以及数据持久子系统给其他应用程序。XULRunner允许开发者使用流行网络技术来创建富客户端应用程序，而不是典型的基于浏览器的Web应用程序。事实上，Mozilla的开发者们正忙于将基于Mozila的应用程序（Firefox,Thunderbird）转换为直接使用XULRunner使它们不必再去使用核心库的独立副本。

4.2 Konqueror

Konqueror是KDE的官方浏览器。它也可以作为一个图形文件管理器和通用文件浏览器。对Konqueror的开发始于1999年，其主要设计目标是速度快，标准化兼容并且与KDE集成良好。我们研究了3.3.2发布版，算上它所需的KDE库，它由大约61.3万行代码组成。Konqueror完全使用C++进行编写，这是由于它所需的不少代码都来自于KDE。我们发现Konqueror的代码组织相当良好，模块清晰的分割成各个子目录，并且每个子目录中通常都包含一个设计文档来阐述主要抽象和设计决策。



Konqueror的概念架构到参考架构的映射关系如图5所示。Konqueror广泛使用了各种KDE库：KHTML执行解析，布局，网页渲染；KJS解释嵌入的Javascript代码；KWallet通过强大的加密和错误发现能力来存储敏感数据（如密码）；KIO是一个异步虚拟文件系统，它自动的在通用协议上提供加密和解密。XML解析器和显示后端子系统由QTtoolkit来提供，QT toolkit是所有KDE应用程序的基础；这些子系统处于浏览器之外。PCRE(PerlCompatible RegularExpressions)库用来作为Javascript解释器中正则表达式功能的后端。PCRE是一个成熟的，久经考验的组件，它被使用在许多其他引人注目的开源项目中，这包括Python和Apache.数据持久化提供了三个等级，首先，一些高层数据如书签或历史由Konqueror自身来存储。第二，其他高层数据比如说表单自动完成数据被存储由KHTML。第三，安全数据比如说密码由KWallet来存储，KWallet还允许这些数据被其他的KDE应用程序所共享。

我们发现，Konqueror广泛使用了现有的库。相比之下，Mozilla自行开发了几乎所有这些库，只在必要时才委托给其他库。因此，Konqueror与类UNIX系统和QT紧密的捆绑在一起。而Mozilla支持多种不同操作系统和显示组件。然而，正如我们将在下一节中看到的，Apple能够通过移除对QT的依赖来适配Konqueror到它自己的需求上。


5 验证参考架构

另外5个被选中的浏览器实现用于验证参考架构：Epiphany, Safari, Lynx, Mosaic,还有Firefox。选中Epiphany的原因是它证明了开源组件的重用--它结合了Mozilla的引擎与GNOME桌面组件。选择Safari是因为它代表了开源与闭源技术的有趣结合--苹果已经适配Konqueror的核心子系统到OSX库并且添加了一个专有用户界面。选择Lynx是因为它是最老的仍被使用和维护的浏览器。选择Mosaic是因为它是第一个被广泛使用的图形化浏览器。选择Firefox是因为它那独特的扩展能力并且还因为他是Mozilla的近亲。

5.1 Epiphany

Epiphany是GNOME的官方浏览器，它嵌入了Mozilla的引擎。该项目始于2003年作为GaleonBrowser的一个独立的代码分支，这是由于用户界面设计决策的分歧。我们研究了1.4.6版本的源码，源代码约为7万行，不过它还需要大约150万行Mozilla引擎的代码来运转。除了Mozilla引擎的代码，所有Epiphany的代码使用C编写。




Epiphany的概念架构到参考架构的映射关系如图6所示。由于Epiphany重用了Mozilla的全部引擎，所以唯一不同的子系统是用户界面和数据持久化子系统。Epiphany的架构包含两个XML解析器：Expat内置在Mozilla引擎中用于解析Web内容（它的使用方式与XML解析子系统一致），Epiphany使用libxml2来序列化高层的应用数据（由于Expat解析器作为Mozilla的内部实现被隐藏，它不可能被Epiphany重用来实现此功能）。

另外一个Epiphany不能完全利用的组件是Mozilla的XUL抽象层，它使跨多个平台的一致用户界面成为可能。与此相反，Epiphany直接使用GTK+工具包，支持的XUL后端之一，除此之外还有几个GNOME库。这样做是为了实现与GNOME桌面环境的紧密集成。有趣的是这里提供了三种不同级别的数据持久化,GConf用来存储用户偏好设置，GConf存储了所有GNOME应用程序的偏好设置。高层数据如工具条，历史和书签被Epiphany自身以XML格式存储。底层数据如缓存，验证和cookies则通过Mozilla的profile机制来存储。

Epiphany的代码重用方式会影响对它进行维护的方式，Epiphany视Mozilla代码为一个黑盒-它被重用而无需任何修改，所有两者之间的通信都被放置在一小块定义良好的接口中。Epiphany的代码存储在针对于GNOME桌面的一个代码仓库中，Mozilla的代码被存储在另一个针对Mozilla产品的代码仓库中以方便它被其他所有Mozilla产品使用。这两个项目各自使用了独立的Bug跟踪系统和MailingList。这种方式避免了重复的工作量，只要相关接口没有改变，对Mozilla引擎进行的修改操作将直接被Epiphany获知。如果接口改变了，那么Epiphany的开发者就需要去调整Epiphany的代码来适配那些被改变了的接口。因此，对于Epiphany的每一个release而言，通常都会提供一个与这个release兼容的且稳定的Mozilla建议版本号。

5.2 Safari

Safari是苹果公司为它的MacOSX所开发的网络浏览器，第一个版本发布于2003年1月。Safari的主要设计目标是可用性，速度，标准化兼容以及与MacOSX的集成。Safari重用了KDE项目中的KHTML渲染引擎和KJS解释器。这两者被修改后的版本被称之为WebCore和JavaScriptCore,并且基于LGPL开源协议进行了发布。不过Safari中的其他代码则是私有的，包括用户界面。我们研究了WebCore和JavaScriptCore的125号release,它由11.4万行C++代码和2.2万行ObjectC++代码所组成，因为我们不能对私有部分进行抽取，它们的结构只能从Apple的开发文档中推断。



Safari的概念架构到参考架构的映射关系如图7所示。渲染引擎由KHTML核心引擎组成，KTHML核心引擎由KWQ适配器包装。KWQ由ObjectiveC++编写。这是出于将Safari集成到OS X的需要。网络功能由OSX的核心基础网络库来提供，用以代替KIO.对XML的解析功能由Expat XML解析器来提供，用以代替Qttoolkit所提供的XML解析器。显示后端子系统由两个互补的库组成：Carbon和Cocoa.Cocoa提供了一个用于常规显示工作的低级别C API，而Cocoa提供了一个高级别的Objective C API.数据持久化工作由内建在OSX中的三个独立的的系统级服务来提供，Preferences,Keychains和Caches，通过使用这些服务来达成与OSX应用程序的平滑整合。

总体来说，Safari的概念架构与我们的参考架构的匹配度良好。Safari重用了来自Konqueror的核心引擎，取而代之的是一个MacOS样式的，并且利用了其他的MacOSX原生组件和库来代替掉Konqueror中那些UNIX和KDE相关的组件。为了达成对于开发以及适配到OSX工作的完全控制，Apple也并行地维护着它自己的一个Konqueror引擎版本。这个决策的一个后果是：对于safari的bug修正和新特性的添加都必须被手动的传送给Konqueror（反之亦然），不这么做的话只能从头开始重写。由于这种初始的代码分流，Safari的引擎一直在以比Konqueror更快的速度开发出各种针对OSX的改动，这导致了两个代码库出现了分歧。无论如何，近日来对Safari的更新被Konqueror所重用，并帮助Konqueror通过了Acid2浏览器测试。另外，几个Konqueror中的新技术已经被移至到Safari,这包括可缩放矢量图形引擎（KSVG2），新的文档对象模型架构（KDOM），还有渲染树库（KCanvas）.

5.3 Lynx

Lynx是当今被使用的最流行的纯文本浏览器之一。它的出现早于WWW，起初被作为组织范围信息系统（organization-wideinformationsystem）的接口。定制超文本的能力随后被添加，再之后是支持Gopher协议。最终，对WWW的支持被嫁接了进来。这使得Lynx成为了一个真正的网络浏览器。这一递增的开发过程导致系统由一些小的代码片段组成，系统没有一致的整体结构。此外，大部分代码是底层代码，并且与平台所关联，这也增加了它的复杂性。


Lynx的概念架构到参考架构的映射关系如图8所示。W3C协议库（libwww）提供了多种多样的功能如对HTML解析和对HTTP与FTP两种协议的支持。libgnutls库提供了对安全协议的支持（此支持是可选的）。curses库用于在字符终端上对信息进行显示和导航。Lynx的概念架构展示了三个主要子系统之间的明确分离：浏览器核心，网络和显示后端。不过在用户界面，浏览器引擎，渲染引擎，和数据持久化这几个子系统之间却没有很明确的分离。这有可能是由于Lynx的天生的纯文本特性导致这些子系统并不复杂--呈现引擎以线性形式来输出网页而无需去将元素排版到一个恰当的坐标位置上，用户界面完全依靠键盘输入而不是使用按钮，小部件，和鼠标事件来处理。Lynx不包含JavaScript解释器或XML解析器，这是因为这些是相对现代化的特性，当前还未被支持。

模块化程度的不足以及Lynx的纯文本特性使它的概念架构比我们的参考架构要简单的多。自Lynx被开发时起，缺失的组件便引起了人们对于浏览器领域变化的注意。由于Web的分布式和开放特性，新的技术不断的被浏览器所采用以增强用户体验。由于浏览器支持的特定技术达到了一个临界值，作者们可能会开始使用网页中的一些技术。这使得一些浏览器很难跟上脚步，就如Lynx，它已经不如上面所提到的浏览器。不过，Lynx仍然能够满足浏览很多类型网站的需求，因此它仍然在一些用户之间流行着，尤其是哪些旧的电脑或者是缓慢的网络连接的情况下。

5.4 Mosaic

Mosaic是第一个被设计用于大众用户群体的图形浏览器。第一次发布是在1993年，它采用了许多的创新，如渲染穿插着文本和多媒体的图像的能力。它由NCSA的一个小程序员团队所开发。对于每一种操作系统（Windows,Mac,UNIX）都有各自相应的版本。不过也有一些通用代码在它们之间共享。Mosaic曾经超越了Netscape和IE，并在1997年正式停止开发。虽然UNIX版本的源码是公开可用的，不过它的许可协议并不是技术开源的。我们仍然可以获取它的源码并在当今的UNIX系统上编译它。我们研究了release2.7b6版本的源码，它的代码行数大约是8.8万行，并且完全使用C编写。



Mosaic的概念架构到参考架构的映射关系如图9所示。与Lynx一样，Mosaic太老了，不能够包含现代的子系统如Javascript解释器或XML解析器。引擎子系统由libhtmlw实现，它是一个用于显示文档数据的通用显示部件。尽管它执行着与现代渲染引擎相同的任务，不过它要小很多，这是因为早期网页的排版选项比起现代网页来说要简单的多。通用客户接口（CCI）是一个实验子系统，它允许外部应用程序通过TCP/IP与当前的Mosaic会话进行通信.使用CCI,一个客户端可以执行包含这GET和POST的HTTP活动，安排特定类型的渲染输出转发这个活动，或者注册以便每次Mosaic读取新URI时被通知。CCI与浏览器核心紧密的耦合，它是一个典型的不会出现在现代浏览器中的子系统。

Mosaic 重用了TimBerners-Lee的libwww库，尽管像Lynx做了大量修改。由Mosaic所做的大部分改动后来被纳入了库的原始版本。这种开放的源代码早期实例
浏览器之间的重用标志着浏览器进化的关键趋势的开始点。在现存的，成熟的代码上构建的意愿要大于尝试去从起跑线开发等价的功能。在当时，libwww是唯一可用于提供HTTP协议和HTTP解析功能的库，它的重用大幅度减少了用于开发新浏览器的工作量。

5.5 Firefox

Firefox是Mozilla的一个变体，它提供了一个精简的接口并且删除了许多集成的客户端（如Mozilla的mail,news和chat），我们研究了Firefox的1.0版本，它有大约240万行代码（它使用了Mozilla套件的大部分代码）。在大多数情况下Firefox的概念架构与Mozilla的类似，因此我们将不在这里展示它的参考架构映射图，然而，Firefox包含着一个不能在参考架构中找到的显著特性：强大的扩展设施。当标准的浏览器插件被用于显示浏览器不能直接显示的内容时，扩展能够挂入并在不同的架构级别上来改变浏览器。比如说，扩展可以改变用户界面元素（如工具条，按钮），捕获界面的事件（如鼠标点击），改变被显示的网页，并为额外的网络协议提供支持。

扩展会对软件的维护产生影响。每当一个Firefox的新版本发布，扩展与浏览器之间的接口通常会被修改。这意味着扩展是与特定版本的浏览器相关的，并且必须被频繁的更新来维护与新版本的兼容性。扩展通常由不同的工程师在不同的源码仓库中进行开发。这回导致重叠的功能，在一些情况下，冲突行为会出现在扩展中。最终，扩展能够潜在的创建Firefox的安全漏洞。比如说，Greasemonkey扩展使用户添加脚本到任何网页来改变它的行为，一些早期版本包含一个安全漏洞，这个漏洞允许恶意网站去读取用户硬盘上的任何文件。幸运的是，扩展的开发者们能够快速的发布一个临时的解决方案。不过情况并非如此，Firefox的开发者们可能会利用Greasemonkey是开源软件这一特点来创建他们自己持有的安全补丁。

6 观察结果

我们的浏览器参考架构确定了现代浏览器实现中的关键子系统和这些子系统之间的关系。除了作为维护和重设计的指导，它还用于各种浏览器实现的对比，无论是过去的还是当今的。我们已经使用五个额外的开源浏览器来验证了参考架构并且检验了结果。虽然有几个原因导致它们的架构不同于我们的参考架构，不过整体而言，我们发现这些实现与我们的参考架构对应的相当紧密。一些参考架构中的子系统可能会为了简化的需要而被组合为一个单一系统，而另外一些子系统则有可能为了更好的灵活性而被分离并贯穿于多个子系统之间。新的子系统也可能被添加来提供额外的能力，而其他子系统则可能被移除掉来让浏览器变的更轻量。

表1展示了各种被研究的浏览器的统计数据，Konqueror实现了与Mizilla相同围度的功能却只用了相对于Mozilla总量1/4左右数量的代码。对于Lynx,尽管它小于其他浏览器，但仍然比Links大五倍，最新的使用可被比较的特性的纯文本浏览器。我们无法获取Safari完整的大小信息,这是因为它有闭源组件，数字只显示了对应的开源部分信息。



Epiphany和Safari由一些可用于所有其他项目的资源驱动，这示范了不同的代码重用和维护方式。Epiphany由一个小的工程师团队利用业余的时间来作为志愿者进行开发，以黑盒方式来重用Mozilla引擎使Epiphany可以利用一大批Mozilla的工程师的成果，这些工程师中的一部分是全职工作于Mozilla之上的。Safari则拥有它们自己的全职工程师团队。以白盒方式来重用Konqueror引擎使Apple可以裁剪浏览器来满足它们自己的需求，与此同时还从Konqueror中手动获取任何所需要的重要改动。与此相反，Konqueror偶尔能够获和应用取来自Apple对它自己的引擎的修改。

最近一段时间手机浏览器的到来代表着浏览器进化历史上的一次颠覆性改变。此前，手机仅支持单色的，纯文本的屏幕以及极少数量的内存，对于网络浏览来说这种平台的功能是有限的。无线服务提供商使用创建WAP（WirelessApplicationProtocol）网关的方式,这种网关将HTML转换为简化标记,这种简化标记最终以一次一页的方式显示出来。无论如何，随着电话的显示和接口变得更加强大，电话浏览器开始像常规浏览器那样直接呈现HTML页。当前，许多手机都拥有高分辨率的彩色显示器和更多数量的内存，这允许它们去运行一些桌面浏览器的简化版本，不过通常UI被调整以适用与小尺寸屏幕和有限的输入法。Opera已经发布了一个它们浏览器的一个移动版本，这个版本包含了许多桌面浏览器的传统特性，比如说书签和密码管理，Nokia也已经在S60OS上发布了一个基于WebCore的浏览器，它能够显示所有被浏览的网页的缩略图并且允许用户去放大或缩小他们感兴趣了一部分页面区域。

7 相关工作

逆向工程技术已经被用于获得各种系统的架构文档，如Linux内核。Mozilla体系结构和开发过程中的不同层面也已经被研究。

参考架构已经在别的领域中被提出，这包括实时列车控制系统，航空电子设备，以及Web服务器。产品线架构类似于参考架构，不过它们通常表示一组被单一组织生产的系统，而参考架构代表了一个领域中的系统的整个范围。

Larrondo-Petrie等人使用了面向对象的领域分析来创建一个领域模型，对象模型，以及特征树（featuretree）,这个树描述了网络浏览器所提供的常见结构和功能。然而，它们并不使用浏览器源码来抽取实体架构来完善它们它们的模型。Chuang等人指导了一项Konqueror的定量能源分析研究，以检验它们提出的分析方案的可行性。

8 结论

我们探讨了浏览器领域的历史和演变，基于2个现有的实现开发了一个参考架构，并且通过映射这个参考架构到另外5个额外的实现来验证了这个参考架构。我们还分析了各个浏览器所使用的代码重用策略对维护所产生的影响。我们还观察到了浏览器领域中的几个有趣的进化现象，即倏忽（emergent）领域边界，趋同进化，以及开源和闭源两种方式之间的伸缩性。

鉴于浏览器领域的演变，它的概念边界——内部和外部的，被逐步的定义完善。不过由于这些边界的一些自然特性，仍然会产生一些差异。微软已经声明将IE作为一个windiws的一个基础部分，为其它的应用程序来提供呈现功能。这提出了一个问题：第三方浏览器像是Netscape去寻求途径与IE竞争的问题。类似的，邮件,新闻,以及聊天的客户端被集成到了Netscape和Mozilla浏览器中，以阻止来自其他客户端的竞争。观察浏览器领域如何去适配支持嵌入式设备（如电话和PDA）是一件有意思的事情，在这些设备上有限的内存使其不适宜部署多个应用。

致力于创建高品质开源浏览器实现的大量努力已经在这个领域产生了深远的影响。在“浏览器大战“期间，专有的扩展被添加到了核心组件以吸引客户。今天，日益增加的遵循标准的压力导致了全面的核心组件重用。各个浏览器主要是通过用户级别的特性来区分的。然而，这些功能往往容易被互相复制，例如选项卡式的浏览和弹出窗口阻止功能曾是创新特性，不过现在它们已经是平常事物了。这些观察表明，浏览器领域表现为趋同进化的形式（Futuyma，1998年，第110-111，120-121）（即物种独立发展成为类似的形态，这是由于类似的环境压力）

成熟的浏览器组件的可用性也导致了开源与闭源开发方法之间的伸缩性。Mozilla的开源引擎已经在众多的应用程序中重用，这些应用程序中有开源的也有闭源的。同样，Konqueror的开源引擎已经被用来作为Appled的Sarfari和S60浏览器的基础。按照许可协议的条款，这两家公司贡献了它们各自的更改来回报社会。与此相反，IE代表了一个闭源引擎，这个引擎可以被隐式的嵌入到其他开源产品中。Netscape8通过嵌入IE和Mozilla引擎去冲击了这种平衡，用户可以在运行时选择需要的引擎。我们在之前已经看到应用程序由开源和闭源两种组件组成，在闭源二进制模块的情况下，交互通常发生在外围。我们认为在一个独立系统中，核心开源和闭源的软件组件的多样化组合使浏览器领域在软件维护和进化方面有别于其他软件。

8 参考