前端必读：浏览器内部工作原理

前端必读：浏览器内部工作原理

目录

一、介绍

二、渲染引擎

三、解析与DOM树构建

四、渲染树构建

五、布局

六、绘制

七、动态变化

八、渲染引擎的线程

九、CSS2可视模型

英文原文：How Browsers Work: Behind the Scenes of Modern Web Browsers

一、介绍

浏览器可以被认为是使用最广泛的软件，本文将介绍浏览器的工作原理，我们将看到，从你在地址栏输入https://www.wendangku.net/doc/314906147.html,到你看到google主页过程中都发生了什么。

将讨论的浏览器

今天，有五种主流浏览器——IE、Firefox、Safari、Chrome及Opera。

本文将基于一些开源浏览器的例子——Firefox、Chrome及Safari，Safari是部分开源的。

根据W3C（World Wide Web Consortium万维网联盟）的浏览器统计数据，当前（2011年5月），Firefox、Safari及Chrome的市场占有率综合已接近60％。（原文为2009年10月，数据没有太大变化）因此，可以说开源浏览器已经占据了浏览器市场的半壁江山。

浏览器的主要功能

浏览器的主要功能是将用户选择的web资源呈现出来，它需要从服务器请求资源，并将其显示在浏览器窗口中，资源的格式通常是HTML，也包括PDF、image及其他格式。用户用URI（Uniform Resource Identifier统一资源标识符）来指定所请求资源的位置，在网络一章有更多讨论。

HTML和CSS规范中规定了浏览器解释html文档的方式，由W3C组织对这些规范进行维护，W3C是负责制定web标准的组织。

