乐趣区

关于前端:浏览器从输入网址到页面展示的过程

jiezi

残缺高频题库仓库地址：https://github.com/hzfe/aweso…

残缺高频题库浏览地址：https://febook.hzfe.org/

答复关键点

URL DNS TCP 渲染

浏览器从输出网址到渲染页面次要分为以下几个过程

  • URL 输出
  • DNS 解析
  • 建设 TCP 连贯
  • 发送 HTTP / HTTPS 申请（建设 TLS 连贯）
  • 服务器响应申请
  • 浏览器解析渲染页面
  • HTTP 申请完结，断开 TCP 连贯

知识点深刻

1. URL 输出

URL 地址

URL（对立资源定位符，Uniform Resource Locator）用于定位互联网上资源，俗称网址。

咱们在地址栏输出 HZFE 官网网址 hzfe.org 后敲下回车，浏览器会对输出的信息进行以下判断：

  1. 查看输出的内容是否是一个非法的 URL 链接。
  2. 是，则判断输出的 URL 是否残缺。如果不残缺，浏览器可能会对域进行猜想，补全前缀或者后缀。
  3. 否，将输出内容作为搜寻条件，应用用户设置的默认搜索引擎来进行搜寻。

大部分浏览器会从历史记录、书签等中央开始查找咱们输出的网址，并给出智能提醒。

2. DNS（Domain Name System）解析

因为浏览器不能间接通过域名找到对应的服务器 IP 地址，所以须要进行 DNS 解析，查找到对应的 IP 地址进行拜访。

DNS 解析流程如下：

  1. 在浏览器中输出 hzfe.org 域名，操作系统查看浏览器缓存和本地的 hosts 文件中，是否有这个网址记录，有则从记录外面找到对应的 IP 地址，实现域名解析。
  2. 查找本地 DNS 解析器缓存中，是否有这个网址记录，有则从记录外面找到对应的 IP 地址，实现域名解析。
  3. 应用 TCP/IP 参数中设置的 DNS 服务器进行查问。如果要查问的域名蕴含在本地配置区域资源中，则返回解析后果，实现域名解析。
  4. 查看本地 DNS 服务器是否缓存该网址记录，有则返回解析后果，实现域名解析。
  5. 本地 DNS 服务器发送查问报文至根 DNS 服务器，根 DNS 服务器收到申请后，用顶级域 DNS 服务器地址进行响应。
  6. 本地 DNS 服务器发送查问报文至顶级域 DNS 服务器。顶级域 DNS 服务器收到申请后，用权威 DNS 服务器地址进行响应。
  7. 本地 DNS 服务器发送查问报文至权威 DNS 服务器，权威 DNS 服务器收到申请后，用 hzfe.org 的 IP 地址进行响应，实现域名解析。

查问通常遵循以上流程，从申请主机到本地 DNS 服务器的查问是递归查问，DNS 服务器获取到所需映射的查问过程是迭代查问。

3. 建设 TCP 连贯

世界上简直所有的 HTTP 通信都是由 TCP/IP 承载的，TCP/IP 是寰球计算机及网络设备都在应用的一种罕用的分组替换网络分层。HTTP 的连贯实际上就是 TCP 连贯以及其应用规定。–《HTTP 权威指南》

当浏览器获取到服务器的 IP 地址后，浏览器会用一个随机的端口（1024 < 端口 < 65535）向服务器 80 端口发动 TCP 连贯申请（注：HTTP 默认约定 80 端口，HTTPS 为 443 端口）。这个连贯申请达到服务端后，通过 TCP 三次握手，建设 TCP 的连贯。

3.1 分层模型

    ----------------------------------
  7|   应用层   |           |   HTTP  |

  6|   表示层   |   应用层   |

  5|   会话层   |           |         |
    ---------------------------------
  4|   传输层   |   传输层   | TCP TLS |
    ---------------------------------
  3|   网络层   |   网络层   |   IP    |
    ---------------------------------
  2|  数据链路层
               |   链路层
  1|   物理层
    --------------------------------
       [OSI]   |   [TCP/IP]

3.2 TCP 三次握手

# SYN 是建设连贯时的握手信号，TCP 中发送第一个 SYN 包的为客户端，接管的为服务端
# TCP 中，当发送端数据达到接收端时，接收端返回一个已收到音讯的告诉。这个音讯叫做确认应答 ACK

  假如有客户端 A，服务端 B。咱们要建设牢靠的数据传输。SYN(=j)       // SYN: A 申请建设连贯
  A ----------> B
                |
     ACK(=j+1)  |   // ACK: B 确认应答 A 的 SYN
     SYN(=k)    |   // SYN: B 发送一个 SYN
  A <-----------
  |
  |  ACK(=k+1)
   -----------> B   // ACK: A 确认应答 B 的包
  1. 客户端发送 SYN 包（seq = j）到服务器，并进入 SYN\_SEND 状态，期待服务器确认。
  2. 服务器收到 SYN 包，必须确认客户的 SYN（ACK = k + 1），同时本人也发送一个 SYN 包（seq = k），即 SYN+ACK 包，此时服务器进入 SYN\_RECV 状态。
  3. 客户端收到服务器的 SYN+ACK 包，向服务器发送确认包 ACK（ACK = k + 1），此包发送结束，客户端和服务器进入 ESTABLISHED 状态，实现三次握手。

4. TLS 协商

TLS 协商

