前端技术-HTML页面的加载

HTML页面的加载

HTML页面的加载实际上是基于http过程+浏览器对数据的解析渲染。

http协议的请求过程是基于TCP协议的。http是要基于TCP连接基础上，简单的说，TCP单纯建立连接，不涉及任何我们需要请求的实际数据，简单的传输。http基于TCP建立的连接来收发数据，即实际应用上来的。

一个HTML页面的加载的交互流程大致如下：

0.输入URL
1.解析URL
2.构造并发送HTTP请求
服务器的永久重定向响应（从 http://example.com 到 http://www.example.com）
浏览器跟踪重定向地址
3.HTTP报文传输过程
4.服务器接受并处理HTTP报文
5.服务器构造并发送响应报文（传输过程略）
6.浏览器接收报文，并开始构建页面
7.（可选）浏览器发送嵌入在 HTML 中的静态资源如图片、音频、视频、CSS、JS等等）
8.（可选）浏览器发送Ajax异步请求（处理过程略）
9.页面构建完成

一.http过程

http协议的请求过程是基于TCP协议的。实际上是TCP/IP协议簇的共同作用。

1.TCP/IP协议

TCP/IP协议，Transmission Control Protocol/Internet Protocol的简写，中译名为传输控制协议/因特网互联协议，又名网络通讯协议，是Internet最基本的协议、Internet国际互联网络的基础，由网络层的IP协议和传输层的TCP协议组成的协议簇。它是计算机网络的的实际分层方式。

计算机网络的分层

第一种ISO/OSI模型，即开放式通信系统互联参考模型（Open System Interconnection Reference Model），是国际标准化组织（ISO）提出的一个试图使各种计算机在世界范围内互连为网络的标准框架，简称OSI。可是实践中没有广泛应用。

第二种TCP/IP协议模型（Transmission Control Protocol/Internet Protocol），包含了一系列构成互联网基础的网络协议，是Internet的核心协议。根据实际情况将ISO的OSI模型改造为5层，这种模型具有现实可行性。目前已成为事实上的国际标准。TCP/IP协议簇是一组不同层次上的多个协议的组合，通常被认为是一个五层协议系统，与OSI的七层模型相对应。

TCP/IP协议簇中不同层次的协议：

(1). 链路层 
也称作数据链路层或网络接口层（在第一个图中为网络接口层和硬件层），通常包括操作系统中的设备驱动程序和计算机中对应的网络接口卡。它们一起处理与电缆（或其他任何传输媒介）的物理接口细节。ARP（地址解析协议）和RARP（逆地址解析协议）是某些网络接口（如以太网和令牌环网）使用的特殊协议，用来转换IP层和网络接口层使用的地址。     
(2). 网络层
也称作互联网层（在第一个图中为网际层），处理分组在网络中的活动，例如分组的选路。在TCP/IP协议族中，网络层协议包括IP协议（网际协议），ICMP协议（Internet互联网控制报文协议），以及IGMP协议（Internet组管理协议）。     
IP是一种网络层协议，提供的是一种不可靠的服务，它只是尽可能快地把分组从源结点送到目的结点，但是并不提供任何可靠性保证。同时被TCP和UDP使用。TCP和UDP的每组数据都通过端系统和每个中间路由器中的IP层在互联网中进行传输。  IP层接收由更低层（网络接口层例如以太网设备驱动程序）发来的数据包，并把该数据包发送到更高层---TCP或UDP层；相反，IP层也把从TCP或UDP层接收来的数据包传送到更低层。IP数据包是不可靠的，因为IP并没有做任何事情来确认数据包是按顺序发送的或者没有被破坏。IP数据包中含有发送它的主机的地址（源地址）和接收它的主机的地址（目的地址）。   
ICMP是IP协议的附属协议（PING是最常用的基于ICMP的服务）。IP层用它来与其他主机或路由器交换错误报文和其他重要信息。  IGMP是Internet组管理协议。它用来把一个UDP数据报多播到多个主机。
(3). 传输层
主要为两台主机上的应用程序提供端到端的通信。在TCP/IP协议族中，有两个互不相同的传输协议：TCP（传输控制协议）和UDP（用户数据报协议）。     
TCP为两台主机提供高可靠性的数据通信。它所做的工作包括把应用程序交给它的数据分成合适的小块交给下面的网络层，确认接收到的分组，设置发送最后确认分组的超时时钟等。由于运输层提供了高可靠性的端到端的通信，因此应用层可以忽略所有这些细节。为了提供可靠的服务，TCP采用了超时重传、发送和接收端到端的确认分组等机制。  UDP则为应用层提供一种非常简单的服务。它只是把称作数据报的分组从一台主机发送到另一台主机，但并不保证该数据报能到达另一端。一个数据报是指从发送方传输到接收方的一个信息单元（例如，发送方指定的一定字节数的信息）。UDP协议任何必需的可靠性必须由应用层来提供。     
(4). 应用层
应用层负责处理特定的应用程序细节。

