zxd's Blog

Appearance

URL解析 ​

地址解析 ​

首先判断输入的是一个合法的URL还是一个待搜索的关键词。

  1. 待搜索的关键词 -> 关键词+默认搜索引擎 合成完整的URL
  2. 合法URL -> 加上协议 组成完整URL

URL组成 ​

URL 主要由 协议、主机、端口、路径、查询参数、锚点6部分组成！ image.png ⇒ protocol 😕/ hostname[:port] / path / [:parameters][?query]#fragment protocol (协议)

  • file 资源是本地计算机上的文件。格式file:///，注意后边应是三个斜杠。
  • http 通过 HTTP 访问该资源。 格式 HTTP://
  • https 通过安全的 HTTPS 访问该资源。 格式 HTTPS://

hostname（主机名）

  • 主机指的是在互联网（局域网）中提供服务的设备，可以通过ip或者域名访问
  • 如果访问的是域名：dns服务器解析 ⇒ ip地址⇒ 是指存放资源的服务器的域名系统(DNS) 主机名或 IP 地址。

port（端口号）

  • 端口号是 0 - 65535 之间的整数, 默认可以省略，省略使用默认端口。
  • 计算机内部服务和外部通讯的 虚拟通道
  • http默认端口80，https默认端口号443
  • 一个端口一次只能被一个服务占用

path（路径）

  • 由零或多个“/”符号隔开的字符串，一般用来表示主机上的一个目录或文件地址。(资源路径)

parameters（参数）

  • 这是用于指定特殊参数的可选项,有服务器端程序自行解释。

query(查询)

  • 可选，可以向服务器传递参数
  • 可有多个参数，用“&”符号隔开，每个参数的名和值用“=”符号隔开。

fragment（信息片断-锚点）

  • 字符串，用于指定网络资源中的片段。例如一个网页中有多个名词解释，可使用fragment直接定位到某一名词解释。

然后按下回车，浏览器进程通过进程间通信（IPC）把URL请求发送给网络进程（网络进程接收到url才发起真正的网络请求）。

浏览器缓存 ​

网络进程收到URL请求后，会优先先检查本地缓存是否缓存了该资源。如果有缓存资源，那么直接返回资源给浏览器进程；

强缓存 ​

强缓存是利用缓存数据可再次使用的一种方式,它是利用几个HTTP响应头字段实现的:

  • Expires: 这个响应头包含一个日期值,指示缓存数据的过期时间,在这个时间之前都可以直接使用缓存。
  • Cache-Control: 这个响应头更为可靠,它优先于Expires。常见值有max-age(最大生存期)、public(所有缓存接受响应)、private(只有浏览器可缓存)等。

当浏览器第一次访问某个资源时,服务器会在响应头中返回上述字段。浏览器接下来请求同一资源时,如果资源缓存未过期(即满足Expires和Cache-Control标注的时间窗口),浏览器就会直接从缓存中获取资源,不会再与服务器发生通信。这种情况称为"命中强缓存"。

协商缓存 ​

如果强缓存未命中,浏览器会把资源的相关缓存标识发送给服务器,由服务器决定是否可以使用缓存。这种通过服务器允许使用缓存的方式称为"协商缓存"。主要涉及以下字段:

  • Last-Modified / If-Modified-Since: 资源的最后修改时间。浏览器会提供If-Modified-Since值,服务器据此判断资源是否未修改。
  • ETag / If-None-Match: 资源的特征值标识。类似于Last-Modified,但更准确,服务器会告诉浏览器当前ETag值,下次浏览器发送此值。

如果协商缓存命中,服务器会返回304 Not Modified状态码,告诉浏览器继续使用缓存。否则服务器会返回200 OK和完整资源内容,浏览器则使用该新资源并更新缓存。

强缓存优先于协商缓存。当两种方式都没有命中时,浏览器直接从服务器下载完整的响应数据,并根据服务器的响应头字段重新建立起缓存。