建设连贯后就能够通过 HTTP 进行数据传输。如果应用 HTTPS，会在 TCP 与 HTTP 之间多增加一层协定做加密及认证的服务。HTTPS 应用 SSL（Secure Socket Layer）和 TLS（Transport Layer Security）协定，保障了信息的平安。

  • SSL
  • 认证用户和服务器，确保数据发送到正确的客户端和服务器。
  • 加密数据避免数据中途被窃取。
  • 保护数据的完整性，确保数据在传输过程中不被扭转。
  • TLS
  • 用于在两个通信应用程序之间提供保密性和数据完整性。该协定由两层组成：TLS 记录协定（TLS Record）和 TLS 握手协定（TLS Handshake）。较低的层为 TLS 记录协定，位于某个牢靠的传输协定（例如 TCP）下面。

4.1 TLS 握手协定

  1. 客户端收回一个 client hello 音讯，携带的信息包含：所反对的 SSL/TLS 版本列表；反对的与加密算法；所反对的数据压缩办法；随机数 A。
  2. 服务端响应一个 server hello 音讯，携带的信息包含：协商采纳的 SSL/TLS 版本号；会话 ID；随机数 B；服务端数字证书 serverCA；因为双向认证需要，服务端须要对客户端进行认证，会同时发送一个 client certificate request，示意申请客户端的证书。
  3. 客户端校验服务端的数字证书；校验通过之后发送随机数 C，该随机数称为 pre-master-key，应用数字证书中的公钥加密后收回；因为服务端发动了 client certificate request，客户端应用私钥加密一个随机数 clientRandom 随客户端的证书 clientCA 一并收回。
  4. 服务端校验客户端的证书，并胜利将客户端加密的随机数 clientRandom 解密；依据随机数 A/ 随机数 B/ 随机数 C（pre-master-key）产生动静密钥 master-key，加密一个 finish 音讯发至客户端。
  5. 客户端依据同样的随机数和算法生成 master-key，加密一个 finish 音讯发送至服务端。
  6. 服务端和客户端别离解密胜利，至此握手实现，之后的数据包均采纳 master-key 进行加密传输。

5. 服务器响应

当浏览器到 web 服务器的连贯建设后，浏览器会发送一个初始的 HTTP GET 申请，申请指标通常是一个 HTML 文件。服务器收到申请后，将发回一个 HTTP 响应报文，内容包含相干响应头和 HTML 注释。

<html>
 <head>
  <meta charset="UTF-8"/>
  <title> 我的博客 </title>
  <link rel="stylesheet" src="styles.css"/>
  <scrIPt src="index.js"></scrIPt>
</head>
<body>
  <h1 class="heading"> 首页 </h1>
  <p>A paragraph with a <a href="https://hzfe.org/">link</a></p>
  <scrIPt src="index.js"></scrIPt>
</body>
</html>

5.1 状态码

状态码是由 3 位数组成，第一个数字定义了响应的类别，且有五类可能取值

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

5.2 常见的申请头和字段

  • Cache-Control：must-revalidate、no-cache、private（是否须要缓存资源）
  • Connection：keep-alive（放弃连贯）
  • Content-Encoding：gzip（web 服务器反对的返回内容压缩编码类型）
  • Content-Type：text/html；charset=UTF-8（文件类型和字符编码格局）
  • Date：Sun，21 Sep 2021 06:18:21 GMT（服务器音讯收回的工夫）
  • Transfer-Encoding：chunked（服务器发送的资源的形式是分块发送）

5.3 HTTP 响应报文

响应报文由四局部组成（响应行 + 响应头 + 空行 + 响应体）

  • 状态行：HTTP 版本 + 空格 + 状态码 + 空格 + 状态码形容 + 回车符（CR）+ 换行符（LF）
  • 响应头：字段名 + 冒号 + 值 + 回车符 + 换行符
  • 空行：回车符 + 换行符
  • 响应体：由用户自定义增加，如 post 的 body 等

6. 浏览器解析并绘制

不同的浏览器引擎渲染过程都不太一样，这里以 Chrome 浏览器渲染形式为例。

  1. 解决 HTML 标记并构建 DOM 树。
  2. 解决 CSS 标记并构建 CSSOM 树。
  3. 将 DOM 与 CSSOM 合并成一个渲染树。
  4. 依据渲染树来布局，以计算每个节点的几何信息。
  5. 将各个节点绘制到屏幕上。

7. TCP 断开连接

当初的页面为了优化申请的耗时，默认都会开启长久连贯（keep-alive），那么一个 TCP 连贯确切敞开的机会，是这个 tab 标签页敞开的时候。这个敞开的过程就是 四次挥手。敞开是一个全双工的过程，发包的程序是不肯定的。一般来说是客户端被动发动的敞开，过程如下图所示：

  1. 被动敞开方发送一个 FIN，用来敞开被动方到被动敞开方的数据传送，也就是被动敞开方通知被动敞开方：我曾经不会再给你发数据了（在 FIN 包之前发送进来的数据，如果没有收到对应的 ACK 确认报文，被动敞开方仍然会重发这些数据），但此时被动敞开方还能够承受数据。
  2. 被动敞开方收到 FIN 包后，发送一个 ACK 给对方，确认序号为收到序号 +1（与 SYN 雷同，一个 FIN 占用一个序号）。
  3. 被动敞开方发送一个 FIN，用来敞开被动敞开方到被动敞开方的数据传送，也就是通知被动敞开方，我的数据也发送完了，不会再给你发数据了。
  4. 被动敞开方收到 FIN 后，发送一个 ACK 给被动敞开方，确认序号为收到序号 +1，至此，实现四次挥手。

参考资料

  1. How_browsers_work
  2. DOMTokenList
  3. 图解 SSL/TLS 协定
  4. DNS 域名零碎
退出移动版