浅谈浏览器解析 URL+DNS 域名解析+TCP 三次握手与四次挥手+浏览器渲染页面

（1）浏览器解析 URL

为了能让我们的知识层面看起来更有深度，我们应该考虑下面两个问题了：

• 从浏览器输入 URL 到渲染成功的过程中，究竟发生了什么？
• 浏览器渲染过程中，发生了什么，是不是也有重绘与回流？

OK，兴致来了，我们就先从 浏览器解析 URL 看起，先来看看当用户输入 URL，到浏览器呈现给用户页面，经历了以下过程：

• 版本 A：

1. 用户输入 URL 地址。
2. 对 URL 地址进行 DNS 域名解析。
3. 建立 TCP 连接（三次握手）。
4. 浏览器发起 HTTP 请求报文。
5. 服务器返回 HTTP 响应报文。
6. 关闭 TCP 连接（四次挥手）。
7. 浏览器解析文档资源并渲染页面。

讲到这里，突然想起一个对话：

学生：“老师，这门课的考试重点是什么？”

老师：“全都是重点！”

enm…老师会不会被打我不知道，但是 jsliang 这样写会被怼我就清楚，所以，咱还是结合上面的图，进一步勾勒我们的结构：

很好，jsliang 感觉自己的画图技术又进了一步~

①：虽然很感激网上有那么多的文章可以参考，但是在我查了二十来篇文章后，jsliang 觉得这部分十有八九有问题撒，问了些小伙伴，它们有的说对，有的说错。不过，不妨碍小伙伴们继续往下看哈。
②：为了避免出篓子，下面贴出另外一个版本，小伙伴们可以在评论区说出你支持哪个版本哈：

• 版本 B

1. 用户输入 URL 地址。
2. 对 URL 地址进行 DNS 域名解析。
3. 进行 TCP 连接。
4. 进行 HTTP 报文的请求与响应。
5. 浏览器解析文档资源并渲染页面。

在这里我们可以清晰的了解到从 用户输入 URL，到浏览器呈现给用户页面，经历了哪些过程。

那么剩下的就简单了：

1. 什么是 DNS 解析，它是怎么个流程？
2. 什么是 TCP 三次握手，什么是 TCP 四次挥手，它们的流程是怎样的？
3. 浏览器解析文档资源并渲染页面是个怎样的流程？

Let’s go~ 逐步完成下面三个知识点！

参考文献 1：《网页解析的全过程(输入url到展示页面)》
参考文献 2：《浏览器渲染页面过程剖析》

（2）DNS 域名解析

首先，我们解决第一个问题：

• 什么是 DNS 解析，它是怎么个流程？

DNS（Domain Name System）是 域名系统 的英文缩写，提供的服务是用于将主机名和域名转换为 IP 地址的工作：

域名：http://jsliang.top <—> DNS <—> IPV4：119.147.15.13

IPV4 是造假的，仅用来说明 DNS 解析后能返回 IP 地址

所以，当用户在浏览器输入 http://jsliang.top 时，DNS 经历了以下步骤：

1. 浏览器根据地址，在自身缓存中查找 DNS（域名服务器） 中的解析记录。如果存在，则直接返回 IP 地址；如果不存在，则查找操作系统中的 hosts 文件是否有该域名的 DNS 解析记录，如果有就返回。
2. 在条件 1 中的浏览器缓存或者操作系统的 hosts 文件中都没有这个域名的 DNS 解析记录，或者已经过期，则向域名服务器发起请求解析这个域名。
3. 先向本地域名服务器中请求，让它解析这个域名，如果解析不了，则向根域名服务器请求解析。
4. 根服务器给本地域名服务器返回一个主域名服务器。
5. 本地域名服务器向主域名服务器发起解析请求。
6. 主域名服务器接收到解析请求后，查找并返回域名对应的域名服务器的地址。
7. 域名服务器会查询存储的域名和 IP 的映射关系表，返回目标 IP 记录以及一个 TTL（Time To Live）值。
8. 本地域名服务器接收到 IP 和 TTL 值，进行缓存，缓存的时间由 TTL 值控制。
9. 将解析的结果返回给用户，用户根据 TTL 值缓存在本地系统缓存中，域名解析过程结束。

