春招八股学习笔记——URL输入到页面展示全流程详解

在春招面试中，“从URL输入到页面展示中间经历了什么”是前端、后端、测试等多个岗位的高频经典考题，考察概率高达80%。该问题看似简单，实则贯穿了计算机网络、操作系统、前端渲染等多个核心知识点，能全面检验求职者的知识体系完整性和逻辑组织能力。本次学习笔记将以该问题为核心，结合参考资料中的考点的细节，系统拆解整个流程，补充相关延伸知识点，帮助梳理知识脉络，应对春招面试中的各类相关提问。

本文核心学习目标：掌握URL输入到页面展示的完整流程，理解各环节的底层原理，明确计算机网络（DNS解析、HTTP请求）、操作系统（进程/线程、进程间通信）、前端渲染的关联关系，能够按知识体系清晰、流畅地阐述整个过程，避免零散知识点的堆砌。

一、前置核心概念梳理（基础必备）

在拆解完整流程前，需先明确参考资料中提到的核心概念，这些概念是理解整个流程的基础，也是面试中高频追问的要点，尤其涉及操作系统和浏览器架构相关内容，必须扎实掌握。

1.1 操作系统核心考点：进程与线程

参考资料明确指出：操作系统中，进程是分配资源的最小单元，线程是执行的最小单元，二者既有区别又有紧密关联，具体细节如下：

进程（Process）：是操作系统进行资源分配和调度的基本单位，每个进程都有自己独立的内存空间、文件描述符、进程控制块（PCB）等资源，进程之间相互独立，互不干扰。例如，我们打开的浏览器、微信、记事本，都是独立的进程。进程的创建、销毁、切换开销较大，因为涉及到资源的分配和释放。

线程（Thread）：是进程内的执行单元，一个进程可以包含多个线程，所有线程共享该进程的资源（如内存空间、文件描述符），但每个线程有自己独立的程序计数器、栈空间。线程的创建、销毁、切换开销远小于进程，因为无需重新分配资源，只需切换执行上下文即可。例如，浏览器的渲染进程中，有负责解析HTML的线程、负责执行JS的线程、负责渲染页面的线程等。

补充延伸：进程与线程的核心区别的在于资源分配和独立性——进程独立分配资源，线程共享进程资源；进程崩溃通常不会影响其他进程，而线程崩溃可能导致整个进程崩溃。

1.2 浏览器多进程架构（关键核心）

参考资料强调，浏览器是多进程架构，整个URL请求到页面展示的过程，需要浏览器各个进程之间的协同配合，每个进程承担不同的职责，缺一不可。浏览器的多进程架构主要包括以下核心进程，结合参考资料细节拆解如下：

（1）浏览器主进程（Browser Process）

浏览器主进程是整个浏览器的“总指挥”，负责统筹协调其他所有子进程，核心职责如下（参考资料重点内容）：

• 处理用户交互：接收用户的操作指令，如URL输入、点击链接、刷新页面、关闭标签页等，并提供相应的反馈。
• URL输入处理：当用户在地址栏输入内容后，由主进程接收并判断输入内容是URL还是搜索关键词，进而执行不同的处理逻辑。
• 浏览历史管理：将用户的浏览记录入栈，支持前进、后退等操作，本质是对浏览历史链表的维护。
• 请求状态展示：负责控制页面加载时的loading图标显示与隐藏——网络请求开始时，显示loading图标；请求完成（无论成功或失败）时，隐藏loading图标；同时将网络进程获取到的资源转发给渲染进程。
• 子进程管理与进程间通信（IPC）：负责创建、管理所有子进程（如网络进程、渲染进程、插件进程等），并通过IPC（Inter-Process Communication，进程间通信）机制实现各进程之间的信息交互。因为不同进程的内存空间相互独立，无法直接访问，所以需要通过IPC机制传递数据，这是浏览器多进程协同工作的核心。
• 页面状态管理：当当前页面被替换、刷新或关闭时，触发beforeunload事件，提示用户是否确认离开当前页面；同时管理页面的缓存、Cookie、localStorage等数据存储。

补充说明：浏览器主进程的核心作用是“统筹协调”，不参与具体的资源下载和页面渲染，仅负责调度和管理，确保整个浏览器的正常运行。