接下来介绍TCP连接的建立。

2.TCP的三次握手与四次分手

TCP是面向连接的，无论哪一方向另一方发送数据之前，都必须先在双方之间建立一条连接。在TCP/IP协议中，TCP协议提供可靠的连接服务，连接是通过三次握手进行初始化的。三次握手的目的是同步连接双方的序列号和确认号并交换 TCP窗口大小信息。先来看图说话。

三次握手

第一次握手：建立连接。客户端发送连接请求报文段，将SYN位置为1，Sequence Number为x；然后，客户端进入SYN_SEND状态，等待服务器的确认；
第二次握手：服务器收到SYN报文段。服务器收到客户端的SYN报文段，需要对这个SYN报文段进行确认，设置Acknowledgment Number为x+1(Sequence Number+1)；同时，自己自己还要发送SYN请求信息，将SYN位置为1，Sequence Number为y；服务器端将上述所有信息放到一个报文段（即SYN+ACK报文段）中，一并发送给客户端，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN+ACK报文段。然后将Acknowledgment Number设置为y+1，向服务器发送ACK报文段，这个报文段发送完毕以后，客户端和服务器端都进入ESTABLISHED状态，完成TCP三次握手。
完成了三次握手，客户端和服务器端就可以开始传送数据。

四次分手

当客户端和服务器通过三次握手建立了TCP连接以后，当数据传送完毕，肯定是要断开TCP连接的啊。那对于TCP的断开连接，这里就有了神秘的“四次分手”。
第一次分手：主机1（可以使客户端，也可以是服务器端），设置Sequence Number和Acknowledgment Number，向主机2发送一个FIN报文段；此时，主机1进入FIN_WAIT_1状态；这表示主机1没有数据要发送给主机2了；
第二次分手：主机2收到了主机1发送的FIN报文段，向主机1回一个ACK报文段，Acknowledgment Number为Sequence Number加1；主机1进入FIN_WAIT_2状态；主机2告诉主机1，我也没有数据要发送了，可以进行关闭连接了；
第三次分手：主机2向主机1发送FIN报文段，请求关闭连接，同时主机2进入CLOSE_WAIT状态；
第四次分手：主机1收到主机2发送的FIN报文段，向主机2发送ACK报文段，然后主机1进入TIME_WAIT状态；主机2收到主机1的ACK报文段以后，就关闭连接；此时，主机1等待2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，主机1也可以关闭连接了。发送完毕之后，客户端进入等待状态，等待两个时间周期。关闭。
至此，TCP的四次分手就这么愉快的完成了。当你看到这里，你的脑子里会有很多的疑问，很多的不懂，感觉很凌乱；没事，我们继续总结。

为什么要三次握手

既然总结了TCP的三次握手，那为什么非要三次呢？怎么觉得两次就可以完成了。

为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。

举例如下：

“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”
这就很明白了，防止了服务器端的一直等待而浪费资源。

那四次分手又是为何呢？

TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP是全双工模式，这就意味着，当主机1发出FIN报文段时，只是表示主机1已经没有数据要发送了，主机1告诉主机2，它的数据已经全部发送完毕了；但是，这个时候主机1还是可以接受来自主机2的数据；当主机2返回ACK报文段时，表示它已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的；当主机2也发送了FIN报文段时，这个时候就表示主机2也没有数据要发送了，就会告诉主机1，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。

为什么四次分手TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态？