总的来说,强缓存是存在于客户端(浏览器)的缓存,命中强缓存时可以直接从本地加载资源,不需要再与服务器通信。而协商缓存需要客户端与服务器通信来判断资源是否可以缓存利用。 image.png

启发式缓存 ​

启发式缓存（Heuristic Caching）是当HTTP响应不包含明确的缓存到期指示（如Cache-Control或Expires头部）时，浏览器或代理服务器自己决定如何缓存及保存内容多长时间的一种机制。 由于没有具体的缓存策略，浏览器或代理会使用一定的算法（启发式算法）来估算一个合理的缓存时间，这个过程就是启发式缓存。这通常基于资源的最后修改时间（Last-Modified头部）来设定缓存的时长。

如果没有缓存资源，进入网络请求的流程。 那这里就有个疑问了，我们向谁发送请求呢？ 所以请求的第一步就是进行 DNS 解析，以获取请求域名的服务器 IP 地址。如果请求协议是 HTTPS，那么还需要建立 TLS 连接。

Question ​

HSTS ​

HSTS(HTTP Strict TransportSecurity)是一种新的Web安全协议，HSTS的作用是强制客户端使用HTTPS与服务器创建连接。

由于安全隐患，会使用 HSTS 强制客户端使用 HTTPS 访问页面。详见：你所不知道的 HSTS。 当你的网站均采用 HTTPS，并符合它的安全规范，就可以申请加入 HSTS 列表，之后用户不加 HTTPS 协议再去访问你的网站，浏览器都会定向到 HTTPS。无论匹配到没有，都要开始 DNS 查询工作了。

encodeURIComponent 与 encodeURI区别 ​

  • 编码范围不同、应用场景不同
  1. encodeURIComponent 用于编码 URI 的组成部分,如协议、路径、查询字符串参数等
  2. encodeURI 用于编码整个 URI

DNS域名解析 ​

DNS定义 ​

Domain Name System 域名系统， 是互联网使用的命名系统，用来把便于人们使用的域名转换为IP地址。域名是大小写无关的。 互联网的域名系统DNS被设计成一个联机分布式数据库系统，并采用客户服务器方式。 域名到IP地址的解析是由分布在互联网上的许多域名服务程序（简称域名服务器）共同完成的。 DNS的核心系统是一个三层的树状、分布式服务。对应域名的结构：

  1. 根域名服务器 （Root DNS Server）
    • 管理顶级域名服务器，返回“com” “net” “cn”等顶级域名服务器的 IP 地址；
    • 全世界目前有13组根域名服务器，又有数百台镜像。
  2. 顶级域名服务器（Top-level DNS Server）
    • 管理各自域名下的权威域名服务器，比如 com 顶级域名服务器可以返回 apple.com 域名服务器的 IP 地址；
  3. 权威域名服务器（Authoritative DNS Server）
    • 管理自己域名下主机的 IP 地址，比如 apple.com 权威域名服务器可以返回 www.apple.com 的 IP 地址。

除了上面三种DNS服务器，还有一种不在DNS层次结构之中，但是很重要的DNS服务器，就是本地域名服务器。本地域名服务器是电脑解析时的默认域名服务器，即电脑中设置的首选 DNS 服务器和备选 DNS 服务器。常见的有电信、联通、谷歌、阿里等的本地 DNS 服务。

域名解析 把域名映射到IP的过程，叫做域名解析。此过程是 计网7 中摘录。 真实情况要考虑缓存等。 域名到IP地址的解析过程要点如下： 当某一个应用进程需要把主机名解析为IP地址时，

  1. 该应用进程就调用解析程序（resolver），并成为DNS的一个客户，
  2. 把待解析的域名放在DNS请求报文中，以UDP 用户数据报的格式发送给本地域名服务器（使用 UDP 是为了减少开销）。
  3. 本地域名服务器在查找域名后，把对应的IP地址放在响应报文中返回。

