乐趣区

关于前端:从输入URL到页面展示-这中间发生了什么

jiezi

从导航栏外面输出了一个 URL 之后到底产生了什么???

这外面波及到了浏览器中, 各个过程之间的配合, 如下图:

所以在正式流程开始之前, 咱们还是先来疾速回顾一下浏览器过程、渲染过程和网络过程的次要责任。

  • 浏览器过程：用户交互、子过程治理和文件存储等性能。
  • 网络过程：面向渲染过程和浏览器过程等提供网络下载性能。
  • 渲染过程：将从网络下载的 HTML、JavaScript、CSS、图片等资源解析为能够显示和交互的页面。

渲染过程里所有的内容都是通过网络获取的，会存在一些恶意代码利用浏览器破绽对系统进行攻打，所以运行在渲染过程外面的代码是不被信赖的。这也是为什么 Chrome 会让渲染过程运行在平安沙箱里，就是为了保证系统的平安。

相熟了这几个过程的性能之后，咱们再来看这张图:

整个流程中蕴含了许多步骤，大抵过程形容如下:

  1. 首先，用户从 浏览器过程 里 输出申请信息;
  2. 而后，网络过程 发动 URL 申请;
  3. 服务器响应 URL 申请之后，浏览器过程开始 筹备渲染过程;
  4. 渲染过程筹备结束之后，须要先向渲染过程提交页面数据，咱们成为 提交文档阶段;
  5. 渲染过程承受完文档信息之后，便开始 解析页面和加载子资源，实现页面的渲染。

这其中，用户收回 URL 申请到页面开始解析的这个过程，叫做导航。

上面咱们来剖析这些步骤，同时也就解开这个问题了 …

从输出 URL 到页面展现

1. 用户输出
用户在浏览器地址栏中输出关键字时，地址栏会判断输出的关键字是 搜寻内容 ，还是 申请的 URL

  • 如果是搜寻内容，地址栏会应用浏览器默认的搜索引擎，来合成新的带搜寻关键字的 URL。
  • 如果判断输出内容合乎 URL 规定，比方输出的是 time.geekbang.org，那么地址栏会依据规定，把这段内容加上协定，合成为残缺的 URL，如:https://time.geekbang.org。

当用户输⼊关键字并键⼊回车之后，浏览器便进入下图的状态：

从图中能够看出，当浏览器刚开始加载一个地址之后，标签页上的图标便进入了加载状态。然而页面并没变，还是之前的内容。这是因为须要期待提交文档阶段，页面内容才会被替换。

2. URL 申请过程
咱们晓得，咱们方才是在浏览器过程中进行的，当初，浏览器过程会通过过程间通信(IPC)，把 URL 申请发送至网络过程，网络过程接管到 URL 申请后，会在这里发动真正的 URL 申请流程。

  • 网络过程会查找本地缓存，如果有缓存资源，那么间接返回资源给浏览器过程; 如果没有缓存，就会间接进入网络申请流程。

    1. 第一步: DNS 解析，获取申请域名的服务器 IP 地址。如果申请的协定是 HTTPS，那么还须要建设 TLS 连贯。
    2. 三次握手，建设 TCP 连贯。
    3. 浏览器端构建申请行、申请头等信息，并把和该域名相干的 Cookie 等数据附加到申请头中，而后向服务器发送构建的申请信息。
    4. 服务器接管到信息之后，依据申请信息生成响应数据，并发给网络过程。等网络过程接管了响应行和响应头之后，就开始解析响应头的内容了。
    5. 在接管到服务器返回的响应报文后，网络过程对响应报文进行解析，如果发现返回的状态码是 301 或 302，阐明服务器须要浏览器重定向到其余 URL。而后网络过程从响应头的 Location 字段外面读取重定向的地址，而后从新发送申请，又从新开始了。