看文字总是难以理解的，跟着 jsliang 画张图过一遍，就感觉清晰了：

（3）TCP 三次握手与四次挥手

然后，我们解决第二个问题：

• 什么是 TCP 三次握手，什么是 TCP 四次挥手，它们的流程是怎样的？

什么是 TCP 呢？TCP（Transmission Control Protocol 传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议。

简单来说，它的作用就是将数据流从一台主机可靠地传输到另一台主机。

至于具体的工作原理，这里暂时涉及不到，我们目前只想知道两个点：三次握手与四次挥手。

• 三次握手：

1. 第一次握手：起初两端都处于 CLOSED 关闭状态，Client 将标志位 SYN 置为 1，随机产生一个值 seq = x，并将该数据包发送给 Server，Client 进入 SYN-SENT 状态，等待 Server 确认。
2. 第二次握手：Server 收到数据包后由标志位 SYN = 1 得知 Client 请求建立连接，Server 将标志位 SYN 和 ACK 都置为 1，ack = x + 1，随机产生一个值 seq = y，并将该数据包发送给Client以确认连接请求，Server 进入 SYN-RCVD 状态，此时操作系统为该 TCP 连接分配 TCP 缓存和变量。
3. 第三次握手：Client 收到确认后，检查 seq 是否为 x + 1，ACK 是否为 1，如果正确则将标志位 ACK 置为 1，ack = y + 1，并且此时操作系统为该 TCP 连接分配 TCP 缓存和变量，并将该数据包发送给 Server，Server 检查 ack 是否为 y + 1，ACK 是否为 1，如果正确则连接建立成功，Client 和 Server 进入 established 状态，完成三次握手，随后 Client 和 Server 就可以开始传输数据。

文字太乱，show you picture：

• 四次挥手：

1. 第一次挥手：Client 的应用进程先向其 TCP 发出连接释放报文段（FIN = 1，序号 seq = u），并停止再发送数据，主动关闭 TCP 连接，进入 FIN-WAIT-1（终止等待1）状态，等待 Server 的确认。
2. 第二次挥手：Server 收到连接释放报文段后即发出确认报文段，（ACK = 1，确认号 ack = u + 1，序号 seq = v），Server 进入 CLOSE-WAIT（关闭等待）状态，此时的 TCP 处于半关闭状态，Client 到 Server 的连接释放。

注：Client 收到 Server 的确认后，进入 FIN-WAIT-2（终止等待2）状态，等待 Server 发出的连接释放报文段。

1. 第三次挥手：Server 已经没有要向 Client 发出的数据了，Server 发出连接释放报文段（FIN = 1，ACK = 1，序号 seq = w，确认号 ack = u + 1），Server 进入 LAST-ACK（最后确认）状态，等待 Client 的确认。
2. 第四次挥手：Client 收到 Server 的连接释放报文段后，对此发出确认报文段（ACK = 1，seq = u + 1，ack = w + 1），Client 进入 TIME-WAIT（时间等待）状态。此时 TCP 未释放掉，需要经过时间等待计时器设置的时间 2MSL 后，Client 才进入 CLOSED 状态。

文字太乱，show you picture：

OK，至此我们就理解了 TCP 及其三次握手和四次挥手过程，为了方便小伙伴们形象记忆，jsliang 搞了个小故事，希望小伙伴们能加深印象：

• 三次握手 + 四次挥手形象记忆：