DNS解析过程🔥： ​

  1. 首先搜索浏览器DNS缓存，缓存中维护一张域名与IP地址的对应表。
  2. 如果没有命中，系统DNS缓存。 Mac上 nslookup www.baidu.com可以查看系统缓存
  3. hosts文件
  4. 路由器缓存
  5. 本地域名服务器（ISP 互联网服务提供商）
  6. 根域名服务器
  7. 顶级域名服务器
  8. 权威名服务器

DNS查询过程🔥 ​

DNS的查询过程，按查询方式不同，分为递归查询 和 迭代查询。 递归查询：主机和本地域名服务器ISP之间的查询方式是递归查询。 迭代查询：本地域名服务器和其他域名服务器之间的查询方式是迭代查询，防止根域名服务器压力过大。 递归查询：迭代查询: 在实际的网络中，一般采用两段式查询过程，即先递归，后迭代。从本地主机到本地域名服务器采用递归查询，而从本地域名服务器到最终结果则采用迭代方式查询 递归查询：主机和本地域名服务器ISP之间的查询方式是递归查询。 迭代查询：本地域名服务器和其他域名服务器之间的查询方式是迭代查询，防止根域名服务器压力过大。

Question？ ​

1. 递归查询和迭代查询的区别？ ​

**递归查询(Recursive Query) **是指某个DNS服务器在收到DNS查询请求后,如果自身无法回答该请求,就以DNS客户端的身份,代理发起查询去其他DNS服务器查询,直到得到最终结果后再将结果返回给启动查询的客户端。

**迭代查询(Iterative Query) **是指DNS服务器在收到查询时,如果无法直接回答,就会将自己能够查询到的下一级DNS服务器的地址提供给发initiator,由发起查询的客户端再次向下一级DNS服务器查询,如此循环直到最终找到答案或查无结果。

简单来说:

  • 递归查询是DNS服务器代理客户端完成整个查询过程
  • 迭代查询是将查询任务转移给客户端,由客户端自行按照返回的下一步地址继续查询
2. 本地主机向ISP发起DNS查询时，使用的是UDP报文协议，为什么？ ​
  1. 低开销
    1. DNS查询报文相对较小,不需要可靠的传输,使用轻量级的UDP比重量级的TCP更加高效。
  2. 传输可靠性要求低
    1. 对于DNS查询，偶尔丢失几个查询请求或者响应报文是可以接受的，不要求100%可靠性传输。
  3. 传统惯例
    1. 如果采用TCP协议需要重新设计DNS协议格式和实现

PS：DNS查询的时候，其实也会使用TCP协议，比如在涉及大量数据传输或对传输可靠性有较高要求的场景,DNS查询就更倾向于使用TCP协议替代默认的UDP协议,以保证数据的完整性和可靠性。

  1. Zone Transfer(区域传输) 当一台DNS服务器需要从另一台服务器获取一个完整的区域数据库的副本时,需要使用TCP协议进行区域传输。区域数据量往往较大,使用UDP可能由于报文长度限制而被截断。
  2. DNS动态更新 当需要动态添加、修改或删除DNS记录时,为了保证更新操作的可靠性和原子性,通常会使用TCP协议。
  3. 查询响应超长 当DNS查询的响应超过了UDP报文最大长度(通常为512字节)限制时,DNS服务器会自动切换到TCP协议传输响应数据。较长的响应一般出现在存在大量Additional区域数据的情形。
3. 前端可以做哪些DNS查询优化？ ​
  1. 使用link rel="dns-prefetch"预解析DNS
html
<link rel="dns-prefetch" href="//example.com">

当需要加载该域名资源时已经完成了DNS解析,可以减少DNS查询延迟。但需要权衡是否增加了不必要的DNS查询开销。

  1. 使用HTTP/2

HTTP/2支持多路复用,一个连接可以并行加载多个资源,从根本上减少了DNS查询的数量。但需要服务端和客户端都支持HTTP/2。

  1. CDN分发