（2）网络进程（Network Process）

网络进程是浏览器的“网络请求工具”，核心职责是面向渲染进程、浏览器主进程等提供网络下载功能，负责所有URL请求的发起、响应处理、资源下载等操作，是URL请求流程的核心执行单元。

具体职责包括：URL补全、DNS解析、TCP连接建立、HTTP请求发送、响应接收与解析、资源缓存管理等，后续流程拆解中会详细说明。

（3）渲染进程（Renderer Process）

渲染进程是页面展示的“核心执行者”，负责将网络进程下载的资源（HTML、CSS、JS、图片等）解析、渲染成用户可见的页面。每个标签页通常对应一个独立的渲染进程（特殊情况如同一域名的页面可能共享渲染进程），这样可以避免单个页面崩溃影响其他页面。

渲染进程内部包含多个线程，如HTML解析线程、CSS解析线程、JS执行线程、渲染线程等，后续前端渲染环节会详细拆解。

（4）其他辅助进程

除上述核心进程外，浏览器还包括插件进程（负责运行浏览器插件，如Flash插件）、GPU进程（负责页面渲染的硬件加速，尤其处理复杂的图形渲染、动画等）等，这些进程根据浏览器的配置和用户操作动态创建和销毁。

1.3 其他基础概念补充

（1）IPC机制：Inter-Process Communication，进程间通信，是多进程架构中不同进程之间传递信息的核心方式。浏览器中常用的IPC方式包括管道、消息队列、共享内存等，具体实现因浏览器内核（如Chrome的Blink内核）不同而有差异，但核心作用都是实现进程间的协同。

（2）缓存机制：浏览器为了提升请求效率，减少网络请求，会对已下载的资源进行缓存，分为本地缓存（如浏览器缓存、本地DNS缓存）、服务器缓存等，后续流程中会详细说明缓存的作用和触发逻辑。

（3）HTTP相关概念：请求行、请求头、响应头、状态码等，是网络请求的核心组成部分，参考资料中提到的jwt token、Cookie、Content-Type等，都是HTTP请求/响应中的关键信息。

二、URL输入到页面展示完整流程拆解（核心重点）

从用户在浏览器地址栏输入URL，到页面完全展示，整个过程可分为7个核心环节，每个环节紧密衔接，涉及计算机网络、操作系统、前端渲染等多个知识点，结合参考资料细节，按顺序逐一拆解，确保逻辑清晰、知识点完整，避免零散蹦知识点。

环节1：用户输入URL，浏览器主进程接收并处理输入内容

这是整个流程的起点，核心是浏览器主进程判断用户输入的内容是“URL”还是“搜索关键词”，并执行对应的处理逻辑，具体步骤如下：

1. 用户在浏览器地址栏输入内容（如“time.geekbang.org”或“极客时间”），松开键盘后，浏览器主进程立即接收该输入内容。

2. 浏览器主进程对输入内容进行判断，区分两种情况：

• 情况1：输入内容是搜索关键词（如“极客时间”“春招八股”），且不满足URL格式（无http/https协议、无域名后缀等），浏览器主进程会将该关键词拼接到底层默认的搜索引擎URL后，生成完整的URL
• 情况2：输入内容是URL，浏览器主进程会对URL进行补全处理，补充协议头（http:// 或https:// ）、www前缀（部分URL可省略），生成标准的URL格式。如http:// 浏览器会自动补全为https:// 。

3. 补充说明：参考资料中提到“time.geekbang.org”的补全的和跳转逻辑——若用户输入http:// 开头的网址，服务器会返回301（永久重定向）或302（临时重定向）、307（临时重定向）状态码，同时在响应头中通过“location: https:// ”指定跳转地址，浏览器主进程接收该响应后，会自动跳转到https协议的URL，这是因为当前浏览器普遍强制使用https协议，保障数据传输的安全性。

4. 此时，浏览器主进程会触发浏览历史入栈操作，将当前准备访问的URL加入浏览历史链表，同时准备启动网络进程，将补全后的标准URL转发给网络进程，开启后续的网络请求流程。

环节2：网络进程接收URL，执行DNS解析（获取IP地址）