1. jsliang：（对妹子发起微信好友申请）“你好，我可以加你好友吗？” —— 第一次握手
2. 妹子：（通过审核）“你好，很高兴认识你~” —— 第二次握手
3. jsliang：“你好，我叫梁峻荣，前端折腾小能手……” —— 第三次握手
4. ……（聊天内容）
5. …………（聊天内容）
6. ………………（聊天内容）
7. …………（聊天内容）
8. ……（聊天内容）
9. jsliang：（感冒拍了张纸篓都是纸巾的图）“啊，好难受今天。” —— 第一次挥手
10. 妹子：“卧槽，你好恶心！” —— 第二次挥手
11. 妹子：“咱还是当不认识吧，互删了，谢谢！” —— 第三次挥手
12. jsliang：（呆）“不是，你听我说！” —— 第四次挥手
13. 妹子：（果断删除好友） —— CLOSED
14. jsliang：（！“我今天感冒了。” 妹子开启了好友验证，你还不是她好友。请先发送好友验证请求，对方验证通过后，才能聊天。） ——— CLOSED

OK，成功出糗，相信小伙伴们有了个很好的了解了。

那么，我们继续前行探索。

参考文献 1：《TCP三次握手和四次挥手过程》
参考文献 2：《TCP的三次握手与四次挥手（详解+动图）》

（4）浏览器渲染页面

最后，我们解决第三个问题：

• 浏览器解析文档资源并渲染页面是个怎样的流程？

话不多说，一起来看：

1. 浏览器通过 HTMLParser 根据深度遍历的原则把 HTML 解析成 DOM Tree。
2. 浏览器通过 CSSParser 将 CSS 解析成 CSS Rule Tree（CSSOM Tree）。
3. 浏览器将 JavaScript 通过 DOM API 或者 CSSOM API 将 JS 代码解析并应用到布局中，按要求呈现响应的结果。
4. 根据 DOM 树和 CSSOM 树来构造 render Tree。
5. layout：重排（也可以叫回流），当 render tree 中任一节点的几何尺寸发生改变，render tree 就会重新布局，重新来计算所有节点在屏幕的位置。
6. repaint：重绘，当 render tree 中任一元素样式属性（几何尺寸没改变）发生改变时，render tree 都会重新画，比如字体颜色，背景等变化。
7. paint：遍历 render tree，并调动硬件图形 API 来绘制每个节点。

文字讲解肯定还是不够清晰的，但是 jsliang 画了几张图也累了，所以咱们 盗 来了一张图：

这样，我们就对 浏览器渲染页面过程 一清二楚啦~

参考文献：《一篇文章搞定前端面试》

（5）总结

至此，我们回顾下自己做了什么？

1. 我们在工作中碰到一些问题，这些问题会卡住页面，于是我们查资料，知道想要减少浏览器的开销，我们就需要使用 防抖与节流。
2. 使用 防抖与节流 解决完问题后，我们好奇为什么会有这样的操作，于是我们深入了解了下 重绘与回流。
3. 重绘与回流 只告诉了我们浏览器在 CSS 上的渲染，我们需要进一步了解 浏览器渲染页面 的详细过程，但洋葱还是要一层一层剥开的，所以我们需要从 浏览器解析 URL 开始了解。
4. 在 浏览器解析 URL 中，我们顺带了解下 DNS 域名解析、TCP 三次握手与四次挥手 这两个知识点。
5. 最后，我们终于知道了 浏览器渲染页面 是怎么一回事。

综上，如果我们仅仅是需要关注面试的一个点，我们很可能因为不知头尾，而被面试官问得哑口无言。

但是，如果我们知道一个知识点，并对其进行思路发散，深入学习，相信面试官问起来的时候，小伙伴们就可以侃侃而谈，而不会被问地体无完肤了！

• 《函数防抖和节流》
• 《节流 & 防抖》
• 《JS奇淫巧技：防抖函数与节流函数》
• 《闲聊 JS 中的 apply 和 call》
• 《js 中 arguments 的用法》
• 《防抖和节流的应用场景和实现》
• 《网页解析的全过程(输入url到展示页面)》
• 《浏览器渲染页面过程剖析》
• 《一篇文章搞定前端面试》

.