这是因为虽然双方都同意关闭连接了，而且握手的4个报文也都协调和发送完毕，按理可以直接回到CLOSED状态（就好比从SYN_SEND状态到ESTABLISH状态那样）；但是因为我们必须要假想网络是不可靠的，你无法保证你最后发送的ACK报文会一定被对方收到，因此对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文，而重发FIN报文，所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文。
1、  客户端的最后一个ACK报文在传输的时候丢失，服务器并没有接收到这个报文。这个候。
服务器就会超时重传这个FIN消息，然后客户端就会重新返回最后一个ACK报文，等待两个时间周期，完成关闭。如果不等待这两个时间周期，服务器重传的那条消息就不会收到。服务器就因为接收不到客户端的信息而无法正常关闭。
2、  预防上一次在三次握手中提到的失效的报文干扰。两个时间周期过去之后，所有的报文都会在网络中消失，保证下一次重新连接的时候有乱七八糟的报文影响。

TCP建立了连接，我们看看http是在TCP连接基础上进行请求的。

3.HTTP协议详解

HTTP是一个属于应用层的面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。它于1990年提出，经过几年的使用与发展，得到不断地完善和扩展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的规范化工作正在进行之中，而且HTTP-NG(Next Generation of HTTP)的建议已经提出。
HTTP协议的主要特点可概括如下：

1.支持客户/服务器模式。
2.简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
3.灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
4.无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
5.无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

HTTP协议之URL

http URL (URL是一种特殊类型的URI，包含了用于查找某个资源的足够的信息)的格式如下：
http://host[":"port][abs_path]
http表示要通过HTTP协议来定位网络资源；
host表示合法的Internet主机域名或者IP地址；
port指定一个端口号，为空则使用缺省端口 80；
abs_path指定请求资源的URI；如果URL中没有给出abs_path，那么当它作为请求URI时，必须以“/”的形式给出，通常这个工作浏览器自动帮我们完成。

如：

1、输入：www.guet.edu.cn
浏览器自动转换成：http://www.guet.edu.cn/
2、http:192.168.0.116:8080/index.jsp

HTTP协议之请求

http请求由三部分组成，分别是：请求行、消息报头、请求正文

Request 消息分为3部分，第一部分叫请求行， 第二部分叫http header, 第三部分是body. header和body之间有个空行， 结构如下图

请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本，格式如下：

Method Request-URI HTTP-Version CRLF

其中 Method表示请求方法；Request-URI是一个统一资源标识符；HTTP-Version表示请求的HTTP协议版本；CRLF表示回车和换行（除了作为结尾的CRLF外，不允许出现单独的CR或LF字符）。

请求方法（所有方法全为大写）有多种，各个方法的解释如下：

GET     请求获取Request-URI所标识的资源
POST    在Request-URI所标识的资源后附加新的数据
HEAD    请求获取由Request-URI所标识的资源的响应消息报头
PUT     请求服务器存储一个资源，并用Request-URI作为其标识
DELETE  请求服务器删除Request-URI所标识的资源
TRACE   请求服务器回送收到的请求信息，主要用于测试或诊断
CONNECT 保留将来使用
OPTIONS 请求查询服务器的性能，或者查询与资源相关的选项和需求

HEAD方法与GET方法几乎是一样的，对于HEAD请求的回应部分来说，它的HTTP头部中包含的信息与通过GET请求所得到的信息是相同的。利用这个方法，不必传输整个资源内容，就可以得到Request-URI所标识的资源的信息。该方法常用于测试超链接的有效性，是否可以访问，以及最近是否更新。

应用：
GET方法：在浏览器的地址栏中输入网址的方式访问网页时，浏览器采用GET方法向服务器获取资源

POST方法要求被请求服务器接受附在请求后面的数据，常用于提交表单。

当使用的是"GET" 方法的时候， body是为空的
比如我们打开博客园首页的request 如下

GET http://www.cnblogs.com/ HTTP/1.1
Host: www.cnblogs.com

我们用Fiddler 捕捉一个博客园登录的Request 然后分析下它的结构， 在Inspectors tab下以Raw的方式可以看到完整的Request的消息，   如下图

get和post：

根据HTTP规范，Get是向服务器发索取数据的一种请求（GET获取信息是安全的和幂等的），而Post是向服务器提交数据的一种请求。

在HTML中：

相同点：都可（带参数）以向服务器发送请求。GET和POST只是发送机制不同，严格是并不区分一个取一个发，但会根据情况考虑哪种方式更合适。

主要用于from表单的提交（html的默认提交方式为get而不是post），以及ajax获取数据。

不同点：

