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的执行机制）

    请看下次博客分享~