URL的核心作用是定位网络资源，但计算机网络中，设备之间的通信是通过IP地址实现的（OSI七层协议中，网络层通过IP地址定位设备），而URL中的域名（如“time.geekbang.org”）是为了方便用户记忆，无法直接用于设备通信。因此，网络进程接收URL后，首先需要通过DNS解析，将域名转换为对应的IP地址，这是网络请求的前提。

参考资料中明确提到，DNS（Domain Name System，域名系统）是一个分布式的数据库，核心作用是“域名→IP地址”的映射，类似“电话簿”——域名是“姓名”，IP地址是“电话号码”，DNS的作用就是根据“姓名”找到对应的“电话号码”。DNS解析的流程遵循“从本地到远程”的顺序，优先使用缓存，提升解析效率，具体步骤如下：

2.1 DNS解析的完整流程（参考资料重点拆解）

1. 本地DNS缓存查找：网络进程首先查询本地DNS缓存（浏览器缓存、操作系统缓存），查看是否有该域名对应的IP地址。本地缓存是为了减少网络请求，提升解析速度，缓存有一定的过期时间（由DNS服务器设置），若缓存未过期，直接获取IP地址，跳过后续解析步骤。
2. 局域网缓存查找：若本地DNS缓存中未找到对应的IP地址，网络进程会向局域网内的DNS服务器（如路由器的DNS）发送查询请求，路由器通常会缓存常用域名的IP地址，若找到，直接返回IP地址。
3. 运营商DNS服务器查询：若局域网缓存未找到，网络进程会向用户所在的运营商DNS服务器（如参考资料中的“抚州电信DNS服务器”）发送查询请求。运营商DNS服务器拥有大量的域名-IP映射缓存，是DNS解析的重要环节，大部分常见域名的IP地址都能在这里找到。
4. 根服务器查询：若运营商DNS服务器未找到对应的IP地址，会向全球13台根服务器（分布在世界各地，其中部分位于美国，通过海底光缆连接）发送查询请求。根服务器不直接存储域名-IP映射，而是告知运营商DNS服务器该域名对应的顶级域名服务器（如.com、.org、.cn等对应的服务器）地址。
5. 顶级域名服务器查询：运营商DNS服务器向根服务器返回的顶级域名服务器发送查询请求（如“time.geekbang.org”的顶级域是“.org”，则向.org顶级域名服务器查询）。顶级域名服务器同样不存储具体的IP地址，而是告知该域名对应的权威DNS服务器地址。
6. 权威DNS服务器查询：运营商DNS服务器向权威DNS服务器（该域名的所属机构搭建的DNS服务器，如极客时间的权威DNS服务器）发送查询请求，权威DNS服务器存储着该域名对应的IP地址，会将IP地址返回给运营商DNS服务器。
7. 结果返回与缓存：运营商DNS服务器将获取到的IP地址返回给浏览器的网络进程，同时将该域名-IP映射存入自身缓存，方便后续其他用户查询；网络进程也会将该IP地址存入本地缓存，供本次请求使用。

2.2 DNS解析的补充知识点（面试高频）

（1）DNS解析的类型：分为递归查询和迭代查询。递归查询是指网络进程向本地DNS服务器发送请求后，本地DNS服务器负责全程查询，直到获取IP地址并返回给网络进程；迭代查询是指本地DNS服务器向根服务器、顶级域名服务器等发送请求时，对方仅返回下一级服务器地址，本地DNS服务器需自行继续查询，直到获取IP地址。实际应用中，通常是“递归查询+迭代查询”结合——网络进程与本地DNS服务器之间是递归查询，本地DNS服务器与根服务器、顶级域名服务器之间是迭代查询。

（2）DNS缓存的层级：从本地到远程，分为4级缓存——浏览器缓存、操作系统缓存、路由器缓存、运营商DNS缓存，缓存层级越靠前，解析速度越快，开销越小。

（3）DNS负载均衡：大型网站（如淘宝、百度）通常会有多个IP地址，权威DNS服务器会根据用户的地理位置、服务器负载情况，返回不同的IP地址，实现负载均衡，提升网站的访问速度和稳定性。例如，用户在上海访问淘宝，DNS解析会返回上海地区的服务器IP；用户在北京访问，会返回北京地区的服务器IP。

