乐趣区

关于浏览器: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 的执行机制)

    请看下次博客分享~

退出移动版