利用CDN进行资源分发,客户端就近访问节点,可以减少DNS查询的跨网络延迟

建立TCP连接 ​

TCP（Transmission Control Protocol，传输控制协议）连接是一种可靠的、面向连接的通讯协议。它在两个网络设备之间建立连接，确保数据可以安全、准确地传输。 TCP的特点

  1. 面向连接的，可靠的传输层协议
  2. 一个TCP连接只能从端到端（或者说点到点）
  3. 顺序性维护数据的发送和接收顺序
  4. 有拥塞控制，当网络拥塞时，TCP会自动降低数据的发送速率
  5. 全双工通讯数据可以在两个方向上同时传输

以下是TCP连接建立、维持、终止的详细流程：

TCP三次握手 ​

image.png

第一次握手（SYN）： ​

  • **SYN （seq = x）**

客户端发送**SYN包（seq=x）**的数据包到服务器，以表示开始建立连接。它包含客户端的初始序列号，用于同步。 告诉服务器，客户端准备好通信了，等待服务器确认，并进入SYN_SEND状态

第二次握手（SYN-ACK）： ​

  • **SYN （ACK = x + 1, seq = y）**** => SYN/ACK包**

服务器收到SYN包，需要确认客户的SYN, **ACK=x+1 **，同时自己也发送一个**SYN包（seq=y）**，即SYN+ACK包，此时服务器进入**SYN_RECV**状态；

ACK（确认响应）表示确认收到了客户端的初始序列号，并且加1，返回去让客服端确认服务端收到消息了 SYN 则包含服务器自己的初始序列号。用于第三次确认客服端你收到消息

第三次握手（ACK）： ​

  • **ACK( ACK = y + 1 )**

客户端收到服务器的SYN-ACK响应后，会向服务器发送一个确认段**ACK(ack=y+1)**。 这个ACK确认了服务器的初始序列号。一旦服务器接收到这个ACK段，连接就建立成功了，客户端和服务器进入ESTABLISHED状态，完成三次握手双方可以开始数据传输。

握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP连接都将被一直保持下去。 第三个包是客户端对第二个SYN-ACK包的响应。理论上，从第三次握手的ACK包开始，可以附带数据（这在TCP的快速打开（TFO）中有体现），但在传统的TCP建立连接中，这种做法不常见，因为大多数TCP协议栈会等到连接完全建立后再发送数据。

四次挥手 ​

四次挥手的过程是当数据传输完成后，用于双方同意并确认断开已建立的TCP连接。

第一次挥手（FIN）： ​

发起关闭连接的一方（假设为客户端）发送一个FIN（结束）标志的TCP段给对方，表示没有数据发送了，并希望关闭连接。

第二次挥手（ACK）： ​

服务器收到这个FIN段后，发送一个ACK段给客户端，确认收到了客户端的终止请求，但服务器可能还有数据需要处理和发送。

第三次挥手（FIN）： ​

一旦服务器处理完毕其剩余的数据，也准备好关闭连接时，它会再发送一个带有FIN标志的TCP段给客户端，通知客户端所有的数据都发送完毕了。

第四次挥手（ACK）： ​

客户端收到服务器的FIN之后，它发送一个ACK给服务器。然后，客户端会等待足够长的时间（等待2MSL，即最大报文生存时间）以确保服务器接收到ACK。之后，客户端关闭连接，服务器在收到ACK之后也会关闭连接。

三次握手主要确保双方都能接收和发送数据，而四次挥手则确保双方数据传输完成，并同意关闭连接。

Question？ ​

TCP 和 UDP 的区别？ ​

TCP的特点：

面向连接： 在数据传输前，必须先建立连接（三次握手过程）。 可靠性： 确保数据正确无误地到达接收端，通过确认应答（ACK）和数据重传进行错误修复。 顺序性： 维护数据的发送和接收顺序。 拥塞控制： 当网络拥塞时，TCP会自动降低数据的发送速率。 流量控制： 使用滑动窗口机制来避免发送方使接收方缓冲区溢出。 全双工通信： 数据可以在两个方向上同时传输。