（4）DNS解析的优化：除了缓存，常见的优化方式还有DNS预解析（浏览器提前解析页面中可能用到的域名）、HTTPDNS（绕过运营商DNS，直接向权威DNS服务器查询，避免运营商DNS劫持）等。

环节3：网络进程建立TCP连接（三次握手）

获取到IP地址后，网络进程需要与该IP地址对应的服务器建立TCP连接，因为HTTP协议（超文本传输协议）是基于TCP协议的（面向连接、可靠传输），只有建立TCP连接后，才能进行HTTP请求的发送和响应的接收。参考资料中强调，三次握手的核心目的是“确保双方都具有请求发送和接收的能力”，避免出现一方能发送但另一方无法接收的情况，保证数据传输的可靠性。

TCP（Transmission Control Protocol，传输控制协议）是一种面向连接、可靠的、基于字节流的传输层协议，其核心特点是“可靠传输”——通过确认机制、重传机制、流量控制、拥塞控制等，确保数据能够完整、有序地传输到对方。三次握手的具体流程如下（结合参考资料，详细拆解每一步的作用）：

3.1 TCP三次握手的具体步骤

假设浏览器的网络进程为“客户端”，目标服务器为“服务器端”，双方通过三次握手建立连接：

1. 第一次握手（客户端→服务器端）：客户端（网络进程）向服务器端发送一个SYN（同步）报文段，报文段中包含客户端的初始序列号（seq=x），同时告知服务器端“我准备好发送数据了，请你做好接收准备”。此时，客户端进入SYN_SENT状态，等待服务器端的响应。
2. 第二次握手（服务器端→客户端）：服务器端接收到客户端的SYN报文段后，确认自己能够接收客户端的请求，于是向客户端发送一个SYN+ACK（同步+确认）报文段。该报文段中包含服务器端的初始序列号（seq=y），以及对客户端SYN报文段的确认号（ack=x+1，含义是“我已经收到了你发送的seq=x的报文段，请你下次发送seq=x+1及以后的数据”）。此时，服务器端进入SYN_RCVD状态，等待客户端的确认。
3. 第三次握手（客户端→服务器端）：客户端接收到服务器端的SYN+ACK报文段后，确认服务器端已经做好接收准备，于是向服务器端发送一个ACK（确认）报文段。该报文段中包含对服务器端SYN报文段的确认号（ack=y+1，含义是“我已经收到了你发送的seq=y的报文段，请你下次发送seq=y+1及以后的数据”），同时客户端的序列号更新为seq=x+1。此时，客户端进入ESTABLISHED状态（连接建立完成）；服务器端接收到ACK报文段后，也进入ESTABLISHED状态，TCP连接正式建立。

3.2 三次握手的核心意义（面试必答）

为什么需要三次握手，而不是两次或四次？核心原因是“确保双方的发送和接收能力都正常”，具体分析如下：

• 两次握手无法确保客户端能接收服务器端的响应：假设客户端发送的SYN报文段丢失，服务器端没有收到，就不会发送响应；但如果客户端发送的SYN报文段没有丢失，服务器端收到后发送SYN+ACK报文段，但该报文段丢失，客户端没有收到确认，会认为连接未建立，而服务器端会认为连接已建立，等待客户端发送数据，导致资源浪费。两次握手无法解决这种“单向连接”的问题。

• 三次握手可以完美解决上述问题：第三次握手的ACK报文段，是客户端对服务器端SYN+ACK报文段的确认，确保服务器端知道“客户端已经收到了我的响应，能够正常接收数据”，此时双方都确认了对方的发送和接收能力，连接正式建立，避免了资源浪费和连接异常。

• 四次握手没有必要：三次握手已经能确保双方的发送和接收能力，第四次握手不会增加可靠性，反而会增加网络开销和连接建立的时间，因此TCP协议设计为三次握手。

3.3 补充知识点：TCP连接的特点与后续处理

（1）TCP连接的特点：面向连接（必须先建立连接才能传输数据）、可靠传输（通过确认、重传机制保证数据完整）、面向字节流（将数据拆分为字节流传输，接收方再重组）、双工通信（双方可以同时发送和接收数据）。

