浏览器之URL加载

1. 前言

每次发博客之前都总先说点废话，哈哈哈！！！

一直对这个问题有所耳闻，但也没有真正的深究过，今年打算换个工作，在准备面试的过程中再次遇见这个问题（哈哈哈，毕竟是经久不衰的经典面试题），这次深入的了解一下，一方面为了面试，一方面也是借这个机会扩展一下自己的知识。

有不足指出希望大家指出。

2. 大致流程

1. 在浏览器地址栏输入URL并按下回车；
2. 解析URL, 通过DNS查找IP;
3. TCP连接，三次握手；
4. 获取HTML页面
5. 页面渲染；
6. TCP断开，四次挥手；

3. 解析URL, 通过DNS查找IP

3.1. DNS解析大致流程

1. 浏览器缓存中查找；
2. 在本机hosts文件中查找；
3. 在本地DNS缓存和本地DNS服务器中查找；
4. 在本地没有找到就查询根DNS服务器 > 顶级DNS服务器 > 权限域名服务器，直到找到域名对应的IP地址。
   盗一张网上的图，这个图片描述的太清晰了，棒！！！
   

3.2. DNS解析方式

DNS解析方式有两种：迭代方式、递归方式。

3.2.1. 迭代方式

1. 本地DNS服务器查询根DNS服务器，如果查到，解析结束，否则继续查询；
2. 本地DNS服务器查询顶级DNS服务器，如果查到，解析结束，否则继续查询；
3. 本地DNS服务器查询权限DNS服务器，权限DNS把IP地址返回给本地DNS服务器；
4. 本地DNS服务器返回IP地址给客户端；
   

3.2.2. 递归方式

1. 本地DNS服务器查询根DNS服务器，如果查到会直接返回查询结果，否则继续向下查看；
2. 根DNS服务器查询顶级DNS服务器，如果查到会将结果返回顺序：顶级DNS服务器 > 根DNS服务器 > 本地DNS服务器。如果没有查到继续向下查看；
3. 顶级DNS服务器查询权限DNS服务器，查到会将结果返回顺序：权限DNS服务器 > 顶级DNS服务器 > 根DNS服务器 > 本地DNS服务器。
   

4. TCP连接，三次握手

1. 第一次握手：
   Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。

2. 第二次握手：
   Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态。

3. 第三次握手：
   Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了。
   

4.1 为什么需要三次握手呢？

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

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

5. 获取HTML页面

查看浏览器缓存中是否存在html文件，如果有直接返回，如果没有去后端请求。

浏览器缓存机制：https://blog.csdn.net/qq_36968599/article/details/114556906

6. 页面渲染

服务器收到请求之后会返回响应头和HTML内容给客服端，浏览器收到响应数据后，开始解析HTML。

1. 生成DOM树；
2. 生成CSSOM树；
3. 把DOM树和CSSOM树合成渲染树；
4. 在渲染树上进行布局计算，确定节点的尺寸和位置；
5. 绘制；
6. 回流和重绘；

6.1. 生成DOM树

DOM树描述了文档内容和结构，从跟节点元素开始自上而下进行解析。树反映了不同节点之间的关系和层次结构，DOM树节点数量越多，构建DOM树的时间越长。
HTML是解析一部分就会显示一部分的。

解析器从根节点进行解析如果遇到非阻塞资源连接（例如：<link>，<img>）时，浏览器会请求资源并且继续向下解析；如果遇到阻塞资源（例如，<script>）时，会阻塞渲染并停止HTML解析。浏览器通过预加载扫描器优化了这个过程。

6.1.1. 预加载扫描器

构建DOM树时，预加载扫描器会解析内容预先请求资源，以便在解析器在解析到对资源的引用时，资源已经被运行或者下载了。

• 使用内联CSS样式，可以省略请求资源的步骤提高速度，但是没有必要降低可维护性来提高这点速度。
• 等待获取CSS不会阻塞HTML的解析或者下载，但是它的确阻塞JavaScript，因为JavaScript经常用于查询元素的CSS属性。

6.2. 生成CSSOM树