UDP的特点：

无连接： 发送数据之前不需要建立连接。 不可靠性： 数据包可能丢失或到达顺序可能错乱，并且没有内置的方式来检测或修复。 无顺序性： 不保证包的发送和到达顺序。 轻量级： 头部开销小，仅有8字节，不进行连接管理。 无拥塞控制： 无论网络状况如何，总是以同样的速率发送数据。

TCP与UDP的区别：

连接： TCP是面向连接的，而UDP是无连接的。 可靠性： TCP提供可靠的服务，UDP则不保证数据一定会被接收。 速度： 由于TCP有建立连接、确认、拥塞控制等过程，其速度通常比UDP慢。 头部大小： TCP头部至少20字节，相比之下，UDP只有8字节。 使用场景： TCP适用于对可靠性要求高的应用，如网页浏览、文件传输、邮件发送等。UDP适合于实时性要求高的应用，如视频会议、在线游戏和流媒体，以及其他容忍丢包的场合。

总之，TCP更关注可靠性和顺序性，适合要求高度可靠性的数据传输。而UDP则关注速度和效率，适合于对速度要求高但可以容忍一定数据丢失的场合。 另外补充， TCP 面向字节流， UDP 面向报文传输。面向字节流的TCP是一种流式传输，发送的数据没有固定边界，由协议层根据最优的传输进行分段和重组。而面向报文的UDP则保持了数据的边界，每个UDP数据报的发送和接收都是独立的

为什么是三次握手？ ​

  1. 确认双方的接收与发送能力：
    • 第一次握手（SYN）-客户端发送SYN包以表明其希望开始通信，并且能发送数据。
    • 第二次握手（SYN-ACK）-服务器回应SYN-ACK包以表明同意建立连接，并且它也能接收数据。
    • 第三次握手（ACK）-客户端回应ACK包以确认接收到服务器的同步请求，并且准备好接收数据。
  2. 防止失效的连接请求建立连接：
    • 可能存在网络延迟，导致失效的连接请求（过时的SYN包）在网络中延迟到达服务器。如果不进行三次握手，服务器可能会错误地打开一个无意义的连接，浪费资源。
  3. 初始化序列号以避免混淆：
    • 为了保证数据包的顺序和完整性，TCP连接的每一方都有独立的序列号。在三次握手过程中，这些序列号被初始化和确认，为后续的数据传输提供同步点。
  4. 建立连接参数：
    • 在握手过程中，双方可以交换有关如何进行后续通信的参数信息，如窗口大小（用于流量控制）和最大报文段长度（MSS）。

为什么是四次挥手？ ​

由于TCP是全双工通信，每个方向的关闭都需要确认，因此无法在发送完数据后立即完全关闭连接。

  • 结合过程描述。

为什么客户端在四次挥手后要等待2MSL（Maximum Segment Lifetime）？ ​

客户端在发送最后一个ACK之后会进入TIME_WAIT状态，等待2MSL时间，这是

  1. 为了确保服务器接收到最后的ACK。如果服务器没有收到ACK，它会重传FIN+ACK包。
  2. 这段时间也足以确保网络中所有该连接的副本分组都会在网络中消失，这样可以清除旧的分组，避免在后续新的连接中出现旧分组。

TCP如何保证数据包的顺序性和可靠性？ ​

  1. 顺序性：TCP通过在每个数据包中加入序列号来保证数据的顺序性，接收方可以根据序列号重新排列乱序到达的数据段。
  2. 可靠性：TCP的确认应答机制（发送ACK）和超时重传机制（如果长时间未收到ACK就重传数据段）则保证了数据的可靠性。

对于丢包情况，发送方没有收到对应数据段的ACK将重传那个数据段。

发送HTTP请求 ​