（2）端口号的作用：TCP连接建立时，除了IP地址，还需要端口号来定位服务器端的具体服务。例如，HTTP协议默认端口号是80，HTTPS协议默认端口号是443，服务器端会监听对应的端口号，接收客户端的请求。因此，DNS解析获取IP地址后，网络进程会结合URL中的协议，确定对应的端口号（若URL中未指定端口号，使用默认端口号）。

（3）HTTPS的额外步骤：如果URL使用的是HTTPS协议（当前主流），在TCP三次握手建立完成后，还需要进行TLS/SSL握手，建立加密连接，确保数据传输的安全性。TLS/SSL握手的核心是身份验证（确认服务器端的身份，避免中间人攻击）和密钥协商（生成对称加密密钥，用于后续数据的加密传输）。

环节4：网络进程发送HTTP请求（请求行+请求头）

TCP连接建立完成后，网络进程开始向服务器端发送HTTP请求，HTTP请求由“请求行、请求头、请求体”三部分组成（参考资料中重点提到了请求行和请求头，结合延伸知识点补充完整），其中请求体仅在POST、PUT等请求方法中存在，GET请求通常没有请求体。

4.1 HTTP请求的组成（结合参考资料细节）

（1）请求行（Request Line）

请求行是HTTP请求的第一行，包含三个核心部分：请求方法、请求URL、HTTP协议版本，格式为“请求方法 请求URL HTTP版本”。

参考资料中提到的GET请求，是最常用的请求方法，核心作用是“获取服务器端的资源”（如HTML页面、图片、CSS文件等）。除此之外，常见的请求方法还有POST（提交数据到服务器端，如表单提交）、PUT（更新服务器端的资源）、DELETE（删除服务器端的资源）、HEAD（仅获取响应头，不获取响应体）等。

（2）请求头（Request Headers）

请求头是HTTP请求的核心部分，用于向服务器端传递额外的信息，如客户端的身份、请求的资源类型、缓存控制、认证信息等，参考资料中重点提到的jwt token、Cookie都属于请求头的内容，常见的请求头如下：

• Host：指定服务器端的域名和端口号，如“Host: time.geekbang.org”，用于服务器端区分不同的网站（同一台服务器可能托管多个网站，通过Host字段区分）。
• User-Agent（UA）：标识客户端的浏览器类型、操作系统版本等信息，如“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36”，服务器端可以根据UA信息返回适配不同浏览器的资源。
• Authorization：用于传递认证信息，参考资料中提到的jwt token就通过该字段传递，格式为“Authorization: Bearer ”，服务器端通过解析token，验证用户的身份。
• Cookie：用于传递客户端的Cookie信息，Cookie是浏览器存储在本地的小型文本文件，包含用户的登录状态、偏好设置等信息，服务器端可以通过Cookie识别用户身份，实现会话保持（如登录后无需重复登录）。
• Accept：指定客户端能够接收的资源类型，如“Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8”，表示客户端能够接收HTML、XML等类型的资源。
• Accept-Encoding：指定客户端能够支持的压缩格式，如“Accept-Encoding: gzip, deflate, br”，服务器端可以对资源进行压缩后传输，减少网络传输量，提升传输速度。
• Cache-Control：用于控制缓存，如“Cache-Control: max-age=3600”，表示该请求的缓存有效期为3600秒（1小时），在有效期内，浏览器可以直接使用缓存，无需重新发送请求。

（3）请求体（Request Body）

请求体仅在POST、PUT等请求方法中存在，用于向服务器端提交数据，如表单数据、JSON数据等。例如，用户登录时，用户名和密码会通过POST请求的请求体发送到服务器端，请求体的格式由请求头中的“Content-Type”字段指定（如“Content-Type: application/json”表示请求体是JSON格式）。

4.2 HTTP请求的发送逻辑（参考资料重点）

网络进程发送HTTP请求时，会先检查本地缓存（浏览器缓存），如果请求的资源在本地缓存中存在，且缓存未过期（根据Cache-Control、Expires等字段判断），则直接从缓存中获取资源，无需向服务器端发送请求，这就是参考资料中提到的“如果本地有缓存，不用请求，直接使用缓存”，核心目的是提升请求效率，减少网络开销。

若本地缓存中没有该资源，或缓存已过期，则网络进程会将请求行、请求头（以及请求体，若有）组装成完整的HTTP请求报文，通过已建立的TCP连接，发送到服务器端，等待服务器端的响应。