处理外部CSS的时候会创建和DOM树相似的CSSOM树，用来描述对文档应用的样式规则。构建CSSOM的速度非常快。

6.3 合成渲染树

构建完DOM树和CSSOM树之后，浏览器只是拥有两个相互独立的数据对象，DOM树描述文本内容和结构，CSSOM树描述了对文档应用的样式规则。想要渲染出页面就要将DOM树和CSSOM树组合在一起，这就是渲染树。

Render树保存所有具有内容和计算样式的可见节点——将所有相关样式匹配到DOM树中的每个可见节点，并根据CSS级联确定每个节点的计算样式。
盗图

像和它的子节点以及任何具有display: none样式的结点，例如script { display: none; }（在user agent stylesheets可以看到这个样式）这些标签将不会显示，也就是它们不会出现在Render树上。具有visibility: hidden的节点会出现在Render树上，因为它们会占用空间。

6.4. 布局

布局是确定呈现树中所有节点的宽度、高度和位置，以及确定页面上每个对象的大小和位置的过程。

渲染树标识显示哪些节点（即使不可见）及其计算样式，但不标识每个节点的尺寸或位置。为了确定每个对象的确切大小和位置，浏览器从渲染树的根开始遍历它。

6.5. 渲染

最后一步是将各个节点绘制到屏幕上。

6.6. 回流和重绘

当页面继续加载资产时，可能会发生回流（回想一下我们迟到的示例图像），回流会触发重新绘制和重新组合。如果我们定义了图像的大小，就不需要重新绘制，只需要重新绘制需要重新绘制的层，并在必要时进行合成。但我们没有包括图像大小！从服务器获取图像后，渲染过程将返回到布局步骤并从那里重新开始。

6.7 参考地址

1. 浏览器渲染原理与过程： https://www.jianshu.com/p/e6252dc9be32

7. TCP断开，四次挥手

由于TCP连接时全双工的，因此，每个方向都必须要单独进行关闭，这一原则是当一方完成数据发送任务后，发送一个FIN来终止这一方向的连接，收到一个FIN只是意味着这一方向上没有数据流动了，即不会再收到数据了，但是在这个TCP连接上仍然能够发送数据，直到这一方向也发送了FIN。首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭。

1. 第一次挥手：
   Client发送一个FIN，seq=x，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。

2. 第二次挥手：
   Server收到FIN后，发送一个ACK给Client，ack=x+1, seq=y（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。

3. 第三次挥手：
   Server发送一个FIN, ack=x+1, seq=n，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。

4. 第四次挥手：
   Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，ack=n+1，Server进入CLOSED状态，完成四次挥手。

盗一张网上的图

7.1 为什么需要四次挥手呢？

TCP是全双工模式，当client发出FIN报文段时，只是表示client已经没有数据要发送了，client告诉server，它的数据已经全部发送完毕了；但是，这个时候client还是可以接受来server的数据；当server返回ACK报文段时，表示它已经知道client没有数据发送了，但是server还是可以发送数据到client的；当server也发送了FIN报文段时，这个时候就表示server也没有数据要发送了，就会告诉client，我也没有数据要发送了，如果收到client确认报文段，之后彼此就会愉快的中断这次TCP连接。

8. TCP报文字段解释

上图中有几个字段需要重点介绍下：

1. 序号：Seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。
2. 确认序号：Ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，Ack=Seq+1。
3. 标志位：共6个，即URG、ACK、PSH、RST、SYN、FIN等，具体含义如下：
   （A）URG：紧急指针（urgent pointer）有效。
   （B）ACK：确认序号有效。
   （C）PSH：接收方应该尽快将这个报文交给应用层。
   （D）RST：重置连接。
   （E）SYN：发起一个新连接。
   （F）FIN：释放一个连接。

需要注意的是：
（A）不要将确认序号Ack与标志位中的ACK搞混了。
（B）确认方Ack=发起方Seq+1，两端配对。

9. 参考链接

1. https://www.huaweicloud.com/articles/331e73c5039a43c6a2cb2db069a5c9e2.html