get是把参数数据队列加到提交表单的ACTION属性所指的URL中，值和表单内各个字段一一对应，在URL中可以看到。post是通过HTTP post机制，将表单内各个字段与其内容放置在HTML BODY中一起传送到ACTION属性所指的URL地址。用户看不到这个过程。
GET的URL会有长度上的限制，则POST的数据则可以非常大。
POST比GET安全，因为数据在地址栏上不可见。
get请求需注意缓存问题,post请求不需担心这个问题。
post请求必须设置Content-Type值为application/x-form-www-urlencoded
在客户端使用get请求时,服务器端使用Request.QueryString来获取参数,而客户端使用post请求时,服务器端使用Request.Form来获取参数.

建议：
1、get方式的安全性较Post方式要差些，包含机密信息的话，建议用Post数据提交方式；
2、在做数据查询时，建议用Get方式；而在做数据添加、修改或删除时，建议用Post方式，例如form中的内容；

不同点的解释：

在HTTP中：

1. GET和POST与数据如何传递没有关系

GET和POST是由HTTP协议定义的。在HTTP协议中，Method和Data（URL， Body， Header）是正交的两个概念，也就是说，使用哪个Method与应用层的数据如何传输是没有相互关系的。

HTTP没有要求，如果Method是POST数据就要放在BODY中。也没有要求，如果Method是GET，数据（参数）就一定要放在URL中而不能放在BODY中。
这只是HTML标准对HTTP协议的用法的约定。

2. HTTP协议对GET和POST都没有对长度的限制

HTTP协议明确地指出了，HTTP头和Body都没有长度的要求。而对于URL长度上的限制，有两方面的原因造成：

浏览器。据说早期的浏览器会对URL长度做限制。据说IE对URL长度会限制在2048个字符内。
服务器。URL长了，对服务器处理也是一种负担。多数服务器出于安全、稳定方面的考虑，会给URL长度加限制。但是这个限制是针对所有HTTP请求的，与GET、POST没有关系。

3.安全不安全和GET、POST没有关系

而且，现代的Web Server都是支持GET中包含BODY这样的请求。虽然这种请求不可能从浏览器发出，但是现在的Web Server又不是只给浏览器用，已经完全地超出了HTML服务器的范畴了。

HTTP协议之响应

在接收和解释请求消息后，服务器返回一个HTTP响应消息。

HTTP响应也是由三个部分组成，分别是：状态行、消息报头、响应正文

第一部分叫request line, 第二部分叫request header，第三部分是body. header和body之间也有个空行，  结构如下图

状态行格式如下：

HTTP-Version Status-Code Reason-Phrase CRLF

其中，HTTP-Version表示服务器HTTP协议的版本；Status-Code表示服务器发回的响应状态代码；Reason-Phrase表示状态代码的文本描述。
状态代码有三位数字组成，第一个数字定义了响应的类别，且有五种可能取值：

1xx：指示信息--表示请求已接收，继续处理
2xx：成功--表示请求已被成功接收、理解、接受
3xx：重定向--要完成请求必须进行更进一步的操作
4xx：客户端错误--请求有语法错误或请求无法实现
5xx：服务器端错误--服务器未能实现合法的请求

常见状态代码、状态描述、说明：

200 OK      //客户端请求成功
400 Bad Request  //客户端请求有语法错误，不能被服务器所理解
401 Unauthorized //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用
403 Forbidden  //服务器收到请求，但是拒绝提供服务
404 Not Found  //请求资源不存在，eg：输入了错误的URL
500 Internal Server Error //服务器发生不可预期的错误
503 Server Unavailable  //服务器当前不能处理客户端的请求，一段时间后可能恢复正常
eg：HTTP/1.1 200 OK （CRLF）

我们用Fiddler 捕捉一个博客园首页的Response然后分析下它的结构， 在Inspectors tab下以Raw的方式可以看到完整的Response的消息，   如下图

HTTPS协议：

HTTPS应用了Netscape的安全套接字层（SSL）作为HTTP应用层的子层。SSL协议位于TCP/IP协议与各种应用层协议之间，为数据通讯提供安全支持。SSL协议可分为两层： SSL记录协议（SSL Record Protocol）：它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。 SSL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。

SSL协议通信过程