环节5：服务器端处理请求，返回HTTP响应（响应头+响应体）

服务器端接收到网络进程发送的HTTP请求后，会对请求进行解析（解析请求方法、请求URL、请求头、请求体等），然后根据请求内容处理对应的业务逻辑（如查询数据库、读取静态资源等），处理完成后，向网络进程返回HTTP响应。HTTP响应与HTTP请求对应，由“响应行、响应头、响应体”三部分组成，参考资料中重点提到了响应头和状态码，详细拆解如下：

5.1 HTTP响应的组成

（1）响应行（Response Line）

响应行是HTTP响应的第一行，包含三个核心部分：HTTP协议版本、状态码、状态描述，格式为“HTTP版本 状态码 状态描述”。

状态码是服务器端对请求处理结果的标识，参考资料中提到了301、302、307等重定向状态码，除此之外，常见的状态码分为5类，每类对应不同的处理结果，面试中高频考察，需重点记忆：

• 1xx（信息性状态码）：表示服务器端已接收请求，正在处理，如100（Continue，表示客户端可以继续发送请求体）。
• 2xx（成功状态码）：表示请求处理成功，如200（OK，表示请求成功，响应体包含请求的资源）、204（No Content，表示请求成功，但响应体为空）。
• 3xx（重定向状态码）：表示请求需要进一步操作才能完成，如参考资料中提到的301（Moved Permanently，永久重定向，请求的资源已永久迁移到新的URL）、302（Found，临时重定向，请求的资源临时迁移到新的URL）、307（Temporary Redirect，临时重定向，与302类似，但要求请求方法不变）。重定向时，服务器端会在响应头的“Location”字段中指定新的URL，浏览器会根据该URL重新发起请求。
• 4xx（客户端错误状态码）：表示客户端的请求存在错误，服务器端无法处理，如400（Bad Request，请求参数错误）、401（Unauthorized，未认证，需要用户登录）、403（Forbidden，禁止访问，用户没有权限）、404（Not Found，请求的资源不存在）。
• 5xx（服务器端错误状态码）：表示服务器端在处理请求时发生错误，如500（Internal Server Error，服务器内部错误）、502（Bad Gateway，网关错误）、503（Service Unavailable，服务器暂时不可用）、504（Gateway Timeout，网关超时）。

（2）响应头（Response Headers）

响应头用于向客户端（网络进程）传递服务器端的信息，如资源的类型、大小、缓存控制、服务器信息等，参考资料中提到的Content-Type是核心响应头，常见的响应头如下：

• Content-Type：指定响应体的类型和编码格式，是浏览器判断如何处理响应体的核心依据，参考资料中提到的“text/html → 渲染进程准备接收”“text/css image 下载”“doc mp3”等，都是根据Content-Type字段判断的。常见的Content-Type值：text/html（HTML页面）、text/css（CSS文件）、image/jpeg（JPG图片）、application/json（JSON数据）、application/pdf（PDF文件）等。
• Content-Length：指定响应体的大小（字节数），方便客户端判断数据是否接收完整。
• Location：用于重定向，指定新的URL，如301、302状态码对应的响应头中，会包含该字段，如“Location: time.geekbang.org”。
• Set-Cookie：用于服务器端向客户端设置Cookie，如“Set-Cookie: username=xxx; path=/; max-age=3600”，客户端会将该Cookie存储在本地，后续请求时通过Cookie请求头传递给服务器端。
• Cache-Control：用于控制客户端的缓存策略，如“Cache-Control: public, max-age=3600”，表示该资源可以被公开缓存，缓存有效期为3600秒。
• Server：标识服务器端的软件版本，如“Server: Nginx/1.21.0”。

（3）响应体（Response Body）

响应体是服务器端返回的核心资源，也是浏览器最终要渲染的内容，其格式由响应头中的Content-Type字段指定。例如，Content-Type为text/html时，响应体是HTML代码；Content-Type为image/jpeg时，响应体是图片的二进制数据；Content-Type为application/json时，响应体是JSON格式的数据。

参考资料中提到的“发送响应头，解析响应头数据，并将数据转发给浏览器进程”，就是指服务器端返回响应后，网络进程先解析响应头，根据Content-Type判断响应体的类型，然后将响应头和响应体一起转发给浏览器主进程。