TCP三次连接成功后，浏览器构建HTTP请求报文，并通过建立的TCP连接发送到服务器。 请求报文含请求行（如GET/POST）、请求头和请求体。

请求报文 ​

image.png

响应报文 ​

image.png

状态码 ​

http状态码 ​

三位数字组成，在network => 网络中查看 http 响应状态码（Status Code）由三位数字组成，用来标识响应成功与否的状态。 在状态行中所包含的状态码，叫做响应状态码 / http状态码 响应状态码是由 http 协议规定的，具有通用性。每个不同的状态码都有其标准的含义，不能乱用。

常见的http状态码 ​

image.png

浏览器解析渲染 ​

解析服务端返回的HTML网页数据，并进行渲染，这个过程的5个关键步骤： ①构建DOM树 => ②构建CSS规则树 => ③构建渲染树 => ④布局 => ⑤绘制 image.png

**① DOM 树**：根据 HTML 解析出** DOM 树（DOM Tree）**

  1. 从上往下解析HTML内容，按照标签结构构造DOM树，构建过程采用深度优先遍历，即先构建当前节点的所有子节点，然后才继续下一个兄弟节点。
  2. 当遇到外部css链接文件、图片资源时，会异步发起资源请求，不影响HTML解析。
  3. 解析中如遇到<script>脚本（没有async、defer），会等待脚本执行完才继续，如果是外部JS文件，还得等JS先下载再执行。这么做的目的是JS代码可能会修改DOM树和CSS样式，避免造成回流和重绘。
  4. 遇到设置async和defer的<script>脚本，创建新的线程异步加载，继续解析HTML。async加载完马上执行，defer在DOMContentLoaded前执行。

image.png**② CSS规则树**：根据 CSS 解析生成 CSS 规则树（CSS Rule Tree）

  • 对CSS内容进行词法分析、语法分析，解析CSS规则，构建CSS规则树。

**③ 渲染树**：DOM 树 + CSSOM 规则树，生成渲染树 （Render Tree）

  • 渲染树只包含需要显示的节点，及其样式信息，样式信息是来自CSS规则树的样式规则（CSS Rule）。

**④ 布局/回流**：根据渲染树计算每一个节点的位置的过程，就是布局。

  • 布局（Layout）：通过渲染树中渲染对象的信息，计算出每一个渲染对象的确切位置和尺寸，就是布局的过程。HTML的布局是自上而下、从左到右流式排列，位置是是会相互影响的，一个元素位置、大小变化会影响整体（其后续）布局，导致回流的发生。布局的开销是比较大的，要尽量避免频繁布局。
  • 回流（Reflow）：某个部分发生了变化影响了布局，如DOM的新增、删除，某个元素的位置尺寸发生了变化，那就需要倒回去重新布局>渲染。

**⑤ 渲染**：根据计算好的信息绘制页面，通过调用操作系统Native GUI的API绘制，将呈现器的内容显示在屏幕上。

  • 重绘（Repaint）：某个元素的背景颜色，文字颜色的变化，不影响元素周围或内部布局，不需要重新布局，就需只需要浏览器重绘即可。

Question ​

script标签中defer和async的区别? ​

参考我的github解答: https://github.com/zxdfe/FE-Interview/issues/11对于async 和 defer script， 下载时都不会阻碍HTML的解析

  1. **普通的script **：下载会阻碍 HTML 解析，下载好并执行完脚本才会继续解析 HTML。
  2. **async script **：async表示异步，解析 HTML 过程中进行脚本的异步下载，下载成功立马执行，会阻断 HTML 的解析。
  3. defer script：defer表示延迟，完全不会阻碍 HTML 的解析，解析完成之后再按照顺序执行脚本。

image.png小结

  1. 加载时机：

两者都不会阻塞HTML的解析过程，但是async脚本一旦下载完毕就会暂停HTML解析，立即执行，而defer脚本会等到整个HTML文档解析完成后，再按顺序执行。

  1. 执行时机：