(1) 浏览器发送一个连接请求给服务器;服务器将自己的证书(包含服务器公钥S_PuKey)、对称加密算法种类及其他相关信息返回客户端;
(2) 客户端浏览器检查服务器传送到CA证书是否由自己信赖的CA中心签发。若是，执行4步;否则，给客户一个警告信息：询问是否继续访问。
(3) 客户端浏览器比较证书里的信息，如证书有效期、服务器域名和公钥S_PK，与服务器传回的信息是否一致，如果一致，则浏览器完成对服务器的身份认证。
(4) 服务器要求客户端发送客户端证书(包含客户端公钥C_PuKey)、支持的对称加密方案及其他相关信息。收到后，服务器进行相同的身份认证，若没有通过验证，则拒绝连接;
(5) 服务器根据客户端浏览器发送到密码种类，选择一种加密程度最高的方案，用客户端公钥C_PuKey加密后通知到浏览器;
(6) 客户端通过私钥C_PrKey解密后，得知服务器选择的加密方案，并选择一个通话密钥key，接着用服务器公钥S_PuKey加密后发送给服务器;
(7) 服务器接收到的浏览器传送到消息，用私钥S_PrKey解密，获得通话密钥key。
(8) 接下来的数据传输都使用该对称密钥key进行加密。
上面所述的是双向认证 SSL 协议的具体通讯过程，服务器和用户双方必须都有证书。由此可见，SSL协议是通过非对称密钥机制保证双方身份认证，并完成建立连接，在实际数据通信时通过对称密钥机制保障数据安全性

https是一个安全通信通道，它基于HTTP开发，用于在客户计算机和服务器之间交换信息。它使用安全套接字层(SSL)进行信息交换，简单来说它是HTTP的安全版。

二者的区别：

协议基础不同：Https在Http下加入了SSL层。http是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl加密传输协议
通讯方式不同：Https在数据通信之前需要客户端、服务器进行握手(身份认证)，建立连接后，传输数据经过加密，通信端口443。
https协议需要到ca申请证书，一般免费证书很少，需要交费。
http的连接很简单,是无状态的

4.从实际上的数据应用来说http的过程

在前面客户端和应用服务器建立TCP连接之后，就需要用http协议来传送数据了，HTTP协议简单来说，还是请求，确认，连接。
总体就是C发送一个HTTP请求给S，S收到了这个http请求，然后返回给Chttp响应，然后C的中间件或者说浏览器把这些数据渲染成为了网页，展示在用户面前。
第一：发送一个http请求给S，这个请求包括请求头和请求内容：
request header：
包括了，1.请求的方法是POST/GET,请求的URL，http协议版本2.请求的数据，和编码方式3是否有cookie和cooies，是否缓存等。
post和get请求方式的区别是，get把请求内容放在URL后面，但是URL长度有限制。而post是以表单的形势，适合要输入密码之类的，因为不在URL中显示，所以比较安全。
request body：
即请求的内容.
第二：S收到了http请求，然后根据请求头，返回http响应。
response header:包括了1.cookies或者sessions2.状态吗3.内容大小等
response body：
即响应的内容，包括，JS什么的。
第三，C收到了以后，就由浏览器完成一系列的渲染，包括执行JS脚本等。
这就是我所理解的webTCP,HTTP基础知识，待续。。。。。

例如：

在上图中，可清晰的看到客户端浏览器（ip为192.168.2.33）与服务器的交互过程：
1）No1：浏览器（192.168.2.33）向服务器（220.181.50.118）发出连接请求。此为TCP三次握手第一步，此时从图中可以看出，为SYN，seq:X （x=0）
2）No2：服务器（220.181.50.118）回应了浏览器（192.168.2.33）的请求，并要求确认，此时为：SYN，ACK，此时seq：y（y为0），ACK：x+1（为1）。此为三次握手的第二步；
3）No3：浏览器（192.168.2.33）回应了服务器（220.181.50.118）的确认，连接成功。为：ACK，此时seq：x+1（为1），ACK：y+1（为1）。此为三次握手的第三步；
4）No4：浏览器（192.168.2.33）发出一个页面HTTP请求；
5）No5：服务器（220.181.50.118）确认；
6）No6：服务器（220.181.50.118）发送数据；
7）No7：客户端浏览器（192.168.2.33）确认；
8）No14：客户端（192.168.2.33）发出一个图片HTTP请求；
9）No15：服务器（220.181.50.118）发送状态响应码200 OK
……

二.浏览器是怎样渲染HTML的（渲染引擎，HTML解析）

