“ 从浏览器地址栏输出 url 到申请返回产生了什么？”，呃，这道面试题我都不晓得被问了多少遍，作为必考题，咱们有必要总结一下。

总的来说，分为以下几个过程：

• 1、DNS 解析
• 2、TCP 连贯
• 3、发送 HTTP 申请
• 4、服务器解决申请并返回 HTTP 报文
• 5、浏览器解析渲染页面

上面让咱们理解下这 5 个过程。

一、DNS 解析

DNS(Domain Name System) 是 ” 域名零碎 ” 的英文缩写。DNS 解析的过程就是寻找哪台机器上有你须要资源的过程。

当你在浏览器中输出一个地址时，例如 www.shanzhonglei.com，其实不是网站真正意义上的地址。互联网上每一台计算机的惟一标识是它的 IP 地址，然而 IP 地址并不不便记忆，所以就用网址代替 IP 地址。

DNS 域名解析过程

• 1、浏览器缓存。首先会查看浏览器缓存中有没有域名对应的 ip 地址，这个缓存是有过期时长的，个别是几分钟到几小时不等。
• 2、本地 hosts 文件。查看本人本地的 hosts 文件是否有这个网址映射关系。windows 就是 C:\Windows\System32\drivers\etc\hosts 文件，linux 在 /etc/hosts 文件中配置。
• 3、路由器缓存。可能还存在路由器缓存这一层。
• 3、本地 DNS 服务器。如果要查问的域名，蕴含在本地配置区域资源中，则返回解析后果给客户机。此解析具备权威性。
• 4、根 DNS 服务器。如果未用转发模式，本地 DNS 就把申请发至 13 台根 DNS 进行解析。如果是转发模式，DNS 服务器就会把申请转发至上一级 DNS 服务器，由上一级服务器进行解析，上一级服务器如果不能解析，或找根 DNS 或把转申请转至上下级，以此循环。
• 5、此外还会去查问顶级域名服务器和主域名服务器

所以解析过程大略为： 浏览器缓存 -> 本地 hosts 文件 -> 路由器缓存 -> 本地 DNS 服务器 -> 根 DNS 服务器 -> 顶级域名服务器 -> 主域名服务器

前端 DNS 优化

能够在 html 页面头部写入 dns 缓存地址。

<meta http-equiv="x-dns-prefetch-control" content="on" />
<link rel="dns-prefetch" href="http://www.shanzhonglei.com/" />

DNS 负载平衡

如果 DNS 返回的 IP 地址每次都一样，那么这台机器须要多高的性能和贮存能力满足亿万申请呢？

其实 DNS 能够返回一个适合的机器的 IP 给用户，例如能够依据每台机器的负载量，该机器离用户地理位置的间隔等等，这种过程就是 DNS 负载平衡，又叫做 DNS 重定向。

大家耳熟能详的 CDN(Content Delivery Network) 就是利用 DNS 的重定向技术，DNS 服务器会返回一个跟用户最靠近的点的 IP 地址给用户，CDN 节点的服务器负责响应用户的申请，提供所需的内容。

二、TCP 连贯

用户数据包协定（User Datagram Protocol），简称 UDP，是基于 IP 之上开发能和利用打交道的协定。

UDP 中一个最重要的信息是端口号，端口号其实就是一个数字，每个想拜访网络的程序都须要绑定一个端口号。

通过端口号 UDP 就能把指定的数据包发送给指定的程序了，所以通过 IP 地址信息把数据包发送给指定的电脑，而 UDP 通过端口号把数据包分发给正确的程序。

TCP（Transmission Control Protocol，传输控制协议）是一种面向连贯的、牢靠的、基于字节流的传输层通信协议。TCP 绝对于 UDP 有两个特点：

• 对于数据包的失落，建设重传机制
• TCP 引入数据包排序机制，用来保障把乱序的数据包组合成一个残缺的文件

三次握手，就是指在建设一个 TCP 连贯时，客户端和服务器总共要发送 3 个数据包来确认连贯的建设。三次握手次要作用：

• 1、确认单方的接管能力和发送能力
• 2、指定本人的初始化序列号，为前面的可靠性做筹备

2.1 三次握手过程

刚开始客户端处于 Closed 的状态，服务器处于 Listen 状态。

1. 客户端发送到服务器 。客户端发送 SYN 报文给服务器，并且指明客户端初始化序列号为 ISN(c)，即以 SYN=1, seq=x 的模式发送过来。此时客户端处于 SYN_SEND 状态。
2. 服务器发送给客户端 。服务器收到客户端的 SYN 和 ISN(c)，也发送一个 SYN 回去，同时设置 ACK = ISN(c) + 1 以及指明服务器初始化序列号为 ISN(s)，即以 SYN=1, ACK=x+1，seq=y 的模式发送给客户端。
3. 客户端发送到服务器 。客户端收到服务器发送的音讯后，设置 ACK = ISN(s) + 1，将本身的 ISN(c) + 1，即以 ACK=y+1, seq=x+1 的模式发送给服务器。此时客户端处于 ESTABLISHED 阶段，服务器收到报文，也处于 ESTABLISHED 阶段，单方建设了连贯。
   

