关于浏览器:13-聊聊Chrome从输入url到页面展示

3000 字长文预警~

第一关：Chrome 的多过程架构：

并发与并行的辨别

• 并发：领有解决多任务的能力
• 并行：领有 同时 解决多任务的能力

过程与线程的辨别：

作为科班生，先分享我在 OS 课堂上听过的，印象最深的的说法：过程是资源分配的最小单位；线程是任务调度的最小单位。

• 线程必须依靠于过程存在。同一过程内的线程共享过程资源。
• 过程内一个线程解体，则该过程解体。但不会影响到操作系统。
• 过程间通过 IPC 机制通信：共享内存、socket、管道通信（通过内核）

Chrome 的多线程架构实现：

• 主过程×1：用户交互、子过程治理、存储管理。
• 网络过程×1：资源加载
• GPU 过程×1：3D 渲染
• 渲染过程 xn：负责文档解析和子资源加载（每个页面都会创立一个）
• 插件过程×n：因为插件不稳固，须要与其余过程隔离开。

第二关：TCP/IP 协定四层网络模型

• OSI 七层模型与 TCP/IP 四层模型比照

  我的了解是：OSI 是更偏重于 规范性 的体系结构，而 TCP/IP 则是 目前 网络环境中的 最佳实际。

  实际上在本科的课本中是形象为五层模型来讲的：

  应用层（应用层 + 表示层 + 会话层）=> 传输层 => 网络层 => 链路层 => 物理层

  可见具体的分层形式并不是要害，要害的是上图两头列对应的重要性能是否失去了实现。

• 数据包的漂泊：

  这是每个本科老师都十分善于讲的故事。过后听课的我并没有因这个故事而很快了解计算机网络的根本运作，但时至今日，这个例子却很好地领导了我对于计算机网络的了解。

第三关：Domain Name System（DNS）

前置内容

• DNS 的工作：对于给定的 url 查问其对应的 ip 地址。

• DNS 的查问形式分为两种：迭代 / 递归；

  1. 浏览器向本地 DNS 服务器查问个别采纳递归形式；
  2. 本地 DNS 服务器向其余服务器查问个别采纳迭代形式；
• DNS 采纳 UDP 协定进行查问：疾速高效。

查问过程：

1. 浏览器将 URL 发送给本地 DNS 服务器（LDNS）；
2. 本地 DNS 服务器查找本地缓存，若存在该 URL 的记录且尚未过期，则返回该 ip 地址，DNS 查问过程完结；
3. 若本地 DNS 服务器不存在该 URL 对应的记录，则迭代查找 ip 地址；
4. 本地 DNS 服务器首先向根域名服务器发送 DNS 报文，根域名服务器依据报文中申请的 URL 返回对应的顶级域名服务器地址
5. 本地 DNS 服务器向顶级域名服务器发送 DNS 报文，顶级域名服务器依据报文中申请的 URL 返回对应的权威服务器地址。
6. 反复以上过程直到失去最终 URL 对应的 IP 地址。
7. 本地 DNS 服务器将该 [ip,url] 的记录写入缓存，将 ip 返回。

第四关：SSL 协定 — HTTPS

HTTPS 是什么？

HTTPS（http secure）= HTTP + 混合加密 + 权威认证 + 完整性保障

因为网络中对于 HTTPS 的详尽介绍十分丰盛，此处不进行具体地叙述了，间接奔向论断。

SSL 协定运行机制

网络上蕴含两种说法（3 个随机数生成密钥 or 2 个随机数生成密钥），但大同小异，都采纳了对称加密 + 非对称加密的形式：

1. Client 向 Server 发送：加密套件列表 + 随机数 client_random
2. Server 向 Client 返回：选中的加密套件 + 随机数 server_random + 数字证书（带公钥）
3. Client 对数字证书进行合法性验证，若非法：产生一个随机数 pre-master，并用该证书中的公钥进行加密。将加密后的数据包发送给 Server
4. Server 应用私钥对该数据包进行解密，失去 pre-master
5. 此时单方利用曾经协商好的加密套件对 client_random+server_random+pre-master 进行加密生成对称密钥。尔后就能够应用此对称密钥进行加密通信了