5.2 补充知识点：HTTP协议的版本差异

当前主流的HTTP协议版本有HTTP/1.1和HTTP/2，二者在性能上有较大差异，面试中可能会追问，补充如下：

（1）HTTP/1.1：支持长连接（一次TCP连接可以发送多个HTTP请求）、管道化（多个请求可以同时发送，无需等待前一个请求响应），但存在“队头阻塞”问题——如果一个请求被阻塞，后续的请求都需要等待，影响传输效率。

（2）HTTP/2：采用二进制帧传输（将请求和响应拆分为二进制帧）、多路复用（多个请求可以在同一个TCP连接上并行传输，避免队头阻塞）、头部压缩（对请求头和响应头进行压缩，减少传输量）、服务器推送（服务器端可以主动向客户端推送资源，如HTML页面中需要的CSS、JS文件），大幅提升了传输效率。

环节6：浏览器主进程接收响应，协调渲染进程进行页面渲染

网络进程将解析后的HTTP响应（响应头+响应体）转发给浏览器主进程后，浏览器主进程开始协调渲染进程，准备进行页面渲染，这一环节是“URL输入到页面展示”的核心环节，涉及浏览器主进程与渲染进程的IPC通信，以及渲染进程的一系列解析、渲染操作，参考资料中对该环节的流程有详细描述，拆解如下：

6.1 浏览器主进程的处理逻辑

1. 接收响应数据：浏览器主进程接收网络进程转发的响应头和响应体，首先根据响应头中的Content-Type字段，判断响应体的类型。

2. 处理不同类型的资源：

   1. 若响应体是text/html类型（HTML页面）：浏览器主进程会启动渲染进程（如果渲染进程未启动），并通过IPC机制，将HTML数据转发给渲染进程，同时告知渲染进程“准备接收和解析页面数据”。
   2. 若响应体是text/css、image、doc、mp3等非HTML类型的资源：浏览器主进程会通知网络进程将资源下载到本地，存储在缓存中，供后续渲染进程使用（如CSS文件用于页面样式渲染，图片用于页面展示）。

3. 更新页面状态：浏览器主进程接收到渲染进程“确认提交”（已准备好接收和解析页面数据）的消息后，会移除之前旧的文档（如果是刷新页面或跳转页面），然后更新浏览器的页面状态——进入loading状态（显示loading图标），同时更新地址栏的URL，将当前URL加入浏览历史。

参考资料中提到：“用户发出URL请求，到页面开始解析的整个过程，就叫导航”，这里的“导航”就是指从URL输入到渲染进程开始解析HTML的整个流程，导航完成后，就进入页面渲染阶段。

6.2 渲染进程的页面渲染流程（核心重点）

渲染进程接收浏览器主进程转发的HTML数据后，开始进行页面渲染，整个渲染流程分为5个核心步骤，依次执行，最终将HTML、CSS、JS等资源转换为用户可见的页面，具体如下：

（1）解析HTML，生成DOM树（Document Object Model）

渲染进程中的HTML解析线程，会逐行解析HTML代码，将HTML标签（如、、、

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>BeforeUnload</title>
</head>
<body>
    <h1>试着关闭这个标签页，或者刷新页面</h1>
    <p>你应该会看到一个浏览器自带的弹窗问你是否确认离开当前页面</p>
    <script>
        // addEventListener 是 window 对象的方法，用于添加事件监听器
        // 第一个参数是事件类型，第二个参数是事件处理函数
        window.addEventListener('beforeunload',function(event){
            console.log('beforeunload 事件已经触发');
            event.preventDefault(); // 阻止默认行为（部分浏览器需要）
            event.returnValue = ''; // 兼容各浏览器，触发默认弹窗提示
        });

        // 补充pagehide事件监听，演示页面隐藏/卸载时的触发逻辑
        window.addEventListener('pagehide', function(event) {
            console.log('pagehide 事件已经触发');
            // 判断页面是否进入bfcache（前进/后退缓存）
            if (event.persisted) {
                console.log('页面已进入bfcache，下次前进/后退无需重新请求');
            } else {
                console.log('页面正常卸载，未进入bfcache');
            }
        });
    </script>
</body>
</html>