async脚本的执行时机无法确切预测，因为一旦加载完成即刻执行；而defer脚本会等文档解析结束后，但在DOMContentLoaded事件之前按顺序执行。

  1. 文档顺序：

async脚本可能不会按照它们在HTML中出现的顺序执行，而defer脚本则保证了执行顺序

回流和重绘的区别 ​

回流（Reflow）和重绘（Repaint）都是浏览器优化性能时需要尽量减少的过程。

回流（Reflow） ​
  • 回流是指浏览器重新计算页面元素的位置和大小的过程。当DOM的变化影响到元素的几何信息（比如宽度、高度、位置等）时，浏览器会重新计算页面的布局。
  • 任何影响到DOM节点几何信息的更改都会导致回流。
  • 回流是一个昂贵的操作，它会破坏页面的布局，在构建新布局之前，当前的布局必须被废弃。因此，每次回流都会造成页面渲染的显著性能问题。
重绘（Repaint） ​
  • 重绘发生在当页面的一部分由于颜色或可见性等而需要更新。
  • 比如改变元素的颜色、阴影、背景等属性会导致重绘。
  • 重绘不涉及布局阶段，它通常比回流的成本要低，但频繁的重绘依然会影响页面性能。
区别 ​
  1. 回流涉及到布局的变化，因此对DOM的操作比重绘更加昂贵；重绘则只与视觉效果相关，比如颜色、背景色的改变。
  2. **回流必定会触发重绘，**因为布局的更改会导致新的渲染树，且元素需以新样式绘制。但是，重绘不一定伴随回流，如果样式变更不影响布局，就只会发生重绘。
  3. 优化：
    1. 减少DOM和CSS变更频率，批量更新样式，
    2. 避免使用复杂的CSS选择器，
    3. 使用绝对定位使得元素脱离文档流等可以减少回流；

断开连接 ​

也就是四次挥手，见上面整理的知识点~~

优化建议 ​

网络层面： ​

  1. 使用CDN（内容分发网络）：
    • CDN可以减少资源加载时间，将内容分发到离用户更近的服务器。
  2. 开启压缩：
    • 通过Gzip或Brotli之类的压缩算法，减少文件的传输大小。
  3. 优化图片和多媒体内容：
    • 使用现代、高效的图片格式如WebP。
    • 对图片进行压缩，并提供适合屏幕大小的版本。
  4. DNS预解析：
    • 对于第三方资源，使用dns-prefetch来提前解析DNS，并通过preconnect或prefetch预先建立连接。
  5. 使用HTTP/2：
    • 相比HTTP/1.1，HTTP/2 提供了头部压缩、服务器推送、请求管线化和多路复用。
  6. 缓存策略优化：
    • 妥善配置缓存策略，设置适当的Cache-Control头部，使得浏览器能够缓存并复用资源。
  7. 减少HTTP请求：
    • 通过合并文件、CSS Sprites等方式减少请求的数量。

前端渲染层面 ​

  1. 优化CSS和JavaScript加载：
    • 使用标签上的rel=preload为关键CSS文件做预加载。
    • 有选择性地使用async和defer属性加载JavaScript文件，以避免阻塞DOM解析。
  2. 关键渲染路径优化：
    • 确定关键CSS，使得首屏内容可以快速渲染。
    • 削减JavaScript和CSS资源，延迟加载非关键资源。
  3. 优化JavaScript执行：
    • 减少JavaScript代码体积，移除未使用代码。
    • 使用Web Workers进行非UI关联的重计算。
  4. 使用懒加载：
    • 对于图片、视频和越界的DOM元素，使用懒加载技术，这样用户不会立刻看到这些内容。
  5. 优化字体加载：
    • 选择仅所需的字体样式和字符集，避免大量的字体文件下载。
  6. Web Performance API：
    • 利用Navigation Timing API, Resource Timing API等工具监测性能，并根据收集到的数据做针对性优化。
  7. 服务端渲染（SSR）或静态生成（SSG）：
    • 如果使用JavaScript框架构建的单页应用（SPA），可以采用服务端渲染或静态生成来改进首次页面加载速度。