1.渲染引擎

渲染引擎的职责是……渲染，也就是把请求的内容显示到浏览器屏幕上。

默认情况下渲染引擎可以显示HTML，XML文档以及图片。 通过插件（浏览器扩展）它可以显示其它类型文档。比如使用PDF viewer插件显示PDF文件。我们专注渲染引擎的主要用途——显示用CSS格式化的HTML与图片。

各种渲染引擎
我们提到的Firefox, Safari两种浏览器构建于两种渲染引擎之上：Firefox使用Gecko —— Mozilla自家的渲染引擎；Safari 和 Chrome 都使用 Webkit。

2.渲染引擎的基本工作流程

解析ＨＴＭＬ
构建ＤＯＭ树
渲染树构建
渲染树布局
绘制渲染树

渲染引擎开始于从网络层获取请求内容，一般是不超过8Ｋ的数据块。接下来就是渲染引擎的基本工作流程：

渲染引擎会解析ＨＴＭＬ文档并把标签转换成内容树中的ＤＯＭ节点。它会解析style元素和外部文件中的样式数据。样式数据和ＨＴＭＬ中的显示控制将共同用来创建另一棵树——渲染树。
渲染树包含带有颜色，尺寸等显示属性的矩形。这些矩形的顺序与显示顺序一致。
渲染树构建完成后就是”布局”处理，也就是确定每个节点在屏幕上的确切显示位置。 下一个步骤是”绘制” —— 遍历渲染树并用ＵＩ后端层将每一个节点绘制出来。
一定要理解这是一个缓慢的过程，为了更好的用户体验，渲染引擎会尝试尽快的把内容显示出来。它不会等到所有ＨＴＭＬ都被解析完才创建并布局渲染树。它会在处理后续内容的同时把处理过的局部内容先展示出来。

主要流程示例

Webkit主要流程

Mozilla的Gecko渲染引擎主要流程

从上可以看出，尽管Webkit与Gecko使用略微不同的术语，这个过程还是基本相同的。
Gecko 里把格式化好的可视元素称做“帧树”（Frame tree）。每个元素就是一个帧（frame）。 Webkit 则使用”渲染树”这个术语，渲染树由”渲染对象”组成。Webkit 里使用”layout”表示元素的布局，Gecko则称为”Reflow”。Webkit使用”Attachment”来连接DOM节点与可视化信息以构建渲染树。一个非语义上的小差别是Gecko在ＨＴＭＬ与ＤＯＭ树之间有一个附加的层 ，称作”content sink”，是创建ＤＯＭ对象的工厂。

3.解析

解析一个文档意味着把它翻译成有意义的结构以供代码使用。解析的结果通常是一个表征文档的由节点组成的树，称为解析树或句法树。

以下是编译原理知识。这里只作一般性介绍，为下面的HTML解析打基础。

语法

解析是基于文档所遵循的语法规则——书写所用的语言或格式——来进行的。每一种可以解析的格式必须由确定的语法与词汇组成。这被称之为上下文无关语法。 人类语言并非此种语言，所以不能用常规的解析技术来解析。
解析器——词法分析器组合
解析器有两个处理过程——词法分析与句法分析。
词法分析负责把输入切分成符号序列，符号是语言的词汇——由该语言所有合法的单词组成。
句法分析是对该语言句法法则的应用。
解析器通常把工作分给两个组件——分词程序负责把输入切分成合法符号序列，解析程序负责按照句法规则分析文档结构和构建句法树。词法分析器知道如何过滤像空格，换行之类的无关字符。

从源文档到解析树（文档，词法分析，句法分析，解析树）。
解析过程是交互式的。解析器通常会从词法分析器获取新符号并尝试匹配句法规则。如果匹配成功，就在句法树上创建相应的节点，并继续从词法分析器获取下一个符号。如果没有匹配的规则，解析器会内部保存这个符号，并继续从词法分析器获取符号，直到内部保存的所有符号能够成功匹配一个规则。如果最终无法匹配，解析器会抛出异常。这意味着文档无效，含有句法错误。

转换

多数情况下解析树并非最终结果。解析经常是为了从输入文档转换成另外一种格式。比如编译器要把源码编译成机器码，会首先解析成解析树，再把解析树转换成机器码。

编译过程（源码，解析，解析树，转换，机器码）。