2.2、两次握手不行吗？

三次握手的目标：

1. 客户端发送数据给服务器，服务器确认本人能够承受客户端的申请。
2. 服务器发送数据给客户端，客户端确认本人能够发送数据给服务器，也能够承受到服务器的申请。
3. 客户端发送数据给服务器，服务器确认本人能够发送数据给客户端。

如果采纳两次握手，客户端发送数据给服务器，服务器确认后就当连贯开始：

1. 客户端发送一次申请给服务器，指定工夫后没响应再发了一个
2. 服务器先接管到后一个建设连贯的申请，而后前一个建设连贯的申请，因为网络提早等问题，在第二个之后达到了
3. 服务器认为第二个申请是最新发的，于是向客户端发送确认报文段，批准建设连贯，于是连贯建设了（两次握手）
4. 这时候客户端还在期待最新的申请连贯（第二次申请），主动疏忽服务器发送的对于第一个申请连贯的响应，也不发送数据
5. 服务器始终期待客户端发送数据，服务器资源被占用

2.3 三次握手过程中能够携带数据吗？

第三次握手的时候能够携带，第一第二次不能够携带。

第三次握手的时候，客户端处于 ESTABLISHED 状态了，它能够建设连贯并且晓得服务器的接管、发送能力是失常的，所以能够携带数据了。

2.3、四次挥手过程

• 客户端发送给服务器。客户端以 FIN=1, seq=u 的模式发送给服务器，示意须要敞开客户端和服务器的数据传输。此时客户端处于 FIN_WAIT 状态。
• 服务器发送给客户端。服务器收到信息，先返回 ACK 给客户端，即以 ACK=1, seq=v, ack=u+1 的模式返回给客户端，示意收到客户端报文了。此时服务器处于 CLOST_WAIT 状态。
• 服务器发送给客户端。服务器期待一会，看客户端还有没有数据没发过来，等解决完这些数据之后，也想断开连接了，于是发送 FIN 给客户端，即以 FIN=1, ACK=1, seq=w, ack=u+1 的模式发送给客户端。此时服务器处于 LAST_ACK 状态。
• 客户端发送给服务器。客户端收到 FIN 之后，返回 ACK 报文作为应答，即以 ACK=1, seq=w+1 的模式发送给服务器。此时客户端处于 TIME_WAIT 状态。
  

2.4、为什么须要四次挥手

因为服务器接管到客户端的敞开申请之后。

如果有一些数据因为网络提早等问题没有发送到，那么它间接敞开会导致这些数据没有接管到；亦或者服务器也有一些数据要发送给客户端，要确保这些数据发送完。

咱们晓得 TCP 是个牢靠的棒小伙，所以它才会第一次回复客户端收到敞开连贯的申请了，第二次回复客户端你发送的数据应该没提早了，我也发送完我要发送的数据了，能够敞开了。

最初客户端接管到了，回复通知服务器它也能够敞开了，而后过一阵子确保服务器接管到它发的 ACK 报文之后，也处于 CLOSED 状态了。这样就确保了连贯的失常敞开。

三、发送 HTTP 申请

发送 HTTP 申请的过程就是构建 HTTP 申请报文，并通过 TCP 协定发送到服务器指定端口（HTTP 协定默认端口 80/8080，HTTPS 协定默认端口 443）。

HTTP 申请报文由 3 局部组成：申请行、申请报文 和 申请注释。

• 申请行：罕用办法有：GET、POST、PUT、DELETE、OPTIONS、HEAD。
• 申请报头：容许客户端向服务器传递申请的附加信息和客户端本身的信息。
• 申请注释：通过 POST、PUT 等办法时，通常须要客户端向服务器传递数据，这些数据就贮存在申请注释中。

留神，如果本地缓存是否缓存了该资源，就会间接渲染页面。

GET 和 POST 办法到底有什么区别？

如果没有前提，也就是不必任何标准限度的话，咱们只思考语法来说，GET 申请和 POST 申请都能拉取数据。这两个形式是没有任何区别的，只有名字不一样。

RFC 是一种网络标准，如果基于 RFC 标准，那就不一样：

• 1、GET 的数据在 URL 中对所有人都是可见的。POST 的数据不会显示在 URL 中。
• 2、GET 对数据长度有限度，当发送数据时，GET 办法向 URL 增加数据；URL 的长度是受限制的（URL 的最大长度是 2048 个字符）。POST 无限度。
• 3、GET 可珍藏为书签，POST 不可珍藏为书签。
• 4、GET 后退按钮 / 刷新无影响，POST 数据会被从新提交。
• 5、GET 编码类型 application/x-www-form-url，POST 编码类型 encodedapplication/x-www-form-urlencoded 或 multipart/form-data。为二进制数据应用多重编码。
• 6、GET 历史参数会保留在浏览器历史中。POST 参数不会保留在浏览器历史中。
• 7、GET 只容许 ASCII 字符。POST 没有限度。也容许二进制数据。
• 8、与 POST 相比，GET 的安全性较差，因为所发送的数据是 URL 的一部分。在发送明码或其余敏感信息时绝不要应用 GET！POST 比 GET 更平安，因为参数不会被保留在浏览器历史或 web 服务器日志中。
• 9、比方 GET 申请只会有一次 TCP 连贯，而 POST 申请会有两次 TCP 连贯。对于 GET 形式的申请，浏览器会把 http header 和 data 一并发送进来，服务器响应 200（返回数据）; 而对于 POST，浏览器先发送 header，服务器响应 100 continue，浏览器再发送 data，服务器响应 200 ok（返回数据）。

