聊聊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协议处理报文段

   • 为报文段增长IP头部，添加源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的执行机制）

   请看下次博客分享~