模型结构 ​

OSI七层模型 ​

  1. 应用层(Application Layer)
    • 为应用程序提供网络服务,如HTTP,FTP,DNS等协议
  2. 表示层(Presentation Layer)
    • 负责数据的加密、压缩和格式转换
  3. 会话层(Session Layer)
    • 建立、管理和终止表示层实体间的通信会话
  4. 传输层(Transport Layer)
    • 提供端到端的可靠传输和复用服务,如TCP和UDP协议
  5. 网络层(Network Layer)
    • 决定数据传输路径,如IP协议
  6. 数据链路层(Data Link Layer)
    • 在相邻节点间传输数据帧,检测并重发丢失帧
  7. 物理层(Physical Layer)
    • 定义网络硬件的电气、机械和功能标准

TCP/IP四层模型 ​

  1. 应用层(Application Layer)
    • 为应用程序提供服务,如HTTP、FTP、SMTP等协议都位于这一层。
  2. 传输层(Transport Layer)
    • 为端到端的通信提供可靠的数据传输服务,主要协议有TCP和UDP协议。
  3. 网际层(Internet Layer)
    • 负责设备到设备的数据传输,最主要的协议是IP协议。
  4. 网络接口层/链路层(Network Interface/Link Layer)
    • 负责操作单个跳数据传输,常见协议有以太网协议、WIFI协议等。

这4层按自顶向下的顺序,每一层依赖于下一层提供更底层的网络传输服务。

  • 应用层定义了应用程序如何传输数据
  • 传输层保证了端到端的通信可靠传输
  • 网际层负责设备之间路由和寻址
  • 网络接口层负责在相邻节点间传输数据

TCP/IP四层模型清晰地划分了互联网通信的不同层面职责,为实现复杂的网络通信提供了模块化的解决方案。

TCP/IP ​

当提到TCP/IP协议时,通常是指TCP/IP四层参考模型及其对应的协议集。

  1. TCP (Transmission Control Protocol, 传输控制协议)
    • 面向连接的可靠传输协议
    • 在发送数据前,需要三次握手建立连接
    • 数据传输可靠,有序到达,且不会重复或遗失
    • 常用于电子邮件、文件传输等场景
  2. IP (Internet Protocol, 互联网协议)
    • 无连接、不可靠数据包传输协议
    • 负责路由寻址和数据传输
    • 通过IP地址标识互联网上的设备位置
    • 数据包可能重复、丢失、乱序到达
    • 常与诸如TCP、UDP等协议配合使用

TCP/IP协议簇包含了一整套互联网相关的协议,共同控制着互联网络上数据的传输和通信方式。TCP和IP只是两个核心部分,其他协议如HTTP、FTP、SMTP、UDP等也都属于TCP/IP协议簇的范畴。

  1. 阿里面试官的”说一下从url输入到返回请求的过程“问的难度就是不一样
  2. 从输入URL开始建立前端知识体系 - 掘金 -SS
  3. 浏览器和网络
  4. 从输入页面地址到展示页面信息都发生了些什么 good
  5. https://segmentfault.com/a/1190000006879700
  6. https://zhuanlan.zhihu.com/p/57895541
  7. 在浏览器输入 URL 回车之后发生了什么（超详细版） good!
  8. 从输入 URL 到页面加载完成，发生了什么？在此流程中做优化！
  9. 从输入URL到页面展示，这期间发生了神魔？
  10. 输入URL后都发生这些事情！
  11. 史上最详细的经典面试题 从输入URL到看到页面发生了什么？ - 掘金
  12. 「导航渲染流程」你真的知道从输入URL到页面展示发生了什么吗？（内附思维导图） - 掘金 -A
  13. 输入URL后都发生这些事情！