四种常见的 POST 提交数据形式：

• 1.application/x-www-form-urlencoded（表单默认形式）
• 2.multipart/form-data（表单上传文件）
• 3.application/json
• 4.text/xml

四、服务器解决申请并返回 HTTP 报文

这一步，会查看状态码，如果是 301/302，则须要重定向，从 Location 主动中读取地址，从新发动申请。如果是 200 状态码，查看响应类型 Content-Type，如果是字节流类型，则将该申请提交给下载管理器，该导航流程完结，不再进行后续的渲染。

如果是 html 则告诉浏览器过程筹备渲染过程筹备进行渲染。

HTTP 响应报文也是由 3 局部组成：状态码、响应报头 和 响应报文。

• 状态码：
  1xx：批示信息–示意申请已接管，持续解决。
  2xx：胜利–示意申请已被胜利接管、了解、承受。
  3xx：重定向–要实现申请必须进行更进一步的操作。
  4xx：客户端谬误–申请有语法错误或申请无奈实现。
  5xx：服务器端谬误–服务器未能实现非法的申请。

平时遇到比拟常见的状态码有:200, 204, 301, 302, 304, 400, 401, 403, 404, 422, 500(别离示意什么请自行查找)。

• 响应报头：常见的响应报头字段 Server、Connection 等。
• 响应报文：服务器返回给浏览器的文本信息，通常 HTML、CSS、JS、图片等文件就放在这一部分。

状态码 301 和 302 的区别？

301 重定向是一种永恒重定向，而 302 跳转是临时的跳转。

五、浏览器解析渲染页面

浏览器的渲染过程为：

1. 解析 HTML，生成 DOM 树
2. 解析 CSS，生成 CSS 规定树（CSS Rule Tree）
3. 将 DOM Tree 和 CSS Rule Tree 相结合，生成 渲染树 （Render Tree）
4. 从根节点开始，计算每一个元素的大小、地位，给出每个节点所应该呈现的屏幕准确坐标，从而失去基于渲染树的 布局渲染树 （Layout of the render tree）。
5. 遍历渲染树，将每个节点用 UI 渲染引擎来绘制，从而将整棵树绘制到页面上，这个步骤叫 绘制渲染树 （Painting the render tree）

浏览器在解析过程中，如果遇到申请内部资源时，如图像，JS 等，还会从新执行网络申请。这个申请过程是异步的，并不会影响 HTML 文档进行加载，然而当文档加载过程中遇到 JS 文件，HTML 文档会挂起渲染过程，不仅要等到文档中 JS 文件加载结束还要期待解析执行结束，才会持续 HTML 的渲染过程。起因是因为 JS 有可能批改 DOM 构造，这就是 JS 阻塞后续资源下载的根本原因。

CSS 文件的加载不影响 JS 文件的加载，然而却影响 JS 文件的执行。JS 代码执行前浏览器必须保障 CSS 文件曾经下载并加载结束。

倡议将 script 标签放到 body 标签底部，或者给 script 标签增加 defer/async 属性。

页面渲染层优化

• 1、HTML 文档构造档次尽量少，最好不深于六层
• 2、脚本尽量后放
• 3、大量首屏款式内联放在标签内
• 4、款式构造档次尽量简略
• 5、在脚本中尽量减少 DOM 操作，尽量缓存拜访 DOM 的款式信息，防止适度触发回流
• 6、缩小通过 JavaScript 代码批改元素款式，尽量应用批改 class 名形式操作款式或动画
• 7、动画尽量应用在相对定位或固定定位的元素上

扩大

DNS 域名称和组织类型

TCP 和 UDP 的区别

• TCP 是面向连贯的，UDP 是无连贯的即发送数据前不须要先建设链接。
• TCP 提供牢靠的服务。通过 TCP 连贯传送的数据，无差错，不失落，不反复，且按序达到；UDP 尽最大致力交付，即不保障牢靠交付。并且因为 TCP 牢靠，面向连贯，不会失落数据因而适宜大数据量的替换。
• TCP 只能是 1 对 1 的，UDP 反对 1 对 1，1 对多。
• TCP 是面向连贯的可靠性传输，而 UDP 是不牢靠的。

感激

谢谢浏览，如有帮忙请点个关注、珍藏吧

欢送关注前端技术驿站公众号，分享学习材料，技术总结！