第五关：TCP 协定

TCP 协定特点

面向连贯 ， 牢靠 的传输层协定。

三次握手

• 三次握手的基本目标：确认我方和对方的发送、接管能力是否均失常

• 三次握手过程：

  Client 与 Server 都明确本身的发送和承受能力失常，须要确定对方的发送和接管能力。

  1. 第一次握手：Client 向 Server 发送报文：SYN=1，seq=x；
  2. 第二次握手：Server 接管到报文，向 Client 发送报文：ACK=1，ack=x+1，SYN=1，seq=y；

     Server 确认 Client 的发送能力失常：Client 发送了 SYN 报文。

  3. 第三次握手：Client 接管到报文，向 Server 发送报文：ACK=1，seq=x+1，ack=y+1。

     Client 确认 Server 的发送和接管能力失常：因为 Server 正确地接管并响应了 Client。

     Server 确认 Client 的接管能力失常：Server 接管到了 Client 的 ACK。

• 为什么不应用两次握手：

  假如舍弃最初一次握手，则 Server 端无奈明确 Client 的接管能力是否失常。

四次挥手

• 四次握手的目标：保障单方的数据均发送结束，再敞开连贯。

• 四次挥手过程：

  1. 第一次挥手：Client 向 Server 发送 FIN 报文，表明 Client 不会再向 Server 发送数据：FIN=1,seq=x
  2. 第二次挥手：Server 向 Client 发送 ACK 报文示意回应：AKC=1,seq=y,ack=x+1

     期间 Server 能够持续向 Client 发送数据，此时处于 TCP 的半连贯状态；

     Client 还须要持续监听 Server 发送来的报文。

  3. 第三次挥手：Server 向 Client 发送 FIN 报文，表明 Server 不会再向 Client 发送数据：FIN=1,seq=z,ack=x+1
  4. 第四次挥手：Client 向 Server 发送 ACK 报文示意回应：ACK=1,seq=x+1,ack=z+1。同时期待 2MSL，若此期间没有接管到报文，则 TCP 连贯顺利断开。
• 为什么是四次挥手而不是像建设连贯时应用三次挥手？

  这是因为服务端在 LISTEN（监听）状态下，收到 建设连贯申请 的 SYN 报文后，把 ACK 和 SYN 放在 一个报文 里发送给客户端。而敞开连贯时，当收到对方的 FIN 报文时，仅仅示意对方不再发送数据了然而还能接收数据，己方是否当初敞开发送数据通道，须要 下层利用来 决定，因而，己方 ACK 和 FIN 个别都会 离开 发送。

• 为什么要期待 2MSL？

  1. 第四次握手，客户端收回 ACK 但并不会收到回应，所以客户端无奈确认本人的 ACK 是否顺利达到，所以此时须要期待 2MSL 来给服务器重发 FIN 报文的机会。
  2. 客户端发送 ACK 后的 1MSL 内，服务器的计时器也会到时，如果因为某种原因并没有收到 ACK，则会重发 FIN 报文。
  3. FIN 文件会在 1MSL 内达到客户端；此时客户端的计时器还未清零，收到 FIN 后重启 2MSL 计时器并回送 ACK。

第五关：ARP 协定

定义

• 地址解析协定，是通过 解析 ip 地址来寻找 MAC 地址 的一个在网络协议包中十分重要的网络传输协定。ARP 属于链路层协定。

工作过程

• 同一网段：播送查问 -> 单播回应
• 不同网段：播送查问 -> 单播回应 -> 网关直达 -> 反复
• 参考：https://juejin.cn/post/6890167829984149518

从输出 URL 到页面展现产生了什么？

浏览器侧：

1. 用户输出 url

   由浏览器判断地址栏中的字符串是否合乎 url 命名规定。若不合乎则将该字符串交由搜索引擎解决；若正当则进入第二步。

