前端-从输入url到页面渲染

从输入url到页面加载发生了什么

互联网：好比地球上众横交错的道路。
网络连接：道路通到了村子路口。从此，村子里的苹果就可以运出去卖了。
TCP/IP：为了将村里的苹果能规范有效的运卖出去而不出问题，村长作出如下规定：“用规格刚好 20 cm * 20 cm * 20 cm 的泡沫箱来装，之后外面又用相应规格的纸箱包裹上，最后打上透明胶”。并且要求，对方收到时，一定要外包装完好，不然就会补发。而且还给对方发了一张发货单，明确说明了，苹果有多少，是用什么方法包装的，只有货和发货单对上了，对方才会确认收货。
DNS：突然一天，郭德纲想吃苹果，就跟于谦说，“我听说盘溪新村（域名）的苹果好，要他们那个套餐一选项啊！”，于谦一听，得，也不知道盘溪新村在哪，打开地图查（DNS）吧，一查，好嘛，江苏省苏州市（IP 地址），于是于谦去了苏州，找了村子，告诉村长，要套餐一，要用顺丰快递，并且留下了北京德云社的地址。
HTTP：过了几天，德云社的人一看，有快递来了，来了这么一句，“只收‘顺丰’，拒收其他快递”。司机忙说，“是顺丰，是顺丰”，这才对上暗号，德云社的人收下了货。
组成文件：送来的货可不止一车，而且也不止一种苹果，这车是红富士，那车黄富士的。
代码：有点像，村长事先安排的说明书，让司机到了地方，如何卸车，货放到什么位置，而德云社的看说明书，知道什么样的苹果放到什么位置上，什么样苹果如何食用最佳，等等。
资源：不同种类的苹果。

到底发生了什么？

当你在浏览器里输入一个网址时（在我们的例子里就是走向商店的路上时）：

1. 浏览器在域名系统（DNS）服务器上找出存放网页的服务器的实际地址（找出商店的位置）。
2. 浏览器发送 HTTP 请求信息到服务器来请拷贝一份网页到客户端（你走到商店并下订单）。
3. 这条消息，包括其他所有在客户端和服务器之间传递的数据都是通过互联网使用 TCP/IP 协议传输的。
4. 服务器同意客户端的请求后，会返回一个“200 OK”信息，意味着“你可以查看这个网页，给你～”，然后开始将网页的文件以数据包的形式传输到浏览器（商店给你商品，你将商品带回家）。
5. 浏览器将数据包聚集成完整的网页然后将网页呈现给你（商品到了你的门口 —— 新东西，好棒！）。

总览
3. 浏览器地址栏输入URL并回车
4. 浏览器查找当前URL是否存在缓存，并比较缓存是否过期
5. DNS解析URL对应的IP
6. 根据IP建立TCP连接（三次握手）
7. 发送HTTP请求
8. 服务器处理请求，浏览器接受HTTP响应
9. 浏览器解析并渲染页面
10. 关闭TCP连接（四次挥手）

浏览器获取html，解析，渲染

过程如下

解析HTML,生成DOM树
解析CSS,生成CSS规则树
合并CSS和DOM数，生成render树
布局render树（layout/reflow），负责各元素尺寸、位置的计算
绘制render树（paint），绘制页面像素信息
浏览器将各层信息发送给GPU，GPU将各层合成，显示在屏幕上

HTML解析，构建DOM

Bytes → characters → tokens → nodes → DOM
Conversion转换：浏览器将获得的HTML内容（Bytes）基于他的编码转换为单个字符

Tokenizing分词：浏览器按照HTML规范标准将这些字符转换为不同的标记token。每个token都有自己独特的含义以及规则集

Lexing词法分析：分词的结果是得到一堆的token，此时把他们转换为对象，这些对象分别定义他们的属性和规则

DOM构建：因为HTML标记定义的就是不同标签之间的关系，这个关系就像是一个树形结构一样 例如：body对象的父节点就是HTML对象，然后段略p对象的父节点就是body对象

生成CSSOM树

过程同上

构建渲染树

一般来说，渲染树和DOM树相对应的，但不是严格意义上的一一对应

因为有一些不可见的DOM元素不会插入到渲染树中，如head这种不可见的标签或者display: none等

渲染

计算CSS样式

构建渲染树

布局（回流，Layout，Reflow)，主要定位坐标和大小，是否换行，各种position overflow z-index属性