我们说过常规解析器只能解析上下文无关语法的语言。这种语言的一个直觉的定义是它的句法可以用BNF完整的表达。

解析器的类型
解析器有两种基本类型——自上而下解析器和自下而上解析器。主观上可以认为自上而下的解析器从上层句法结构开始尝试匹配句法；自下而上的则从输入开始，慢慢转换成句法规则，从底层规则开始，直到上层规则全部匹配。

4.HTML解析器

ＨＴＭＬ解析器的工作是解析ＨＴＭＬ标记到解析树。

HTML的定义使用DTD文件。这种格式用来定义SGML族语言，它包含对所有允许的元素的定义，包括它们的属性和层级关系。如我们前面所说，HTML DTD构不成上下文无关语法。
DTD有几种不同类型。严格模式完全尊守规范，但其它模式为了向前兼容可能包含对早期浏览器所用标签的支持。

DOM

解析器输出的树是由ＤＯＭ元素和属性节点组成的。DOM的全称为：Document Object Model。它是ＨＴＭＬ文档的对象化描述，也是ＨＴＭＬ元素与外界（如Javascript）的接口。
ＤＯＭ与标签几乎有着一一对应的关系，如下面的标签
<html>
    <body>
        <p>
            Hello World
        </p>
        <div> <img src="example.png"/></div>
    </body>
</html>
会被转换成如的ＤＯＭ树：

与HTML一样，DOM规范也由w3c组织制订。
当我们说树中包含ＤＯＭ节点时，意思就是这个树是由实现了ＤＯＭ接口的元素组成。这些实现包含了其它一些浏览器内部所需的属性。

HTML解析

如我们前面看到的，HTML无法使用自上而下或自下而上的解析器来解析。
理由如下：
语言的宽容特点

浏览器需要对无效HTML提供容错性的事实。
解析过程的反复。通常解析过程中源码不会变化。但在HTML中，script标签包含”document.write”时可以添加内容，即解析过程实际上还会改变源码。

浏览器创建了自己的解析器来解析HTML文档。
HTML5规范里对解析算法有具体的说明，解析由两部分组成：分词与构建树。
分词属于词法分析部分，它把输入解析成符号序列。在HTML中符号就是开始标签，结束标签，属性名称和属生值。
分词器识别这些符号并将其送入树构建者，然后继续分析处理下一个符号，直到输入结束。

HTML解析流程 (源自HTML5规范)

分词算法

算法的输出是HTML符号。算法可以用状态机来描述。 每一个状态从输入流中消费一个或多个字符，并根据它们更新下一状态。决策受当前符号状态和树的构建状态影响。这意味着同样的字符可能会产生不同的结果，取决于当前的状态。用一个例子来看看它的原理。

基础示例，分析下面的标签:
<html>
    <body>
        Hello world
    </body>
</html>
初始状态是”Data state”，当遇到”<“时状态改为“Tag open state”。吃掉”a-z”字符组成的符号后产生了”Start tag token”，状态变更为“Tag name state”。我们一直保持此状态，直到遇到”>”。每个字符都被追加到新的符号名上。在我们的例子中，解出的符号就是”html”。

当碰到”>”时，当前符号完成，状态改回“Data state”。”<body>”标签将会以同样的方式处理。现在”html”与”body”标签都完成了，我们回到“Data state”状态。吃掉”H”（”Hello world”第一个字母）时会产生一个字符符号，直到碰到”</body>”的”<“符号，我们就完成了一个字符符号”Hello world”。

现在我们回到“Tag open state”状态。吃掉下一个输入”/”时会产生一个”end tag token”并变更为“Tag name state”状态。同样，此状态保持到我们碰到”>”时。这时新标签符号完成，我们又回到“Data state”。同样”</html>”也会被这样处理。

树的构建算法

当解析器被创建时，文档对象也被创建了。在树的构建过程中DOM树的根节点（Documen）将被修改，元素被添加到上面去。每个分词器完成的节点都会被树构建器处理。规范中定义了每一个符号与哪个DOM对象相关。除了把元素添加到DOM树外，它还会被添加到一个开放元素堆栈。这个堆栈用于纠正嵌套错误和标签未关闭错误。这个算法也用状态机描述，它的状态叫做”insertion modes”。

让我们看看下面输入的树构建过程：
<html>
    <body>
        Hello world
    </body>