2. 构建 HTTP 报文

   GET url HTTP/1.1

   主过程将该报文通过 IPC 交给网络过程解决。

3. 查找浏览器内的文件缓存

   若浏览器已经申请过该资源且资源并未过期，则网络过程将缓存文件返回并拦挡 HTTP 申请。若查找缓存未命中，则进入第 4 步。

4. DNS 查问

   详情见第二关 DNS；

   失去的 ip 最终返回到浏览器的网络过程中。

5. HTTP 报文在传输层的处理完毕，筹备下放到传输层（TCP）。

   Chrome 浏览器有对于 TCP 连贯的限度（同个域名最多维持 6 个 TCP 连贯），若超过 6 个则须要放入 TCP 队列中期待。

6. 若应用了 HTTPS 协定，在应用层 HTTP 和传输层 TCP 之间还要减少一层 SSL 层，保障连贯平安

   详情见上文 HTTPS 相干内容。

7. 进行 TCP 的三次握手连贯：

   详情见第四关 TCP 协定

8. 传输层 TCP 协定解决报文

   • TCP 层将 HTTP 报文切分为相等大小的报文段，并为报文段减少TCP 头部。
   • 头部增加序号：保障 程序交付 并在目标端从新组装。
   • 头部增加源端的端口号和目标端的端口号：确认数据包应该交付给目标端的哪个应用程序（端口）。
   • 将报文段下放到网络层

9. 网络层 IP 协定解决报文段

   • 为报文段减少 I P 头部，增加源 IP 地址和目标 IP 地址。
   • 应用动态路由算法或动静路由算法在网络层进行路由

10. 链路层传输报文

    • 为 IP 数据包减少 以太网头部，增加了 MAC 地址
    • 利用 ARP 协定进行链路层数据传输：详情见第六关

服务端侧：

1. 链路层和网络层：

   一次除去以太网头和 IP 头部，提交到传输层

2. 传输层重组报文交给指定应用程序

   • TCP 协定依据报文段头部的序号保证数据的正确性和完整性，组成 HTTP 报文
   • 将 HTTP 报文交付给 TCP 头部指定的目标端口号程序，上交到应用层

3. 客户端对 HTTP 申请进行剖析并构建响应报文

   1. 对于申请行中指定的 URL，查看是否须要重定向。

      若须要重定向则返回 301（永恒重定向）或 302（临时重定向）状态码，并在响应报文首部 Location 字段写入重定向的地址。

   2. 查看申请报文首部 if-none-match 字段对应的资源是否更新

      若为更新返回 304 状态码，示意资源未更新。

   3. 查看是否须要告诉浏览器进行缓存

      若须要浏览器更新，则设定 cache-control：max-age=2000（以 2000 秒为例）

4. 服务端应用层将 HTTP 报文发送回客户端

   过程与上述无异。

5. 敞开 HTTP 连贯

   查看是否处于长连贯

   • HTTP1.0 中通过 Connection:keep-alive 申明长连贯，否则默认应用短连贯；HTTP1.1 中默认长连贯）
   • 若应用长连贯则临时不敞开 HTTP 连贯；若应用短连贯则进行 HTTP 四次挥手过程（详情见第五关）

浏览器侧：

1. 网络过程接管到 HTTP 响应报文进行剖析

   1. 若响应状态码为 301 或 302 则从新构建 HTTP 申请报文，url 为响应报文的 location 对应的 url
   2. 若响应码为 304 则间接应用浏览器的缓存资源
   3. 若状态码为 200，则申请胜利。依据资源类型进行解决。

2. 依据 content-Type 解决相应数据

   • 若 content-Type 是 html/text 则是 html 页面，通过 IPC 告诉浏览器主线程筹备渲染页面。
   • 若 content-Type 是字节流类型，则应用下载管理器进行资源下载。

3. 渲染页面并显示

   这部分内容十分复杂（包含了浏览器的渲染过程和 Javascript 的执行机制）

   请看下次博客分享~