![image.png](/img/bVbK6zv)
当返回了 code 码是 200 之后，示意浏览器能够持续解决该申请。![image.png](/img/bVbK6Gf)
6. 在解决了跳转信息之后，就须要解析 URL 申请的数据类型，有时候是一个下载类型，有时候是失常的 HTML 页面，浏览器会通过 **Content-Type** 这个字段来通知浏览器返回的响应数据是什么类型。咱们来看上面这张图: 
![image.png](/img/bVbK6Ri)
从图中能够看到 Content-Type 返回值是 text/html，这就是通知浏览器，服务器返回的是 HTML 格局。还有一个咱们常见的返回值，Content-Type: application/octet-stream, 他是示意显示的数据是 ** 字节流类型 ** 的，通常状况浏览器会依照下载类型来解决该申请。不同的 Content-Type，后续解决流程截然不同。如果浏览器判断是下载类型，那么这个申请会被提交给浏览器的下载管理器，同时 URL 申请的导航流程完结。然而如果是 HTML 类型，浏览器就会持续进行导航流程，进入渲染过程。7. 筹备渲染过程，默认状况下 Chrome 会为每一个页面调配一个渲染过程。然而，也会有多个页面运行在一个渲染过程中的时候。这种运行在同一个渲染过程中的起因是因为，这几个页面处于同一个站点下。同一站点就是同一个根域名 (geekbang.org) 和同一个协定 (https:// 或 http://) 下的不同子域名和不同的端口。比方上面这三个:

https://time.geekbang.org
https://www.geekbang.org
https://www.geekbang.org:8080
因为他们是是同一个站点，所以 Chrome 会将他们放在同一个渲染过程当中，如果是不同的站点，就会另外开启一个渲染过程。
当咱们的渲染过程筹备好了之后，还是无奈进入文档解析状态，因为此时的文档数据还在网络过程中，这就须要下一步, 提交文档阶段。

  1. 提交文档，这里的文档指的 URL 响应体的数据。

      * 提交文档的音讯是由浏览器过程收回的，渲染过程接管到之后，会和网络过程建设传输数据的 "管道"
  * 期待数据传输实现之后，渲染过程会返回 "确认提交" 的音讯给浏览器过程。* 浏览器过程在收到 "确认提交" 的音讯之后，会更新浏览器的界面状态，这些状态包含了平安状态、地址栏的 URL、后退后退的历史状态，并更新 Web 页面。
    ![image.png](/img/bVbK67W)

这就解释了为什么在浏览器的地址栏外面输出了一个地址之后，之前的页面没有立马隐没，而是加载了一会才会更新页面。
而后才进入了渲染过程。

9. 渲染阶段，一旦文档被提交，渲染过程便开始页面解析和子资源加载。也就是说，一旦页面生成实现，渲染过程会发送一个音讯给浏览器过程，浏览器接管到音讯后，会进行标签图标上的加载动画。![image.png](/img/bVbK69H)
至此，一个残缺的页面就生成了，这时候咱们就晓得了 ** 从 URL 到页面展现，这两头产生了什么?**

总结:

  • 咱们晓得了从输出了 URL 到一个页面的残缺展现，这两头的过程经验了那些过程。
  • 这些过程做了些什么, 以及是如何配合的。

  • 这个流程再来简略的总结一下:

    1. 浏览器过程: 地址栏判断是申请关键字, 还是 URL
    2. 网络过程: 查找本地缓存, 有缓存间接取缓存返回给浏览器过程, 否则持续。
    3. 网络过程: DNS 解析，获取 IP 并缓存到本地。
    4. 网络申请流程: 建设 TCP 连贯。
    5. 浏览器端: 筹备申请报文向服务器发送申请。
    6. 服务器端: 返回响应报文，并发给网络过程。网络过程进行解析响应报文内容。第一: 重定向。第二: 解决响应类型。
    7. 筹备渲染过程: 判断是否是同一个站点。
    8. 浏览器收回提交音讯，渲染过程 接管到之后和 网络过程 建设连贯传输数据的 ” 管道 ”。
    9. 渲染过程 返回确认提交音讯给 浏览器过程。
    10. 浏览器过程收到确认提交之后，更新浏览器界面状态。
    11. 一旦页面生成实现，渲染过程会发送⼀个音讯给浏览器过程，浏览器接管到音讯后，会进行标签图标上的加载动画。
退出移动版