</html>
树的构建过程中，输入就是分词过程中得到的符号序列。第一个模式叫“initial mode”。接收 html 符号后会变成“before html”模式并重新处理此模式中的符号。这会创建一个HTMLHtmlElement元素并追加到根文档节点。

然后状态改变为“before head”。我们收到”body”时，会隐式创建一个HTMLHeadElement，尽管我们没有这个标签，它也会被创建并添加到树中。

现在我们进入“in head”模式，然后是“after head”，Body会被重新处理，创建HTMLBodyElement元素并插入，然后进入“in body”模式。

字符符号”Hello world”收到后会创建一个”Text”节点，所有字符都被一一追加到上面。

收到body结束标签后进入 “after body” 模式，收到html结束标签后进入“after after body”模式。所有符号处理完后将终止解析。

解析结束后的动作

在这一阶段浏览器会把文档标记为交互模式，并开始解析deferred模式的script。”deferred”意味着脚本应该在文档解析完成后执行。脚本处理完成后将进入”complete”状态，”load”事件发生。
HTML5规范中包含了完整的算法： http://www.w3.org/TR/html5/syntax.html#html-parser

浏览器的容错

你永远不会看到HTML页面语法错误。浏览器会修正错误并继续。

三.HTML页面的加载整体流程

从浏览器地址栏的请求链接开始，浏览器通过DNS解析查到域名映射的IP地址，成功之后浏览器端向此IP地址取得连接，成功连接之后，浏览器端将请 求头信息 通过HTTP协议向此IP地址所在服务器发起请求，服务器接受到请求之后等待处理，最后向浏览器端发回响应，此时在HTTP协议下，浏览器从服务器接收到 text/html类型的代码，浏览器开始显示此html，并获取其中内嵌资源地址，然后浏览器再发起请求来获取这些资源，并在浏览器的html中显示。

用户输入网址（假设是个html页面，并且是第一次访问），浏览器向服务器发出请求，服务器返回html文件；
下载的顺序是从上到下，渲染的顺序也是从上到下，下载和渲染是同时进行的。
浏览器开始载入html代码，发现<head>标签内有一个<link>标签引用外部CSS文件；
浏览器继续载入html中<body>部分的代码，并且CSS文件已经拿到手了，可以开始渲染页面了；
如果遇到语义解释性的标签嵌入文件（JS脚本，CSS样式），下载过程会启用单独连接进行下载。并且在下载后进行解析，解析过程中，停止页面所有往下元素的下载，不能并行下载和解析。样式表在下载完成后，将和以前下载的所有样式表一起进行解析，解析完成后，将对此前所有元素（含以前已经渲染的）重新进行渲染。js也不能并行下载和解析
浏览器继续载入html中<body>部分的代码，并且CSS文件已经拿到手了，可以开始渲染页面了；
浏览器在代码中发现一个<img>标签引用了一张图片，向服务器发出请求。此时浏览器不会等到图片下载完，而是继续渲染后面的代码；
服务器返回图片文件，由于图片占用了一定面积，影响了后面段落的排布，因此浏览器需要回过头来重新渲染这部分代码；
浏览器发现了一个包含一行Javascript代码的<script>标签，赶快运行它；
Javascript脚本执行了这条语句，它命令浏览器隐藏掉代码中的某个<div> （style.display=”none”）。浏览器不得不重新渲染这部分代码；
直到运行到</html>。
还没完，通过操作页面运行Javascript代码，改变了DOM或样式，浏览器重新来过，向服务器请求资源文件，重新渲染页面。

-------------------------------------------------------------------------------------------------------------------------------------

完

转载需注明转载字样，标注原作者和原博文地址。

更多阅读：

http://jingyan.baidu.com/article/2fb0ba4048e15500f3ec5f7e.html

http://www.jellythink.com/archives/705

http://www.cnblogs.com/jtome/archive/2008/12/04/1347864.html

http://www.cnblogs.com/li0803/archive/2008/11/03/1324746.html

http://www.chinaz.com/news/2012/0509/250601.shtml

http://wenku.baidu.com/link?url=u9QspfeUFh2SDo8sa8k-_VCdEUP-7QFNYEaKTFi_94ZLowEcdUEgVNnl8Or4bfc2XMaM1wHHQ7ddW7StfFJhiRqi9uTmlX6TJIqpF0Uyqpq

http://kb.cnblogs.com/page/130970/