绘制(重绘，Repaint），将图像绘制出来

回流与重绘

Layout，也称为Reflow，即回流。一般意味着元素的内容、结构、位置或尺寸发生了变化，需要重新计算样式和渲染树
Repaint，即重绘。意味着元素发生的改变只是影响了元素的一些外观之类的时候（例如，背景色，边框颜色，文字颜色等），此时只需要应用新样式绘制这个元素就可以了
什么会引起回流
1.页面渲染初始化

2.DOM结构改变，比如删除了某个节点

3.render树变化，比如减少了padding

4.窗口resize

5.最复杂的一种：获取某些属性，引发回流， 很多浏览器会对回流做优化，会等到数量足够时做一次批处理回流， 但是除了render树的直接变化，当获取一些属性时，浏览器为了获得正确的值也会触发回流，这样使得浏览器优化无效，包括

（1）offset(Top/Left/Width/Height) 
(2) scroll(Top/Left/Width/Height) 
(3) cilent(Top/Left/Width/Height) 
(4) width,height 
(5) 调用了getComputedStyle()或者IE的currentStyle

元素几何属性变化，margin,padding,height,width,border
回流一定伴随着重绘，重绘却可以单独出现

优化方案

减少逐项更改样式，最好一次性更改style，或者将样式定义为class并一次性更新
避免循环操作dom，创建一个documentFragment或div，在它上面应用所有DOM操作，最后再把它添加到window.document
（1）DocumentFragment 节点不属于文档树，继承的 parentNode 属性总是 null。不过它有一种特殊的行为，该行为使得它非常有用，即当请求把一个 DocumentFragment 节点插入文档树时，插入的不是 DocumentFragment 自身，而是它的所有子孙节点。这使得 DocumentFragment 成了有用的占位符，暂时存放那些一次插入文档的节点。它还有利于实现文档的剪切、复制和粘贴操作。其实他就是一个游离在DOM树外面的容器，所以你在把它插入文档节点之前，随便给他增删节点都不会引起回流
（2）使用display:none,只引发两次回流和重绘。道理跟上面的一样。因为display:none的元素不会出现在render树
（3）使用cloneNode和replaceChild技术，引发一次回流和重绘（这条其实没太明白）
避免多次读取offset等属性。无法避免则将它们缓存到变量
将复杂的元素绝对定位或固定定位，使得它脱离文档流，否则回流代价会很高
尽量不要使用表格布局，如果没有定宽表格一列的宽度由最宽的一列决定，那么很可能在最后一行的宽度超出之前的列宽，引起整体回流造成table可能需要多次计算才能确定好其在渲染树中节点的属性，通常要花3倍于同等元素的时间。

三次握手

（1）第一次握手：建立连接。客户端发送连接请求报文段，将SYN位置1，序列号seq（sequence number）为x；然后，客户端进入SYN_SEND状态，等待服务器的确认。

（2）第二次握手：服务器收到SYN报文段服务器收到客户端的SYN报文段，需要对这个SYN报文段进行确认，ACK位置1，确认号ack（acknowledgement number）为x+1；同时，自己还要发送SYN请求信息，将SYN位置1，序列号seq为y；服务器将上述SYN+ACK报文段一并发送给客户端，此时服务器进入SYN_RECV状态

（3）第三次握手：客户端收到服务器的SYN+ACK报文段：然后将确认号ack设置为y+1，向服务器发送ACK报文段。这个报文段发送完毕后，客户端和服务器都进入ESTABLISHED状态，完成TCP三次握手，之后可以开始传数据 ！

断开TCP连接（四次挥手）

第一次挥手是浏览器发完数据后，发送FIN请求断开连接。
第二次挥手是服务器发送ACK表示同意，如果在这一次服务器也发送FIN请求断开连接似乎也没有不妥，但考虑到服务器可能还有数据要发送，所以服务器发送FIN应该放在第三次挥手中。
这样浏览器需要返回ACK表示同意，也就是第四次挥手
注：

为什么服务器在接到断开请求时不立即同意断开：当服务器收到断开连接的请求时，可能仍然有数据未发送完毕，所有服务器先发送确认信号，等所有数据发送完毕后再同意断开。

第四次握手后，主机发送确认信号后并没有立即断开连接，而是等待了 2 个报文传送周期，原因是：如果第四次握手的确认信息丢失，服务器将会重新发送第三次握手的断开连接的信号，而服务器发觉丢包与重新发送的断开连接到达主机的时间正好为 2 个报文传输周期。