HTML规范的最新版本是HTML4(https://www.wendangku.net/doc/314906147.html,/TR/html401/)，HTML5还在制定中（译注：两年前），最新的CSS规范版本是2（https://www.wendangku.net/doc/314906147.html,/TR/CSS2），CSS3也还正在制定中（译注：同样两年前）。

这些年来，浏览器厂商纷纷开发自己的扩展，对规范的遵循并不完善，这为web开发者带来了严重的兼容性问题。

但是，浏览器的用户界面则差不多，常见的用户界面元素包括：

?用来输入URI的地址栏

?前进、后退按钮

?书签选项

?用于刷新及暂停当前加载文档的刷新、暂停按钮

?用于到达主页的主页按钮

奇怪的是，并没有哪个正式公布的规范对用户界面做出规定，这些是多年来各浏览器厂商之间相互模仿和不断改进的结果。

HTML5并没有规定浏览器必须具有的UI元素，但列出了一些常用元素，包括地址栏、状态栏及工具栏。还有一些浏览器有自己专有的功能，比如Firefox的下载管理。更多相关内容将在后面讨论用户界面时介绍。

浏览器的主要构成（High Level Structure）

浏览器的主要组件包括：

1. 用户界面－包括地址栏、后退/前进按钮、书签目录等，也就是你所看到的除了用来显示你所请求页面的主窗口之外的其他部分。

2. 浏览器引擎－用来查询及操作渲染引擎的接口。

3. 渲染引擎－用来显示请求的内容，例如，如果请求内容为html，它负责解析html及css，并将解析后的结果显示出来。

4. 网络－用来完成网络调用，例如http请求，它具有平台无关的接口，可以在不同平台上工作。

5. UI后端－用来绘制类似组合选择框及对话框等基本组件，具有不特定于某个平台的通用接口，底层使用操作系统的用户接口。

6. JS解释器－用来解释执行JS代码。

7. 数据存储－属于持久层，浏览器需要在硬盘中保存类似cookie的各种数据，HTML5定义了web database技术，这是一种轻量级完整的客户端存储技术

图1：浏览器主要组件

需要注意的是，不同于大部分浏览器，Chrome为每个Tab分配了各自的渲染引擎实例，每个Tab就是一个独立的进程。

对于构成浏览器的这些组件，后面会逐一详细讨论。

二、渲染引擎（The rendering engine）

渲染引擎的职责就是渲染，即在浏览器窗口中显示所请求的内容。

默认情况下，渲染引擎可以显示html、xml文档及图片，它也可以借助插件（一种浏览器扩展）显示其他类型数据，例如使用PDF阅读器插件，可以显示PDF格式，将由专门一章讲解插件及扩展，这里只讨论渲染引擎最主要的用途——显示应用了CSS之后的html及图片。

渲染引擎简介

本文所讨论的浏览器——Firefox、Chrome和Safari是基于两种渲染引擎构建的，Firefox使用Geoko——Mozilla自主研发的渲染引擎，Safari和Chrome都使用webkit。

Webkit是一款开源渲染引擎，它本来是为Linux平台研发的，后来由Apple移植到Mac及Windows上，相关内容请参考https://www.wendangku.net/doc/314906147.html,。

渲染主流程（The main flow）

渲染引擎首先通过网络获得所请求文档的内容，通常以8K分块的方式完成。

下面是渲染引擎在取得内容之后的基本流程：

解析html以构建dom树-> 构建render树-> 布局render树-> 绘制render树

图2：渲染引擎基本流程

渲染引擎开始解析html，并将标签转化为内容树中的dom节点。接着，它解析外部CSS文件及style标签中的样式信息。这些样式信息以及html中的可见性指令将被用来构建另一棵树——render树。

Render树由一些包含有颜色和大小等属性的矩形组成，它们将被按照正确的顺序显示到屏幕上。

Render树构建好了之后，将会执行布局过程，它将确定每个节点在屏幕上的确切坐标。再下一步就是绘制，即遍历render树，并使用UI后端层绘制每个节点。

值得注意的是，这个过程是逐步完成的，为了更好的用户体验，渲染引擎将会尽可能早的将内容呈现到屏幕上，并不会等到所有的html都解析完成之后再去构建和布局render树。它是解析完一部分内容就显示一部分内容，同时，可能还在通过网络下载其余内容。

图3：webkit主流程

图4：Mozilla的Geoko渲染引擎主流程

从图3和4中可以看出，尽管webkit和Gecko使用的术语稍有不同，他们的主要流程基本相同。Gecko称可见的格式化元素组成的树为frame树，每个元素都是一个frame，webkit则使用render树这个名词来命名由渲染对象组成的树。Webkit中元素的定位称为布局，而Gecko中称为回流。Webkit称利用dom节点及样式信息去构建render树的过程为attachment，Gecko在html和dom树之间附加了一层，这层称为内容接收器，相当制造dom元素的工厂。下面将讨论流程中的各个阶段。

三、解析与DOM树构建（Parsing and DOM tree construction）

解析（Parsing－general）

既然解析是渲染引擎中一个非常重要的过程，我们将稍微深入的研究它。首先简要介绍一下解析。

解析一个文档即将其转换为具有一定意义的结构——编码可以理解和使用的东西。解析的结果通常是表达文档结构的节点树，称为解析树或语法树。

例如，解析“2＋3－1”这个表达式，可能返回这样一棵树。

图5：数学表达式树节点

文法（Grammars）

解析基于文档依据的语法规则——文档的语言或格式。每种可被解析的格式必须具有由词汇及语法规则组成的特定的文法，称为上下文无关文法。人类语言不具有这一特性，因此不能被一般的解析技术所解析。

解析器－词法分析器（Parser－Lexer combination）

解析可以分为两个子过程——语法分析及词法分析

词法分析就是将输入分解为符号，符号是语言的词汇表——基本有效单元的集合。对于人类语言来说，它相当于我们字典中出现的所有单词。

语法分析指对语言应用语法规则。

解析器一般将工作分配给两个组件——词法分析器（有时也叫分词器）负责将输入分解为合法的符号，解析器则根据语言的语法规则分析文档结构，从而构建解析树，词法分析器知道怎么跳过空白和换行之类的无关字符。

图6：从源文档到解析树

解析过程是迭代的，解析器从词法分析器处取到一个新的符号，并试着用这个符号匹配一条语法规则，如果匹配了一条规则，这个符号对应的节点将被添加到解析树上，然后解析器请求另一个符号。如果没有匹配到规则，解析器将在内部保存该符号，并从词法分析器取下一个符号，直到所有内部保存的符号能够匹配一项语法规则。如果最终没有找到匹配的规则，解析器将抛出一个异常，这意味着文档无效或是包含语法错误。

转换（Translation）

很多时候，解析树并不是最终结果。解析一般在转换中使用——将输入文档转换为另一种格式。编译就是个例子，编译器在将一段源码编译为机器码的时候，先将源码解析为解析树，然后将该树转换为一个机器码文档。

图7：编译流程

解析实例Parsing example

图5中，我们从一个数学表达式构建了一个解析树，这里定义一个简单的数学语言来看下解析过程。

词汇表：我们的语言包括整数、加号及减号。

语法：

自底向上解析器称为shift reduce解析器，因为输入向右移动（想象一个指针首先指向输入开始处，并向右移动），并逐渐简化为语法规则。

自动化解析（Generating parsers automatically）

解析器生成器这个工具可以自动生成解析器，只需要指定语言的文法——词汇表及语法规则，它就可以生成一个解析器。创建一个解析器需要对解析有深入的理解，而且手动的创建一个由较好性能的解析器并不容易，所以解析生成器很有用。Webkit使用两个知名的解析生成器——用于创建语法分析器的Flex及创建解析器的Bison（你可能接触过Lex和Yacc）。Flex的输入是一个包含了符号定义的正则表达式，Bison的输入是用BNF格式表示的语法规则。

HTML解析器（HTML Parser）

HTML解析器的工作是将html标识解析为解析树。

HTML文法定义（The HTML grammar definition）

W3C组织制定规范定义了HTML的词汇表和语法。

非上下文无关文法（Not a context free grammar）

正如在解析简介中提到的，上下文无关文法的语法可以用类似BNF的格式来定义。

不幸的是，所有的传统解析方式都不适用于html（当然我提出它们并不只是因为好玩，它们将用来解析css 和js），html不能简单的用解析所需的上下文无关文法来定义。

Html有一个正式的格式定义——DTD（Document Type Definition文档类型定义）——但它并不是上下文无关文法，html更接近于xml，现在有很多可用的xml解析器，html有个xml的变体——xhtml，它们间的不同在于，html更宽容，它允许忽略一些特定标签，有时可以省略开始或结束标签。总的来说，它是一种soft语法，不像xml呆板、固执。

显然，这个看起来很小的差异却带来了很大的不同。一方面，这是html流行的原因——它的宽容使web开发人员的工作更加轻松，但另一方面，这也使很难去写一个格式化的文法。所以，html的解析并不简单，它既不能用传统的解析器解析，也不能用xml解析器解析。

HTML DTD

Html适用DTD格式进行定义，这一格式是用于定义SGML家族的语言，包括了对所有允许元素及它们的属性和层次关系的定义。正如前面提到的，html DTD并没有生成一种上下文无关文法。

DTD有一些变种，标准模式只遵守规范，而其他模式则包含了对浏览器过去所使用标签的支持，这么做是为了兼容以前内容。最新的标准DTD在https://www.wendangku.net/doc/314906147.html,/TR/html4/strict.dtd

DOM

输出的树，也就是解析树，是由DOM元素及属性节点组成的。DOM是文档对象模型的缩写，它是html文档的对象表示，作为html元素的外部接口供js等调用。

树的根是“document”对象。

DOM和标签基本是一一对应的关系，例如，如下的标签：

Hello DOM

将会被转换为下面的DOM树：

图8：示例标签对应的DOM树

和html一样，DOM的规范也是由W3C组织制定的。访问https://www.wendangku.net/doc/314906147.html,/DOM/DOMTR，这是使用文档的一般规范。一个模型描述一种特定的html元素，可以在

https://www.wendangku.net/doc/314906147.html,/TR/2003/REC-DOM-Level-2-HTML-20030109/idl-definitions.htm查看html定义。

这里所谓的树包含了DOM节点是说树是由实现了DOM接口的元素构建而成的，浏览器使用已被浏览器内部使用的其他属性的具体实现。

解析算法（The parsing algorithm）

正如前面章节中讨论的，hmtl不能被一般的自顶向下或自底向上的解析器所解析。

原因是：

1. 这门语言本身的宽容特性

2. 浏览器对一些常见的非法html有容错机制

3. 解析过程是往复的，通常源码不会在解析过程中发生改变，但在html中，脚本标签包含的“document.write”可能添加标签，这说明在解析过程中实际上修改了输入。

不能使用正则解析技术，浏览器为html定制了专属的解析器。

Html5规范中描述了这个解析算法，算法包括两个阶段——符号化及构建树。

符号化是词法分析的过程，将输入解析为符号，html的符号包括开始标签、结束标签、属性名及属性值。

符号识别器识别出符号后，将其传递给树构建器，并读取下一个字符，以识别下一个符号，这样直到处理完所有输入。

图9：HTML解析流程

符号识别算法（The tokenization algorithm）

算法输出html符号，该算法用状态机表示。每次读取输入流中的一个或多个字符，并根据这些字符转移到下一个状态，当前的符号状态及构建树状态共同影响结果，这意味着，读取同样的字符，可能因为当前状态的不同，得到不同的结果以进入下一个正确的状态。

这个算法很复杂，这里用一个简单的例子来解释这个原理。

基本示例——符号化下面的html：

Hello world

初始状态为“Data State”，当遇到“<”字符，状态变为“Tag open state”，读取一个a－z的字符将产生一个开始标签符号，状态相应变为“Tag name state”，一直保持这个状态直到读取到“>”，每个字符都附加到这个符号名上，例子中创建的是一个html符号。

当读取到“>”，当前的符号就完成了，此时，状态回到“Data state”，“”重复这一处理过程。到这里，html和body标签都识别出来了。现在，回到“Data state”，读取“Hello world”中的字符“H”将创建并识别出一个字符符号，这里会为“Hello world”中的每个字符生成一个字符符号。

这样直到遇到“”中的“<”。现在，又回到了“Tag open state”，读取下一个字符“/”将创建一个闭合标签符号，并且状态转移到“Tag name state”，还是保持这一状态，直到遇到“>”。然后，产生一个新的标签符号并回到“Data state”。后面的“”将和“”一样处理。

图10：符号化示例输入

树的构建算法（Tree construction algorithm）

在树的构建阶段，将修改以Document为根的DOM树，将元素附加到树上。每个由符号识别器识别生成的节点将会被树构造器进行处理，规范中定义了每个符号相对应的Dom元素，对应的Dom元素将会被创建。这些元素除了会被添加到Dom树上，还将被添加到开放元素堆栈中。这个堆栈用来纠正嵌套的未匹配和未闭合标签，这个算法也是用状态机来描述，所有的状态采用插入模式。

来看一下示例中树的创建过程：

Hello world

构建树这一阶段的输入是符号识别阶段生成的符号序列。

首先是“initial mode”，接收到html符号后将转换为“before html”模式，在这个模式中对这个符号进行再处理。此时，创建了一个HTMLHtmlElement元素，并将其附加到根Document对象上。

状态此时变为“before head”，接收到body符号时，即使这里没有head符号，也将自动创建一个HTMLHeadElement元素并附加到树上。

现在，转到“in head”模式，然后是“after head”。到这里，body符号会被再次处理，将创建一个HTMLBodyElement并插入到树中，同时，转移到“in body”模式。

然后，接收到字符串“Hello world”的字符符号，第一个字符将导致创建并插入一个text节点，其他字符将附加到该节点。

接收到body结束符号时，转移到“after body”模式，接着接收到html结束符号，这个符号意味着转移到了“after after body”模式，当接收到文件结束符时，整个解析过程结束。

图11：示例html树的构建过程

解析结束时的处理（Action when the parsing is finished）

在这个阶段，浏览器将文档标记为可交互的，并开始解析处于延时模式中的脚本——这些脚本在文档解析后执行。

文档状态将被设置为完成，同时触发一个load事件。

Html5规范中有符号化及构建树的完整算法(https://www.wendangku.net/doc/314906147.html,/TR/html5/syntax.html#html-parser)。

浏览器容错（Browsers error tolerance）

你从来不会在一个html页面上看到“无效语法”这样的错误，浏览器修复了无效内容并继续工作。

以下面这段html为例：

Really lousy HTML

这段html违反了很多规则（mytag不是合法的标签，p及div错误的嵌套等等），但是浏览器仍然可以没有任何怨言的继续显示，它在解析的过程中修复了html作者的错误。

浏览器都具有错误处理的能力，但是，另人惊讶的是，这并不是html最新规范的内容，就像书签及前进后退按钮一样，它只是浏览器长期发展的结果。一些比较知名的非法html结构，在许多站点中出现过，浏览器都试着以一种和其他浏览器一致的方式去修复。

Html5规范定义了这方面的需求，webkit在html解析类开始部分的注释中做了很好的总结。

解析器将符号化的输入解析为文档并创建文档，但不幸的是，我们必须处理很多没有很好格式化的html文档，至少要小心下面几种错误情况。

1. 在未闭合的标签中添加明确禁止的元素。这种情况下，应该先将前一标签闭合

2. 不能直接添加元素。有些人在写文档的时候会忘了中间一些标签（或者中间标签是可选的），比如HTML HEAD BODY TR TD LI等

3. 想在一个行内元素中添加块状元素。关闭所有的行内元素，直到下一个更高的块状元素

4. 如果这些都不行，就闭合当前标签直到可以添加该元素。

下面来看一些webkit容错的例子：

替代

一些网站使用
替代
，为了兼容IE和Firefox，webkit将其看作
。

代码：

if (t->isCloseTag(brTag) && m_document->inCompatMode()) {

reportError(MalformedBRError);

t->beginTag = true;

}

Note －这里的错误处理在内部进行，用户看不到。

迷路的表格

这指一个表格嵌套在另一个表格中，但不在它的某个单元格内。

比如下面这个例子：

outer table

webkit将会将嵌套的表格变为两个兄弟表格：

代码：

if (m_inStrayTableContent && localName == tableTag)

popBlock(tableTag);

webkit使用堆栈存放当前的元素内容，它将从外部表格的堆栈中弹出内部的表格，则它们变为了兄弟表格。

嵌套的表单元素

用户将一个表单嵌套到另一个表单中，则第二个表单将被忽略。

代码：

if (!m_currentFormElement) {

m_currentFormElement = new HTMLFormElement(formTag,m_document);

}

太深的标签继承

https://www.wendangku.net/doc/314906147.html,.mx是一个由嵌套层次的站点的例子，最多只允许20个相同类型的标签嵌套，多出来的将被忽略。

代码：

bool HTMLParser::allowNestedRedundantTag(const AtomicString& tagName)

{

unsigned i = 0;

for (HTMLStackElem* curr = m_blockStack;

i < cMaxRedundantTagDepth && curr && curr->tagName == tagName;

curr = curr->next, i++) { }

return i != cMaxRedundantTagDepth;

}

放错了地方的html、body闭合标签

又一次不言自明。

支持不完整的html。我们从来不闭合body，因为一些愚蠢的网页总是在还未真正结束时就闭合它。我们依赖调用end方法去执行关闭的处理。

代码：

if (t->tagName == htmlTag || t->tagName == bodyTag )

return;

所以，web开发者要小心了，除非你想成为webkit容错代码的范例，否则还是写格式良好的html吧。

CSS解析（CSS parsing）

还记得简介中提到的解析的概念吗，不同于html，css属于上下文无关文法，可以用前面所描述的解析器来解析。Css规范定义了css的词法及语法文法。

看一些例子：

每个符号都由正则表达式定义了词法文法（词汇表）：

comment///*[^*]*/*+([^/*][^*]*/*+)*//

num[0-9]+|[0-9]*"."[0-9]+

nonascii[/200-/377]

nmstart[_a-z]|{nonascii}|{escape}

nmchar[_a-z0-9-]|{nonascii}|{escape}

name{nmchar}+

ident{nmstart}{nmchar}*

“ident”是识别器的缩写，相当于一个class名，“name”是一个元素id（用“＃”引用）。

语法用BNF进行描述：

ruleset

: selector [ ',' S* selector ]*

'{' S* declaration [ ';' S* declaration ]* '}' S*

;

selector

: simple_selector [ combinator selector | S+ [ combinator selector ] ]

;

simple_selector

: element_name [ HASH | class | attrib | pseudo ]*

| [ HASH | class | attrib | pseudo ]+

;

class

: '.' IDENT

;

element_name

: IDENT | '*'

;

attrib

: '[' S* IDENT S* [ [ '=' | INCLUDES | DASHMATCH ] S*

[ IDENT | STRING ] S* ] ']'

;

pseudo

: ':' [ IDENT | FUNCTION S* [IDENT S*] ')' ]

;

说明：一个规则集合有这样的结构

div.error , a.error {

color:red;

font-weight:bold;

}

div.error和a.error时选择器，大括号中的内容包含了这条规则集合中的规则，这个结构在下面的定义中正式的定义了：ruleset

: selector [ ',' S* selector ]*

'{' S* declaration [ ';' S* declaration ]* '}' S*

;

这说明，一个规则集合具有一个或是可选个数的多个选择器，这些选择器以逗号和空格（S表示空格）进行分隔。每个规则集合包含大括号及大括号中的一条或多条以分号隔开的声明。声明和选择器在后面进行定义。

Webkit CSS解析器（Webkit CSS parser）

Webkit使用Flex和Bison解析生成器从CSS语法文件中自动生成解析器。回忆一下解析器的介绍，Bison 创建一个自底向上的解析器，Firefox使用自顶向下解析器。它们都是将每个css文件解析为样式表对象，每个对象包含css规则，css规则对象包含选择器和声明对象，以及其他一些符合css语法的对象。

图12：解析css

处理脚本及样式表的顺序（The order of processing scripts and style sheets）

脚本

web的模式是同步的，开发者希望解析到一个script标签时立即解析执行脚本，并阻塞文档的解析直到脚本执行完。如果脚本是外引的，则网络必须先请求到这个资源——这个过程也是同步的，会阻塞文档的解析直到资源被请求到。这个模式保持了很多年，并且在html4及html5中都特别指定了。开发者可以将脚本标识为defer，以使其不阻塞文档解析，并在文档解析结束后执行。Html5增加了标记脚本为异步的选项，以使脚本的解析执行使用另一个线程。

预解析（Speculative parsing）

Webkit和Firefox都做了这个优化，当执行脚本时，另一个线程解析剩下的文档，并加载后面需要通过网络加载的资源。这种方式可以使资源并行加载从而使整体速度更快。需要注意的是，预解析并不改变Dom树，它将这个工作留给主解析过程，自己只解析外部资源的引用，比如外部脚本、样式表及图片。

样式表（Style sheets）

样式表采用另一种不同的模式。理论上，既然样式表不改变Dom树，也就没有必要停下文档的解析等待它们，然而，存在一个问题，脚本可能在文档的解析过程中请求样式信息，如果样式还没有加载和解析，脚本将得到错误的值，显然这将会导致很多问题，这看起来是个边缘情况，但确实很常见。Firefox在存在样式表还在加载和解析时阻塞所有的脚本，而Chrome只在当脚本试图访问某些可能被未加载的样式表所影响的特定的样式属性时才阻塞这些脚本。

四、渲染树构建（Render tree construction）

当Dom树构建完成时，浏览器开始构建另一棵树——渲染树。渲染树由元素显示序列中的可见元素组成，它是文档的可视化表示，构建这棵树是为了以正确的顺序绘制文档内容。

Firefox将渲染树中的元素称为frames，WebKit则用renderer或渲染对象来描述这些元素。

一个渲染对象知道怎么布局及绘制自己及它的children。

RenderObject是Webkit的渲染对象基类，它的定义如下：

class RenderObject{

virtual void layout();

virtual void paint(PaintInfo);

virtual void rect repaintRect();

Node* node;//the DOM node

RenderStyle* style;// the computed style

RenderLayer* containgLayer; //the containing z-index layer

}

每个渲染对象用一个和该节点的css盒模型相对应的矩形区域来表示，正如css2所描述的那样，它包含诸如宽、高和位置之类的几何信息。盒模型的类型受该节点相关的display样式属性的影响（参考样式计算章节）。下面的webkit代码说明了如何根据display属性决定某个节点创建何种类型的渲染对象。

RenderObject* RenderObject::createObject(Node* node, RenderStyle* style)

{

Document* doc = node->document();

RenderArena* arena = doc->renderArena();

...

RenderObject* o = 0;

switch (style->display()) {

case NONE:

break;

case INLINE:

o = new (arena) RenderInline(node);

break;

case BLOCK:

o = new (arena) RenderBlock(node);

break;

case INLINE_BLOCK:

o = new (arena) RenderBlock(node);

break;

case LIST_ITEM:

o = new (arena) RenderListItem(node);

break;

...

}

return o;

}

元素的类型也需要考虑，例如，表单控件和表格带有特殊的框架。

在Webkit中，如果一个元素想创建一个特殊的渲染对象，它需要重写“createRenderer”方法，使渲染对象指向不包含几何信息的样式对象。

渲染树和Dom树的关系（The render tree relation to the DOM tree）

渲染对象和Dom元素相对应，但这种对应关系不是一对一的，不可见的Dom元素不会被插入渲染树，例如head元素。另外，display属性为none的元素也不会在渲染树中出现（visibility属性为hidden的元素将出现在渲染树中）。

还有一些Dom元素对应几个可见对象，它们一般是一些具有复杂结构的元素，无法用一个矩形来描述。例如，select元素有三个渲染对象——一个显示区域、一个下拉列表及一个按钮。同样，当文本因为宽度不够而折行时，新行将作为额外的渲染元素被添加。另一个多个渲染对象的例子是不规范的html，根据css规范，一个行内元素只能仅包含行内元素或仅包含块状元素，在存在混合内容时，将会创建匿名的块状渲染对象包裹住行内元素。

一些渲染对象和所对应的Dom节点不在树上相同的位置，例如，浮动和绝对定位的元素在文本流之外，在两棵树上的位置不同，渲染树上标识出真实的结构，并用一个占位结构标识出它们原来的位置。

图13：渲染树及对应的Dom树

创建树的流程（The flow of constructing the tree）

Firefox中，表述为一个监听Dom更新的监听器，将frame的创建委派给Frame Constructor，这个构建器计算样式（参看样式计算）并创建一个frame。

Webkit中，计算样式并生成渲染对象的过程称为attachment，每个Dom节点有一个attach方法，attachment的过程是同步的，调用新节点的attach方法将节点插入到Dom树中。

处理html和body标签将构建渲染树的根，这个根渲染对象对应被css规范称为containing block的元素——包含了其他所有块元素的顶级块元素。它的大小就是viewport——浏览器窗口的显示区域，Firefox称它为viewPortFrame，webkit称为RenderView，这个就是文档所指向的渲染对象，树中其他的部分都将作为一个插入的Dom节点被创建。

样式计算（Style Computation）

创建渲染树需要计算出每个渲染对象的可视属性，这可以通过计算每个元素的样式属性得到。

样式包括各种来源的样式表，行内样式元素及html中的可视化属性（例如bgcolor），可视化属性转化为css 样式属性。

样式表来源于浏览器默认样式表，及页面作者和用户提供的样式表——有些样式是浏览器用户提供的（浏览器允许用户定义喜欢的样式，例如，在Firefox中，可以通过在Firefox Profile目录下放置样式表实现）。

计算样式的一些困难：

1. 样式数据是非常大的结构，保存大量的样式属性会带来内存问题。

2. 如果不进行优化，找到每个元素匹配的规则会导致性能问题，为每个元素查找匹配的规则都需要遍历整个规则表，这个过程有很大的工作量。选择符可能有复杂的结构，匹配过程如果沿着一条开始看似正确，后来却被证明是无用的路径，则必须去尝试另一条路径。

例如，下面这个复杂选择符

div div div div｛…｝

这意味着规则应用到三个div的后代div元素，选择树上一条特定的路径去检查，这可能需要遍历节点树，最后却发现它只是两个div的后代，并不使用该规则，然后则需要沿着另一条路径去尝试

3. 应用规则涉及非常复杂的级联，它们定义了规则的层次

我们来看一下浏览器如何处理这些问题：

共享样式数据（Sharing style data）

WebkKit节点引用样式对象（渲染样式），某些情况下，这些对象可以被节点间共享，这些节点需要是兄弟或是表兄弟节点，并且：

1. 这些元素必须处于相同的鼠标状态（比如不能一个处于hover，而另一个不是）

2. 不能有元素具有id

3. 标签名必须匹配

4. class属性必须匹配

5. 对应的属性必须相同

6. 链接状态必须匹配

7. 焦点状态必须匹配

8. 不能有元素被属性选择器影响

9. 元素不能有行内样式属性

10. 不能有生效的兄弟选择器，webcore在任何兄弟选择器相遇时只是简单的抛出一个全局转换，并且在它们显示时使整个文档的样式共享失效，这些包括＋选择器和类似:first-child和:last-child这样的选择器。

Firefox规则树（Firefox rule tree）

Firefox用两个树用来简化样式计算－规则树和样式上下文树，WebKit也有样式对象，但它们并没有存储在类似样式上下文树这样的树中，只是由Dom节点指向其相关的样式。

图14：Firefox样式上下文树

样式上下文包含最终值，这些值是通过以正确顺序应用所有匹配的规则，并将它们由逻辑值转换为具体的值，例如，如果逻辑值为屏幕的百分比，则通过计算将其转化为绝对单位。样式树的使用确实很巧妙，它使得在节点中共享的这些值不需要被多次计算，同时也节省了存储空间。

所有匹配的规则都存储在规则树中，一条路径中的底层节点拥有最高的优先级，这棵树包含了所找到的所有规则匹配的路径（译注：可以取巧理解为每条路径对应一个节点，路径上包含了该节点所匹配的所有规则）。规则树并不是一开始就为所有节点进行计算，而是在某个节点需要计算样式时，才进行相应的计算并将计算后的路径添加到树中。

我们将树上的路径看成辞典中的单词，假如已经计算出了如下的规则树：

假如需要为内容树中的另一个节点匹配规则，现在知道匹配的规则（以正确的顺序）为B-E-I，因为我们已经计算出了路径A-B-E-I-L，所以树上已经存在了这条路径，剩下的工作就很少了。

现在来看一下树如何保存。

结构化

样式上下文按结构划分，这些结构包括类似border或color这样的特定分类的样式信息。一个结构中的所有特性不是继承的就是非继承的，对继承的特性，除非元素自身有定义，否则就从它的parent继承。非继承的特性（称为reset特性）如果没有定义，则使用默认的值。

样式上下文树缓存完整的结构（包括计算后的值），这样，如果底层节点没有为一个结构提供定义，则使用上层节点缓存的结构。

使用规则树计算样式上下文

当为一个特定的元素计算样式时，首先计算出规则树中的一条路径，或是使用已经存在的一条，然后使用路径中的规则去填充新的样式上下文，从样式的底层节点开始，它具有最高优先级（通常是最特定的选择器），遍历规则树，直到填满结构。如果在那个规则节点没有定义所需的结构规则，则沿着路径向上，直到找到该结构规则。

如果最终没有找到该结构的任何规则定义，那么如果这个结构是继承型的，则找到其在内容树中的parent的结构，这种情况下，我们也成功的共享了结构；如果这个结构是reset型的，则使用默认的值。

如果特定的节点添加了值，那么需要做一些额外的计算以将其转换为实际值，然后在树上的节点缓存该值，使它的children可以使用。

当一个元素和它的一个兄弟元素指向同一个树节点时，完整的样式上下文可以被它们共享。

来看一个例子：假设有下面这段html

以及下面这些规则

1.div {margin:5px;color:black}

2..err {color:red}

3..big {margin-top:3px}

4.div span {margin-bottom:4px}

5.#div1 {color:blue}

6.#div2 {color:green}

简化下问题，我们只填充两个结构——color和margin，color结构只包含一个成员－颜色，margin结构包含四边。

生成的规则树如下（节点名：指向的规则）

上下文树如下（节点名：指向的规则节点）

假设我们解析html，遇到第二个div标签，我们需要为这个节点创建样式上下文，并填充它的样式结构。

我们进行规则匹配，找到这个div匹配的规则为1、2、6，我们发现规则树上已经存在了一条我们可以使用的路径1、2，我们只需为规则6新增一个节点添加到下面（就是规则树中的F）。

然后创建一个样式上下文并将其放到上下文树中，新的样式上下文将指向规则树中的节点F。

现在我们需要填充这个样式上下文，先从填充margin结构开始，既然最后一个规则节点没有添加margin结构，沿着路径向上，直到找到缓存的前面插入节点计算出的结构，我们发现B是最近的指定margin值的节点。因

浏览器工作原理

从输入网址到显示页面：浏览器工作原理拆解分析本文将深入的研究当你输入一个网址的时候，后台到底发生了一件件什么样的事～ 1. 首先嘛，你得在浏览器里输入网址: 2. 浏览器查找域名的IP地址 导航的第一步是通过访问的域名找出其IP地址。DNS查找过程如下： 1.浏览器缓存–浏览器会缓存DNS记录一段时间。有趣的是，操作系统没有告诉 浏览器储存DNS记录的时间，这样不同浏览器会储存个自固定的一个时间（2分钟到30分钟不等）。 2.系统缓存–如果在浏览器缓存里没有找到需要的记录，浏览器会做一个系统调 用（windows里是gethostbyname）。这样便可获得系统缓存中的记录。 3.路由器缓存–接着，前面的查询请求发向路由器，它一般会有自己的DNS缓存。 4.ISP DNS 缓存–接下来要check的就是ISP缓存DNS的服务器。在这一般都能 找到相应的缓存记录。 5.递归搜索–你的ISP的DNS服务器从跟域名服务器开始进行递归搜索，从.com 顶级域名服务器到Facebook的域名服务器。一般DNS服务器的缓存中会有.co m域名服务器中的域名，所以到顶级服务器的匹配过程不是那么必要了。 DNS递归查找如下图所示：

DNS有一点令人担忧，这就是像https://www.wendangku.net/doc/314906147.html, 或者https://www.wendangku.net/doc/314906147.html,这样的整个域名看上去只是对应一个单独的IP地址。还好，有几种方法可以消除这个瓶颈：1. 循环DNS 是DNS查找时返回多个IP时的解决方案。举例来说，Faceboo https://www.wendangku.net/doc/314906147.html,实际上就对应了四个IP地址。 2. 负载平衡器是以一个特定IP地址进行侦听并将网络请求转发到集群服务器上的硬件设备。一些大型的站点一般都会使用这种昂贵的高性能负载平衡器。 3. 地理DNS 根据用户所处的地理位置，通过把域名映射到多个不同的IP地址提高可扩展性。这样不同的服务器不能够更新同步状态，但映射静态内容的话非常好。 4. Anycast是一个IP地址映射多个物理主机的路由技术。美中不足，Anycast 与TCP协议适应的不是很好，所以很少应用在那些方案中。 大多数DNS服务器使用Anycast来获得高效低延迟的DNS查找。 3. 浏览器给web服务器发送一个HTTP请求 因为像Facebook主页这样的动态页面，打开后在浏览器缓存中很快甚至马上就会过期，毫无疑问他们不能从中读取。 所以，浏览器将把一下请求发送到Facebook所在的服务器： GET https://www.wendangku.net/doc/314906147.html,/ HTTP/1.1 Accept: application/x-ms-application, image/jpeg, application/xaml+x ml, [...] User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...] Accept-Encoding: gzip, deflate Connection: Keep-Alive Host: https://www.wendangku.net/doc/314906147.html, Cookie: datr=1265876274-[...]; locale=en_US; lsd=WW[...]; c_user=210 1[...] GET 这个请求定义了要读取的URL：“https://www.wendangku.net/doc/314906147.html,/”。浏览器自身定义(User-Agent头)，和它希望接受什么类型的相应(Accept and Accept-Encodin g头). Connection头要求服务器为了后边的请求不要关闭TCP连接。 请求中也包含浏览器存储的该域名的cookies。可能你已经知道，在不同页面请求当中，cookies是与跟踪一个网站状态相匹配的键值。这样cookies会存储登录用户名，服务器分配的密码和一些用户设置等。Cookies会以文本文档形式存储在客户机里，每次请求时发送给服务器。 用来看原始HTTP请求及其相应的工具很多。作者比较喜欢使用fiddler，当然也有像FireBug这样其他的工具。这些软件在网站优化时会帮上很大忙。

浏览器内部工作原理

浏览器内部工作原理 浏览器可以被认为是使用最广泛的软件，我将介绍浏览器的简单基本的工作原理，我们将看到，从你在地址栏输入https://www.wendangku.net/doc/314906147.html,到你看到facebook主页过程中都发生了什么。

URL解析过程 ? 1. You enter a URL into the browser（输入一个url地址） –https://www.wendangku.net/doc/314906147.html, ? 2.The browser looks up the IP address for the domain name（浏览器查找域名的ip地址） –浏览器缓存 –系统缓存 –路由器缓存 –ISP DNS缓存 –递归搜索

? 3.The browser sends a HTTP request to the web server(浏览器给web服务器发送一个HTTP请求) –GET https://www.wendangku.net/doc/314906147.html,/ HTTP/1.1 –Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...] –User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...] –Accept-Encoding: gzip, deflate –Connection: Keep-Alive –Host: https://www.wendangku.net/doc/314906147.html, –Cookie: datr=1265876274-[...]; locale=en_US; lsd=WW[...]; c_user=2101[...] ?Get : 以GET的方式提交发送请求| POST ?https://www.wendangku.net/doc/314906147.html,/ 发送请求的URL地址 ?Http/1.1 HTTP协议 ?User-Agent : 浏览器自身定义 ?Accept-Encoding : 希望接收什么类型相应数据 ?Connection : 表示要求服务器为了后边的请求不要关闭TCP连接 ?请求中也包含浏览器存储的该域名的cookies，cookies会存储登录用户名，服务器分配的密码和一些用户设置等?像“https://www.wendangku.net/doc/314906147.html,/”中的斜杠是至关重要的。这种情况下，浏览器能安全的添加斜杠。而像“http: //https://www.wendangku.net/doc/314906147.html,/folderOrFile”这样的地址，因为浏览器不清楚folderOrFile到底是文件夹还是文件，所以不能自动添加斜杠。这时，浏览器就不加斜杠直接访问地址，服务器会响应一个重定向，结果造成一次不必要的握手

各服务器工作原理

FTP(文件传输协议)服务器工作原理FTP(文件传输协议)工作原理 目前在网络上,如果你想把文件和其他人共享。最方便的办法莫过于将文件放FTP服务器上，然后其他人通过FTP客户端程序来下载所需要的文件。 1、FTP架构 如同其他的很多通讯协议，FTP通讯协议也采用客户机 / 服务器（Client / Server ）架构。用户可以通过各种不同的FTP客户端程序，借助FTP协议，来连接FTP服务器，以上传或者下载文件。 2、FTP通讯端口知识 FTP服务器和客户端要进行文件传输，就需要通过端口来进行。FTP协议需要的端口一般包括两种：控制链路--------TCP端口21所有你发往FTP服务器的命令和服务器反馈的指令都是通过服务器上的21 端口传送的。数据链路--------TCP端口20数据链路主要是用来传送数据的，比如客户端上传、下载内容，以及列目录显示的内容等。 3、FTP连接的两种方式在数据链路的建立上，FTP Server 为了适应不同的网络环境，支持两种连接模式：主动模式（Port）和被动模式（Pasv)。其实这两种连接模式主要是针对数据链路进行的，和控制链路无关。 主动模式主动模式是这样工作的：客户端把自己的高位端口和服务器端口21建立控制链路。所有的控制命令比如Is或get都是通过这条链路传送的。当客户端需要服务器端给它传送数据时，客户端会发消息给服务器端，告诉自己的位置和打开的高位端口（一般大于1024的端口都就叫高位端口），等候服务器的20端口和客户端打开的端口进行连接，从而进行数据的传输。当服务器端收到信息后，就会和客户端打开的端口连接，这样数据链路就建立起来了。

浏览器工作原理拆解分析

浏览器工作原理拆解分析 1. 首先嘛，你得在浏览器里输入网址: 2. 浏览器查找域名的IP地址 导航的第一步是通过访问的域名找出其IP地址。DNS查找过程如下： 浏览器缓存——浏览器会缓存DNS记录一段时间。有趣的是，操作系统没有告诉浏览器储存DNS记录的时间，这样不同浏览器会储存个自固定的一个时间（2分钟到30分钟不等）。 系统缓存——如果在浏览器缓存里没有找到需要的记录，浏览器会做一个系统调用（windows 里是gethostbyname）。这样便可获得系统缓存中的记录。 路由器缓存——接着，前面的查询请求发向路由器，它一般会有自己的DNS缓存。 ISP DNS缓存——接下来要check的就是ISP缓存DNS的服务器。在这一般都能找到相应的缓存记录。 递归搜索——你的ISP的DNS服务器从跟域名服务器开始进行递归搜索，从.com顶级域名服务器到Facebook的域名服务器。一般DNS服务器的缓存中会有.com域名服务器中的域名，所以到顶级服务器的匹配过程不是那么必要了。 DNS递归查找如下图所示： DNS有一点令人担忧，这就是像https://www.wendangku.net/doc/314906147.html, 或者 https://www.wendangku.net/doc/314906147.html,这样的整个域名看上去只是对应一个单独的IP地址。还好，有几种方法可以消除这个瓶颈： 循环 DNS是DNS查找时返回多个IP时的解决方案。举例来说，https://www.wendangku.net/doc/314906147.html,实际上就对应了四个IP地址。 负载平衡器是以一个特定IP地址进行侦听并将网络请求转发到集群服务器上的硬件设备。一些大型的站点一般都会使用这种昂贵的高性能负载平衡器。 地理 DNS 根据用户所处的地理位置，通过把域名映射到多个不同的IP地址提高可扩展性。这样不同的服务器不能够更新同步状态，但映射静态内容的话非常好。

浏览器工作原理(图) 内部工作原理

前端必读：浏览器内部工作原理 目录 一、介绍 二、渲染引擎 三、解析与DOM树构建 四、渲染树构建 五、布局 六、绘制 七、动态变化 八、渲染引擎的线程 九、CSS2可视模型 英文原文：How Browsers Work: Behind the Scenes of Modern Web Browsers 一、介绍 浏览器可以被认为是使用最广泛的软件，本文将介绍浏览器的工作原理，我们将看到，从你在地址栏输入https://www.wendangku.net/doc/314906147.html,到你看到google主页过程中都发生了什么。 将讨论的浏览器 今天，有五种主流浏览器——IE、Firefox、Safari、Chrome及Opera。 本文将基于一些开源浏览器的例子——Firefox、Chrome及Safari，Safari是部分开源的。 根据W3C（World Wide Web Consortium万维网联盟）的浏览器统计数据，当前（2011年5月），Firefox、Safari及Chrome的市场占有率综合已接近60％。（原文为2009年10月，数据没有太大变化）因此，可以说开源浏览器已经占据了浏览器市场的半壁江山。 浏览器的主要功能 浏览器的主要功能是将用户选择的web资源呈现出来，它需要从服务器请求资源，并将其显示在浏览器窗口中，资源的格式通常是HTML，也包括PDF、image及其他格式。用户用URI（Uniform Resource Identifier统一资源标识符）来指定所请求资源的位置，在网络一章有更多讨论。 HTML和CSS规范中规定了浏览器解释html文档的方式，由W3C组织对这些规范进行维护，W3C是负责制定web标准的组织。 HTML规范的最新版本是HTML4(https://www.wendangku.net/doc/314906147.html,/TR/html401/)，HTML5还在制定中（译注：两年前），最新的CSS规范版本是2（https://www.wendangku.net/doc/314906147.html,/TR/CSS2），CSS3也还正在制定中（译注：同样两年前）。 这些年来，浏览器厂商纷纷开发自己的扩展，对规范的遵循并不完善，这为web开发者带来了严重的兼容性问题。 但是，浏览器的用户界面则差不多，常见的用户界面元素包括： ?用来输入URI的地址栏 ?前进、后退按钮 ?书签选项 ?用于刷新及暂停当前加载文档的刷新、暂停按钮

WEB浏览器工作原理

WEB浏览器工作原理【来自网络】 2007-04-13 17:15 WWW 的工作基于客户机/服务器计算模型，由Web 浏览器(客户机)和Web服务器(服务 器)构成，两者之间采用超文本传送协议（HTTP）进行通信， HTTP协议的作用原理包括四 个步骤：连接，请求，应答。根据上述HTTP协议的作用原理，本文实现了GET 请求的Web服 务器程序的方法，通过创建 TcpListener类对象，监听端口8080；等待、接受客户机连 接到端口8080；创建与socket字相关联的输入流和输出流;然后，读取客户机的请求信 息，若请求类型是GET，则从请求信息中获取所访问的HTML文件名，如果HTML 文件存在， 则打开HTML文件，把HTTP头信息和 HTML文件内容通过socket传回给Web浏览器，然后关闭 文件。否则发送错误信息给Web浏览器。最后，关闭与相应Web浏览器连接的socket 字。 一、HTTP协议的作用原理 WWW是以Internet作为传输媒介的一个应用系统，WWW网上最基本的传输单位是Web网 页。WWW的工作基于客户机/服务器计算模型，由Web 浏览器(客户机)和Web服务器(服务 器)构成，两者之间采用超文本传送协议（HTTP）进行通信。HTTP协议是基于TCP/IP协议 之上的协议，是Web浏览器和Web服务器之间的应用层协议，是通用的、无状态的、面向对 象的协议。HTTP协议的作用原理包括四个步骤： 连接：Web浏览器与Web服务器建立连接，打开一个称为socket（套接字）的虚拟文 件，此文件的建立标志着连接建立成功。 请求：Web浏览器通过socket向Web服务器提交请求。HTTP的请求一般是GET 或POST命 令（POST用于FORM参数的传递）。GET命令的格式为： GET 路径/文件名 HTTP/1.0 文件名指出所访问的文件，HTTP/1.0指出Web浏览器使用的HTTP版本。 应答：Web浏览器提交请求后，通过HTTP协议传送给Web服务器。Web服务器接

深入了解浏览器加载渲染及内核原理

浏览器加载和渲染网页的过程 2009-07-20 20:26 关于网页加载和渲染的过程，在网络上的讨论并不多。可能是因为这个过程比较复杂，而且浏览器执行的速度太快，目前还没有发现什么比较好的工具可以清楚的看到浏览器解析网页的每一个过程。通过firedug和httpWatch可以看到浏览器的http请求，但是对于浏览器如何paint和flow处理html元素，我们仍然是不得而知。“flow”这个词借鉴于reflow，表示浏览器第一次加载网页的过程。在网络上搜索了一下，学习如下。 关于浏览器加载网页过程的有趣视频 可以参见：https://www.wendangku.net/doc/314906147.html,/blog/2008/05/reflow/（形象化的reflow）。这个视频展现了网页加载的过程，看着比较有趣。要是可以更加形象化，就更好了，可以帮助我们书写更好的提高网页加载速度的代码。 浏览器内核 不同的浏览器内核，对于网页的解析过程肯定也不尽相同。 https://www.wendangku.net/doc/314906147.html,/post/Trident-Gecko-WebKit-Presto.php一文对各种浏览器的页面渲染引擎进行了简介。目前主要有基于 （1）Trident页面渲染引擎–> IE系列浏览器； （2）Gecko页面渲染引擎–> Mozilla Firefox； （3）KHTML页面渲染引擎或WebKit框架–> Safafi和Google Chrome； （4）Presto页面渲染引擎–> Opera 详细的介绍可以参见原文。 浏览器解析网页的过程 https://www.wendangku.net/doc/314906147.html,/seosky/blog/item/78d3394c130f86ffd72afc56.html浏览器加载 和渲染原理分析一文中通过一定的方法，推断了浏览器加载解析网页的顺序大致如下： 1. IE下载的顺序是从上到下，渲染的顺序也是从上到下，下载和渲染是同时进行的； 2. 在渲染到页面的某一部分时，其上面的所有部分都已经下载完成（并不是说所有相关联的元素都已经下载完）； 3. 在下载过程中，如果遇到某一标签是嵌入文件，并且文件是具有语义解释性的（例如：JS脚本，CSS样式），那么此时IE的下载过程会启用单独连接进行下载，并且在下载后进行解析，解析（JS、CSS中如有重定义，后定义函数将覆盖前定义函数）过程中，停止页面所有往下元素的下载； 4. 样式表文件比较特殊，在其下载完成后，将和以前下载的所有样式表一起进行解析，解析完成后，将对此前所有元素（含以前已经渲染的）重新进行样

java web 工作原理总结

总结 第一章java web 工作原理 1.1、web应用程序有web服务器，web客服端浏览器，HTTP协议以及静态HTML文件。 Web服务器的作用是接受客服端请求，然后向客服端返回些结果；浏览器的作用是允许用户请求服务器上的某个资源，并且向用户显示请求的结果； HTML是用于告诉浏览器怎么样向用户显示内容； HTTP是web上客服端和服务器之间通信所用的协议。 1.1.2 HTTP协议将来自于客服端的请求信息封装成HTTP请求； 封装的信息当中包括请求行、请求头、消息体、分隔请求头、消息体的一个空行。 请求行是一个ASCII文本行，由三个标记组成：请求的HTTP方法、请求的URL、HTTP版本；中间用空格分开例如： GET /lovobook/index.html HTTP/1.0 在HTTP1.1版本中请求方法有八种分别是下面： GET：用于向服务器检索资源在HTTP请求头 POST：用于向服务器发送资源，并要求指定的URI处理在消息体HEAD：于GET方法相同，服务器只返回状态行和头标，并不返回请求文档。 PUT：请求服务器保持请求数据作为指定的URI新内容；

DELETE：请求服务器删除URI中命名的资源； OPTIONS：请求关于服务器支持的请求方法信息； TRACE：请求web服务器反馈HTTP请求和其头标；CONNECT：已文档化但当前未实现的一个方法，预留做隧道处理；请求头： HTTP协议使用HTTP头来传递请求的元信息。HTTP头是一个用冒号分隔的名称/值对，冒号前面是HTTP头的名称，后面是HTTP头的值。 1.1.3 HTTP响应包括：状态行、响应头、消息体、分割消息头、响应头。状态行里面出现： 1XX:表示信息，请求收到，继续处理。 2XX:表示成功 3XX:表示重定向 4XX:表示客服端错误 5XX:表示服务器错误 1.2 Web服务器的缺陷是只能向用户提供静态网页内容。 1.3 服务器端网页编程就是web服务器创建动态服务器端内容的过程。 1.3.1 服务器端网页编程出现得最早的技术就是CGI，它的缺点就是每次请求一个CGI资源，将在服务器上创建一个新的进程，并且通过标准输

Web服务器的工作原理

Web服务器工作原理概述 很多时候我们都想知道，web容器或web服务器（比如Tomcat或者jboss）是怎样工作的？它们是怎样处理来自全世界的http请求的？它们在幕后做了什么动作？Java Servlet API（例如ServletContext，ServletRequest，ServletResponse和Session这些类）在其中扮演了什么角色？这些都是web应用开发者或者想成为web应用开发者的人必须要知道的重要问题或概念。在这篇文章里，我将会尽量给出以上某些问题的答案。 请集中精神！ 文章章节： ?什么是web服务器、应用服务器和web容器？ ?什么是Servlet？他们有什么作用？ ?什么是ServletContext？它由谁创建？ ?ServletRequest和ServletResponse从哪里进入生命周期？ ?如何管理Session？知道cookie吗？ ?如何确保线程安全？ 什么是web服务器，应用服务器和web容器？ 我先讨论web服务器和应用服务器。让我在用一句话大概讲讲： “在过去它们是有区别的，但是这两个不同的分类慢慢地合并了，而如今在大多在情况下和使用中可以把它们看成一个整体。” 在Mosaic浏览器（通常被认为是第一个图形化的web浏览器）和超链接内容的初期，演变出了“web服务器”的新概念，它通过HTTP协议来提供静态页面内容和图片服务。在

那个时候，大多数内容都是静态的，并且HTTP 1.0只是一种传送文件的方式。但在不久后web服务器提供了CGI功能。这意味着我们可以为每个web请求启动一个进程来产生动态内容。现在，HTTP协议已经很成熟了并且web服务器变得更加复杂，拥有了像缓存、安全和session管理这些附加功能。随着技术的进一步成熟，我们从Kiva和NetDynamics学会了公司专属的基于Java的服务器端技术。这些技术最终全都融入到我们今天依然在大多数应用开发里使用的JSP中。 以上是关于web服务器的。现在我们来讨论应用服务器。 在同一时期，应用服务器已经存在并发展很长一段时间了。一些公司为Unix开发了Tuxedo（面向事务的中间件）、TopEnd、Encina等产品，这些产品都是从类似IMS和CICS的主机应用管理和监控环境衍生而来的。大部分的这些产品都指定了“封闭的”产品专用通信协议来互连胖客户机(“fat”client)和服务器。在90年代，这些传统的应用服

浏览器工作原理

长沙理工大学 《网络系统》课程设计报告 学院城南学院专业计算机科学与技术班级计算机1101 学号201186250222 学生姓名高扬指导教师周书仁 课程成绩完成日期2013年6月28日

课程设计成绩评定 学院城南学院专业计算机科学与技术班级计算机1101 学号201186250222 学生姓名高扬指导教师周书仁完成日期2013年6月28日 指导教师对学生在课程设计中的评价 指导教师对课程设计的评定意见

课程设计任务书 城南学院学院计算机科学与技术专业

浏览器的设计与实现 学生姓名：高扬指导老师：周书仁 摘要论文主要介绍了本课题的开发背景，所要完成的功能和开发的过程。重点说明了系统设计重点、设计思想、难点技术和解决方案；同时也论述了基于HTTP协议的Web浏览器的开发思路、开发过程、利用的主要技术及本浏览器应用程序的功能模块的说明。本课题是在深入理解HTTP协议的工作机理，系统掌握了TCP/UDP网络通信协议及网络编程的基本方法，掌握了使用Windows Sockets API和MFC Socket编程技术之后，采用Visual C++作为开发工具来设计并实现一个Web浏览器，其功能主要包括：浏览器的界面实现;实现收藏菜单;显示超文本;删除相关历史记录;将应用程序加入到时工具栏、禁止弹出窗口、禁止浏览某些网站访问Web页，保存网页，打印网页，停止当前访问，刷新网页，查看源文件和Internet属性等等。 关键词：Visual C++；MFC；HTTP协议；浏览器 目录 第1章绪论 1.1 软件开发背景 随着社会的发展和需求，在20世纪中叶人类研制了电子计算机。电子计算机运算速度快，计算精度高，存储能力强，具有逻辑判断能力，具有自动运行能力等特点。进过半个多世纪的飞速发展，电子计算在许多领域得到了广泛的应用，已成为衡量一个国家现代化水平的重要标志。而

Brower基本原理

浏览器（browser） 定义： 万维网(Web)服务的客户端浏览程序。 可向万维网(Web)服务器发送各种请求，并对从服务器发来的超文本信息和各种多媒体数据格式进行解释、显示和播放。 浏览器工作原理 WWW 的工作基于客户机/服务器计算模型，由Web 浏览器(客户机)和Web服务器(服务器)构成，两者之间采用超文本传送协议（HTTP）进行通信，HTTP协议的作用原理包括四个步骤：连接，请求，应答。根据上述HTTP协议的作用原理，本文实现了GET请求的Web服务器程序的方法，通过创建TcpListener 类对象，监听端口8080；等待、接受客户机连接到端口8080；创建与socket字相关联的输入流和输出流;然后，读取客户机的请求信息，若请求类型是GET，则从请求信息中获取所访问的HTML文件名，如果HTML文件存在，则打开HTML文件，把HTTP头信息和HTML文件内容通过socket传回给Web浏览器，然后关闭文件。否则发送错误信息给Web浏览器。最后，关闭与相应Web浏览器连接的socket 字。 HTTP协议的作用原理 WWW是以Internet作为传输媒介的一个应用系统，WWW网上最基本的传输单位是Web网页。WWW 的工作基于客户机/服务器计算模型，由Web 浏览器(客户机)和Web服务器(服务器)构成，两者之间采用超文本传送协议（HTTP）进行通信。HTTP协议是基于TCP/IP协议之上的协议，是Web浏览器和Web 服务器之间的应用层协议，是通用的、无状态的、面向对象的协议。HTTP协议的作用原理包括四个步骤：连接：Web浏览器与Web服务器建立连接，打开一个称为socket（套接字）的虚拟文件，此文件的建立标志着连接建立成功。 请求：Web浏览器通过socket向Web服务器提交请求。HTTP的请求一般是GET或POST命令（POST 用于FORM参数的传递）。GET命令的格式为： GET 路径/文件名HTTP/1.0 文件名指出所访问的文件，HTTP/1.0指出Web浏览器使用的HTTP版本。 应答：Web浏览器提交请求后，通过HTTP协议传送给Web服务器。Web服务器接到后，进行事务处理，处理结果又通过HTTP传回给Web浏览器，从而在Web浏览器上显示出所请求的页面。 例：假设客户机与https://www.wendangku.net/doc/314906147.html,:8080/mydir/index.html建立了连接，就会发送GET命令：GET /mydir/index.html HTTP/1.0。主机名为https://www.wendangku.net/doc/314906147.html,的Web服务器从它的文档空间中搜索子目录mydir的文件index.html。如果找到该文件，Web服务器把该文件内容传送给相应的Web浏览器。 为了告知Web浏览器传送内容的类型，Web服务器首先传送一些HTTP头信息，然后传送具体内容（即HTTP体信息），HTTP头信息和HTTP体信息之间用一个空行分开。 常用的HTTP头信息有： ①HTTP 1.0 200 OK 这是Web服务器应答的第一行，列出服务器正在运行的HTTP版本号和应答代码。代码 “200 OK”表示请求完成。 ②MIME_V ersion:1.0

百度文库浏览器分析及实现

百度文库浏览器分析及实现 一、引子 2003年开始玩Flash，完了两年就戒掉了；长时间不用不完慢慢就生疏了。最近应客户的需要，希望能在文档系统中实现类似百度文库的效果。考查一番，咋看起来百度用的是FlashPaper技术，也看了看FlexPaper，在GoogleCode上还看到了一个超大文件的示例，可惜链接打不开，无法去详细分析他们了。 在能看到的应用中，FlashPaper、FlexPaper都不能达到在互联网上动态加载大文档的用户体验需求；唯独百度文库有这样的用户体验，因此就只能拿百度文库开刀了，希望李彦宏同志不要见怪。 姑且拿《六十八个经典小故事》作为示例，该文档页数足够多，能够展示动态加载的效果。 二、百度文库浏览器原理分析步骤 1.找到《六十八个经典小故事》对应的链接； 2.清空IE缓存，在IE中浏览该页面； 3.使用导航将文档浏览至最后； 4.抓取IE缓存中的内容； 5.材料已取好，分析开始。 三、百度文库浏览器代码分析 一进来，刘姥姥进了大观园了，这个JavaScript脚本看得人脑袋那个大啊，这条路走起来挺艰难，换个思路吧；找个Flash反编译工具，反编译一下，取出来ActionScript，这个好歹还有个分行短句啊，总算还是个代码。 整理整理代码的层次结构，按照包组织一下，大致能确认应该在baidu这个文件夹吧；再看看，lib大致是用于json处理的；ui是用于用户自定义控件；iknow 就应该是程序入口吧，按照一般程序要的思路先找一找main吧，果然还真有一个main类，有意思。 下面这几句代码大概就是与外部进行参数交换的吧：

var _loc_2:* = _loc_1["docurl"] || "https://www.wendangku.net/doc/314906147.html,:8960/play"; var _loc_3:* = _loc_1["docid"] || "c881e53a580216fc700afd05"; var _loc_4:* = int(_loc_1["fpn"]) || 2; var _loc_5:* = int(_loc_1["npn"]) || 5; this._reader.fpn = _loc_4; this._reader.npn = _loc_5; this._reader.docURL = _loc_2.replace(/(\/)+$/, "") + "/" + _loc_3 + "?"; 如此以来就可以查找docurl、docid、fpn、npn这几个参数了，在JavaScript 或者json中应该有体现的。 在看一看Reader类，再看看DocViewer类大致就知道了百度的FlashPaper 的Reader的原理了。 if (this._firstPagesNum == -1) { tmpURL = this._docURL + "pn=" + (this._pagesLoaded + 1) + "&rn=" +

HTTP工作原理

HTTP协议工作原理是我们现在要为大家介绍的内容。作为WWW的基础的HTTP协议，它的工作原理可以分为外部和内部。试想，一个庞大的网络结构，它的协议又怎么能简单呢。所以我们一定要在了解了HTTP协议的基本结构后来看它的工作流程。 既然我们明白了URL的构成，那么HTTP是怎么工作呢？我们接下来就要讨论这个问题。 一次HTTP操作称为一个事务，HTTP协议工作原理可分为四步： 首先客户机与服务器需要建立连接。只要单击某个超级链接，HTTP的工作就开始了。 建立连接后，客户机发送一个请求给服务器，请求方式的格式为：统一资源标识符（URL）、协议版本号，后边是MIME信息包括请求修饰符、客户机信息和可能的内容。 服务器接到请求后，给予相应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后边是MIME信息包括服务器信息、实体信息和可能的内容。 客户端接收服务器所返回的信息通过浏览器显示在用户的显示屏上，然后客http工作流程图户机与服务器断开连接。 如果在以上过程中的某一步出现错误，那么产生错误的信息将返回到客户端，有显示屏输出。对于用户来说，这些过程是由HTTP自己完成的，用户只要用鼠标点击，等待信息显示就可以了。 许多HTTP通讯是由一个用户代理初始化的并且包括一个申请在源服务器上资源的请求。最简单的情况可能是在用户代理和服务器之间通过一个单独的连接来完成。在Internet上，HTTP通讯通常发生在TCP/IP连接之上。缺省端口是TCP 80，但其它的端口也是可用的。但这并不预示着HTTP协议在Internet或其它网络的其它协议之上才能完成。HTTP只预示着一个可靠的传输。 这个过程就好像我们打电话订货一样，我们可以打电话给商家，告诉他我们需要什么规格的商品，然后商家再告诉我们什么商品有货，什么商品缺货。这些，我们是通过电话线用电话联系（HTTP是通过TCP/IP），当然我们也可以通过传真，只要商家那边也有传真。 以上简要介绍了HTTP协议的宏观运作方式，下面介绍一下HTTP协议工作原理的内部操作过程。 在WWW中，“客户”与“服务器”是一个相对的概念，只存在于一个特定的连接期间，即在某个连接中的客户在另一个连接中可能作为服务器。基于HTTP

浏览器工作原理

简介 浏览器可以被认为是使用最广泛的软件，本文将介绍浏览器的工作原理，我们将看到，从你在地址栏输入https://www.wendangku.net/doc/314906147.html,到你看到google主页过程中都发生了什么。 将讨论的浏览器 今天，有五种主流浏览器——IE、Firefox、Safari、Chrome及Opera。 本文将基于一些开源浏览器的例子——Firefox、 Chrome及Safari，Safari是部分开源的。 根据W3C（World Wide Web Consortium 万维网联盟）的浏览器统计数据，当前（2011年9月），Firefox、Safari及Chrome的市场占有率综合已快接近50％。（原文为2009年10月，数据没有太大变化）因此，可以说开源浏览器将近占据了浏览器市场的半壁江山。 浏览器的主要功能 浏览器的主要功能是将用户选择得web资源呈现出来，它需要从服务器请求资源，并将其显示在浏览器窗口中，资源的格式通常是HTML，也包括PDF、image及其他格式。用户用URI（Uniform Resource Identifier 统一资源标识符）来指定所请求资源的位置，在网络一章有更多讨论。 HTML和CSS规范中规定了浏览器解释html文档的方式，由 W3C组织对这些规范进行维护，W3C是负责制定web标准的组织。 HTML规范的最新版本是HTML4(https://www.wendangku.net/doc/314906147.html,/TR/html401/)，HTML5还在 制定中（译注：两年前），最新的CSS规范版本是2（https://www.wendangku.net/doc/314906147.html,/TR/CSS2），CSS3也还正在制定中（译注：同样两年前）。 这些年来，浏览器厂商纷纷开发自己的扩展，对规范的遵循并不完善，这为web 开发者带来了严重的兼容性问题。 但是，浏览器的用户界面则差不多，常见的用户界面元素包括： ?用来输入URI的地址栏 ?前进、后退按钮 ?书签选项 ?用于刷新及暂停当前加载文档的刷新、暂停按钮 ?用于到达主页的主页按钮 奇怪的是，并没有哪个正式公布的规范对用户界面做出规定，这些是多年来各浏览器厂商之间相互模仿和不断改进得结果。

BS结构的工作原理

B S结构的工作原理 Company Document number：WTUT-WT88Y-W8BBGB-BWYTT-19998

B/S结构的工作原理是：客户端的浏览器通过URL访问Web服务器，Web服务器请求数据库服务器，并将获得的结果以HTML形式返回客户端浏览器。 二、B/S网络模式的结构和特点 B/S网络模式是基于Intranet需求而出现并发展的。一方面Intranet是应用TCP/IP协议中建立的企事业单位内部网络，它采用诸如TCP/IP，HTTP，SMIP和HTML等Internet技术和标准，能为企事业单位内部交换信息提供服务。同时，它是有连接Internet的防止外界入侵的安全措施。另一方面，由于数据库具有强大的数据存储和管理能力，并且能够动态地进行数据输入和输出，如果把数据库应用于Internet上，不仅可以实现大量信息的网上发布，而且能够为广大用户提供动态的信息查询和数据处理服务，进而加强信息交流，降低企事业单位的日常工作成本，提高企事业单位的经济效益。 B/S模式，即浏览器服务器模式，是一种从传统的二层C/S 模式发展起来的新的网络结构模式。其本质是三层结构C/S模式。B/S模式主要由客户机，Web服务器，应用服务器和数据服务器（server）组成。在客户端安装的是标准、易用的通用浏览器（Browser），将Web技术与数据库技术相结合。Web服务器主要是实现对客户端应用程序的集中管理，应用服务器主要负责事务处理，数据服务器主要用于数据的管理， B/S模式基本上克服了C/S模式的不足，其主要表现在：

1．系统开发、维护和升级的经济性。 2．B/S模式提供了一致的用户界面，应用软件都是基于Web浏览器，从而提供了一致的用户界面。 3．B/S模式具有很强的开放性。 4．B/S模式的结构易于扩展，具有可伸缩性。 5．B/S模式具有最强的信息系统集成性。 6．B/S模式提供灵活的交流和信息发布服务。 B/S结构体系与C/S结构体系相比，其优点如下： 1．不必开发专门的客户端软件，在用户终端不需要增加任何代码，用户只需要使用现行的浏览器，基操作十分方便，简单易学，界面统一，降低了用户学习新知识的难度，既节省了开发时间，也减少了系统出错的可能性，降低了维护费用。 2．网络应用系统跨平台，兼容性好，保护原有的软硬件设施，原来的网络操作系统，数据库都可以很容易地加以利用，可以使系统在最短的时间发挥效益。 3．技术上相对成熟，投入费用少，系统维护简便，简单易用，见效快，回报率高，应用Web技术，OA系统只需在服务器上集中实现和配置的维护管理，大大降低了用户用于软件系统维护和升级的难度和费用，用户投资风险小。 4．系统运行稳定、安全、可靠、并可进行扩展。 5．软件移植容易，并可以进行严密的安全管理。

网页及数据库的工作原理

网页提取的工作原理： 网络爬虫是网页检索的核心部分。 网络爬虫定义有广义和狭义之分， 狭义上的定义为利用标准的http协议根据超级链接和web文档检索的方法遍历万维网信息空间的程序； 而广义则是所有能利用http协议检索web文档的软件都称之为网络爬虫。 网络爬虫是一个功能很强的自动提取网页的程序，它为搜索引擎从万维网上下载网页，是搜索引擎的重要部分。它通过请求站点上的HtML文档访问某一个站点。它遍历web空间，不断从一个站点移动到另一个站点，自动建立索引，并加入到网页数据库中。网络爬虫进入某个超级文本时，它利用HTML语言的标记结构来搜索信息及获取指向其他超级文本的URL 地址，可以完全不依赖用户干预实现网络上的自动“爬行”搜索。 浏览器的工作原理： （1）浏览器通过HTML表单或超链接请求指向一个应用程序的URL。 （2）服务器收到用户的请求。 （3）服务器执行已接受创建的指定应用程序。 （4）应用程序通常是基于用户输入的内容，执行所需要的操作。 （5）应用程序把结果格式化为网络服务器和浏览器能够理解的文档，即我们所说的HTML网页 （6）网络服务器最后将结果返回到浏览器中。 ASP的工作原理： （1）用户调出站点内容，默认页面的扩展名是.Asp （2）浏览器从服务器上请求asp文件。 （3）服务器端脚本开始运行ASP。 （4）Asp文件按照从上到下的顺序开始处理，执行脚本命令，执行HTML内容。 （5）页面信息发送到浏览器。 SQL工作原理： （1）SQL语句执行顺序： 1、FROM子句组装来自不停数据源的数据。 2、Where子句基于指定的条件对记录进行筛选。 3、Group by子句将数据划分为多个分组。 4、使用聚集函数进行计算。 5、使用having子句筛选分组。 6、计算所有的表达式。 7、使用order by对结果集进行排序。 数据库： （1）长期储存在计算机内，有组织的、可共享的数据集合。 （2）数据库中的数据不是孤立的，数据与数据之间是相互关联的。 （3）数据库中的数据具有较小的冗余度、较高的数据独立性和易扩展性。 数据库管理系统（DBMS）:是在操作系统的支持下为用户提供数据库建立、数据操纵、数据库维护的管理软件 功能： 1）数据定义。 2）数据操纵功能。

浏览器工作原理新式网络浏览器幕后揭秘

序言 这是一篇全面介绍Webkit 和Gecko 内部操作的入门文章，是以色列开发人员塔利·加希尔大量研究的成果。在过去的几年中，她查阅了所有公开发布的关于浏览器内部机制的数据（请参见资源），并花了很多时间来研读网络浏览器的源代码。她写道： 在IE 占据90% 市场份额的年代，我们除了把浏览器当成一个“黑箱”，什么也做不了。但是现在，开放源代码的浏览器拥有了过半的市场份额，因此，是时候来揭开神秘的面纱，一探网络浏览器的内幕了。呃，里面只有数以百万行计的C++ 代码... 塔利在她的网站上公布了自己的研究成果，但是我们觉得它值得让更多的人来了解，所以我们在此重新整理并公布。 作为一名网络开发人员，学习浏览器的内部工作原理将有助于您作出更明智的决策，并理解那些最佳开发实践的个中缘由。尽管这是一篇相当长的文档，但是我们建议您花些时间来仔细阅读；读完之后，您肯定会觉得所费不虚。保罗·爱丽诗(Paul Irish)，Chrome 浏览器开发人员事务部 简介 网络浏览器很可能是使用最广的软件。在这篇入门文章中，我将会介绍它们的幕后工作原理。我们会了解到，从您在地址栏输入https://www.wendangku.net/doc/314906147.html, 直到您在浏览器屏幕上看到Google 首页的整个过程中都发生了些什么。 我们要讨论的浏览器 目前使用的主流浏览器有五个：Internet Explorer、Firefox、Safari、Chrome 浏览器和Opera。本文中以开放源代码浏览器为例，即Firefox、Chrome 浏览器和Safari（部分开源）。根据StatCounter 浏览器统计数据，目前（2011 年8 月）Firefox、Safari 和Chrome 浏览器的总市场占有率将近60%。由此可见，如今开放源代码浏览器在浏览器市场中占据了非常坚实的部分。 浏览器的主要功能 浏览器的主要功能就是向服务器发出请求，在浏览器窗口中展示您选择的网络资源。这里所说的资源一般是指HTML 文档，也可以是PDF、图片或其他的类型。资源的位置由用户使用URI（统一资源标示符）指定。浏览器解释并显示HTML 文件的方式是在HTML 和CSS 规范中指定的。这些规范由网络标准化组织W3C（万维网联盟）进行维护。多年以来，各浏览器都没有完全遵从这些规范，同时还在开发自己独有的扩展程序，这给网络开发人员带来了严重的兼容性问题。如今，大多数的浏览器都是或多或少地遵从规范。 浏览器的用户界面有很多彼此相同的元素，其中包括： 用来输入URI 的地址栏 前进和后退按钮 书签设置选项 用于刷新和停止加载当前文档的刷新和停止按钮 用于返回主页的主页按钮 奇怪的是，浏览器的用户界面并没有任何正式的规范，这是多年来的最佳实践自然发展以及彼此之间相互模仿的结果。HTML5 也没有定义浏览器必须具有的用户界面元素，但列出了一些通用的元素，例如地址栏、状态栏和工具栏等。当然，各浏览器也可以有自己独特的功能，比如Firefox 的下载管理器。 浏览器的高层结构 浏览器的主要组件为(1.1)： 用户界面- 包括地址栏、前进/后退按钮、书签菜单等。除了浏览器主窗口显示的您请求的页面外，其他显示的各个部分都属于用户界面。 浏览器引擎- 在用户界面和呈现引擎之间传送指令。 呈现引擎- 负责显示请求的内容。如果请求的内容是HTML，它就负责解析HTML 和CSS 内容，并将解析后的内容显示在屏幕上。 网络- 用于网络调用，比如HTTP 请求。其接口与平台无关，并为所有平台提供底层实现。 用户界面后端- 用于绘制基本的窗口小部件，比如组合框和窗口。其公开了与平台无关的通用接口，而在底层使用操作系统的用户界面方法。 JavaScript 解释器。用于解析和执行JavaScript 代码。 数据存储。这是持久层。浏览器需要在硬盘上保存各种数据，例如Cookie。新的HTML 规范(HTML5) 定义了“网络数据库”，这是一个完整（但是轻便）的浏览器内数据库。