普通视图

发现新文章,点击刷新页面。
昨天 — 2026年2月26日首页

浏览器扩展 E2E 测试的救星:vitest-environment-web-ext 让你告别繁琐配置

作者 FliPPeDround
2026年2月26日 15:34

FliPPeDround

前端工程师 · 开源爱好者 · 正在找工作

对我的项目感兴趣?查看我的简历 · resume

如果你曾尝试为浏览器扩展编写 E2E 测试,你大概率会遇到这样的困境:测试环境配置复杂、Playwright 与扩展的集成困难、缺乏统一的测试框架支持。更糟糕的是,当你想要使用 Vitest 这种更现代、更快速的测试框架时,却发现没有合适的浏览器扩展环境支持。

为了解决这些痛点,vitest-environment-web-ext 应运而生。作为一款轻量级的 Vitest 自定义环境,它让浏览器扩展项目的 E2E 测试变得前所未有的简单和高效。

📖 介绍

📚 官方文档:更多详细的安装和配置说明,请参考 CRXJS 官方文档

vitest-environment-web-ext 是一个专门为 Vitest 设计的浏览器扩展 E2E 测试环境。它深度集成了 Playwright 的强大能力,让你能够在 Vitest 框架下无缝运行浏览器扩展的自动化测试。

这个工具的出现,填补了浏览器扩展现代化测试工具链的空白。它不仅保持了与 Playwright 的完全兼容性,还充分发挥了 Vitest 的性能优势,为开发者提供了一个更快速、更现代化的测试解决方案。

🚀 核心功能与技术优势

1. 无缝集成 Vitest 生态

vitest-environment-web-ext 完全兼容 Vitest 的配置系统,你可以像使用其他 Vitest 环境一样简单配置:

import { defineConfig } from 'vitest/config'

export default defineConfig({
  test: {
    environment: 'web-ext',
  },
})

2. 全面的扩展页面支持

工具提供了丰富的 API 来访问浏览器扩展的各个部分:

  • Popup 页面测试:通过 getPopupPage() 获取扩展的弹窗页面
  • Side Panel 测试:通过 getSidePanelPage() 获取侧边栏页面
  • Content Script 测试:通过 context.newPage() 创建新页面并测试注入的内容脚本
  • Service Worker 测试:通过 getServiceWorker() 获取扩展的后台服务工作线程

3. 智能环境管理

工具内部实现了智能的环境初始化和清理机制:

  • 自动管理浏览器上下文的生命周期
  • 支持自动编译扩展项目
  • 内置扩展 ID 自动获取机制
  • 完善的错误处理和资源清理

4. TypeScript 完整支持

提供了完整的 TypeScript 类型定义,让开发者在编写测试代码时享受完整的类型提示和智能补全:

{
  "compilerOptions": {
    "types": [
      "vitest-environment-web-ext/types"
    ]
  }
}

5. 灵活的配置选项

支持丰富的配置选项,满足不同测试场景的需求:

  • 自动启动浏览器
  • 自定义编译命令
  • Playwright 参数配置(如 devtools、slowMo 等)
  • 用户数据目录管理

🧪 为什么 E2E 测试如此重要

在软件开发中,单元测试固然重要,但 E2E(End-to-End)测试在构建高质量代码过程中扮演着不可替代的角色。

提升代码可靠性

E2E 测试模拟真实用户的使用场景,从用户界面到后端服务的完整流程进行验证。与单元测试不同,E2E 测试能够发现:

  • 组件间的集成问题
  • 浏览器扩展与网页内容的交互异常
  • 消息传递机制的错误
  • 权限配置问题

对于浏览器扩展这种运行在特殊环境中的应用,E2E 测试尤为重要。它能够确保你的扩展在不同浏览器、不同网页环境下都能正常运行,避免出现"在开发环境正常,上线后出问题"的尴尬情况。

降低维护成本

虽然编写 E2E 测试需要投入一定的时间成本,但从长远来看,它能显著降低维护成本:

  • 减少回归测试时间:自动化测试可以在几分钟内完成原本需要数小时的手动测试
  • 快速定位问题:当出现 bug 时,E2E 测试能够快速定位问题所在
  • 增强重构信心:有了完善的测试覆盖,你可以放心地进行代码重构,而不必担心破坏现有功能
  • 文档化业务逻辑:测试代码本身就是最好的业务逻辑文档

提升团队协作效率

E2E 测试作为项目质量的"守门员",能够:

  • 统一团队对功能实现的理解
  • 减少 code review 时的争议
  • 让新成员快速理解项目功能
  • 建立持续集成的质量保障体系

📦 快速上手

安装依赖

首先,安装必要的依赖:

pnpm add -D vitest-environment-web-ext playwright

⚠️ 注意:playwright 是必需的依赖,必须安装

配置 Vitest

在项目根目录创建或修改 vitest.config.ts

import { defineConfig } from 'vitest/config'

export default defineConfig({
  test: {
    environment: 'web-ext',
  },
})

配置 TypeScript

tsconfig.json 中添加类型定义:

{
  "compilerOptions": {
    "types": [
      "vitest-environment-web-ext/types"
    ]
  }
}

添加测试脚本

package.json 中添加测试命令:

{
  "scripts": {
    "test": "vitest"
  }
}

编写测试用例

创建测试文件,例如 extension.test.ts

import { describe, expect, it } from 'vitest'

describe('浏览器扩展测试', () => {
  it('测试 Popup 页面', async () => {
    const popupPage = await browser.getPopupPage()
    const text = await popupPage.waitForSelector('.welcome-text')
    expect(await text.textContent()).toBe('欢迎使用扩展')
  })

  it('测试 Side Panel 页面', async () => {
    const sidePanelPage = await browser.getSidePanelPage()
    const title = await sidePanelPage.title()
    expect(title).toContain('侧边栏')
  })

  it('测试 Content Script 注入', async () => {
    const page = await context.newPage()
    await page.goto('https://www.example.com')
    const toggleButton = await page.waitForSelector('.toggle-button')
    await toggleButton.click()
    const appContainer = await page.waitForSelector('.app-content')
    expect(await appContainer.textContent()).toBeTruthy()
  })
})

运行测试

执行测试命令:

pnpm test

🎯 高级配置选项详解

除了基础配置,vitest-environment-web-ext 还支持更多高级选项:

import { defineConfig } from 'vitest/config'

export default defineConfig({
  test: {
    environment: 'web-ext',
    environmentOptions: {
      'web-ext': {
        path: './dist',
        compiler: 'npm run build',
        autoLaunch: true,
        targetUrl: 'https://www.example.com',
        playwright: {
          userDataDir: './.playwright',
          devtools: true,
          slowMo: 100,
        },
      },
    },
  },
})

配置参数说明

  • path: 扩展构建目录路径
  • compiler: 测试前自动编译的命令
  • autoLaunch: 是否自动启动浏览器(默认:true)
  • targetUrl: 用于获取扩展 ID 的目标页面
  • playwright.userDataDir: Playwright 用户数据目录
  • playwright.devtools: 是否自动打开开发者工具
  • playwright.slowMo: 操作延迟时间(毫秒)

🔧 技术实现细节

vitest-environment-web-ext 的实现基于 Vitest 的自定义环境 API,核心类 WebExtEnvironment 实现了以下功能:

  1. 环境初始化:在 setup 方法中初始化浏览器扩展环境
  2. 全局对象注入:将 browsercontext 注入到全局作用域
  3. 资源清理:在 teardown 方法中正确清理浏览器资源
  4. 扩展页面管理:通过 WebExtLoaderWebExtFactory 等类实现扩展页面的智能管理

工具内部还实现了智能的状态管理,避免重复初始化,确保测试环境的稳定性。

🌟 总结

vitest-environment-web-ext 为浏览器扩展开发者提供了一个现代化、高效的 E2E 测试解决方案。它不仅解决了传统测试工具配置复杂的问题,还充分发挥了 Vitest 和 Playwright 的性能优势。

通过完善的 E2E 测试,你可以:

  • 提升代码质量和可靠性
  • 降低长期维护成本
  • 增强团队协作效率
  • 建立持续集成的质量保障体系

如果你正在开发浏览器扩展项目,并且想要建立完善的测试体系,vitest-environment-web-ext 绝对值得一试。它会让你的测试工作变得前所未有的简单和高效。

📚 相关资源


最后

vitest-environment-web-ext 是一个免费的开源软件,遵循MIT协议,社区的赞助使其能够有更好的发展。

你的赞助会帮助我更好的维护@crxjs,如果对你有帮助,请考虑赞助一下😊

你的star🌟也是对我的很大鼓励,Github

欢迎反馈问题和提pr共建

昨天以前首页

从输入URL到页面显示的完整技术流程

作者 Wect
2026年2月22日 13:53

一、引言

在Web应用场景中,用户输入统一资源定位符(URL)到页面最终渲染显示,是一个涉及浏览器、网络协议、服务器交互的复杂技术链路。该链路涵盖URL解析、DNS域名解析、TCP/TLS连接建立、HTTP请求响应、浏览器渲染等多个核心环节,各环节紧密衔接、协同工作,直接决定了页面加载速度与交互体验。本文将从技术原理出发,系统拆解整个流程的核心机制,梳理各环节的关键技术要点,为相关技术研究、开发实践及面试备考提供严谨、客观的参考依据。

二、主体分析:从URL到页面显示的完整流程

(一)URL解析:资源定位的前置准备

URL作为Web资源的唯一标识,浏览器接收用户输入的字符串后,首先需完成URL的解析与补全,确保能够准确定位目标服务器及对应资源。该过程的核心是校验URL合法性,并拆解其核心组成部分。

浏览器会对输入字符串进行格式校验,判断其是否符合URL标准规范。若输入字符串不完整(如仅输入“www.example.com”),浏览器将自动补全协议、默认端口等必要字段,补全后为“www.example.com/”;其中,HTTPS协…

一个完整的URL结构可拆解为六个核心部分,以“www.example.com:443/path?query=…

  • 协议(scheme):即https,用于定义浏览器与服务器之间的通信规则,常用协议还包括HTTP、FTP等;

  • 域名(host):即www.example.com,作为服务器的别名,用于简化用户记忆,需通过DNS解析转换为网络可识别的IP地址;

  • 端口(port):即443,用于区分服务器上的不同服务,默认端口可省略;

  • 路径(path):即/path,用于指定服务器上具体资源的存储位置,如“/index.html”对应服务器根目录下的首页文件;

  • 查询参数(query):即?query=1,用于向服务器传递额外请求参数,多个参数以“&”分隔;

  • 锚点(hash):即#hash,用于定位页面内的具体位置,仅在浏览器本地生效,不会随HTTP请求发送至服务器。

(二)DNS查询:域名与IP的映射转换

网络通信的本质是IP地址之间的交互,服务器与客户端仅能通过IP地址识别彼此。由于IP地址具有复杂性、难记忆的特点,DNS(域名系统)应运而生,其核心功能是实现域名到IP地址的映射转换,相当于网络世界的“通讯录”。

DNS查询遵循“从近到远、从本地到远程”的顺序,优先查询本地缓存以提升查询效率,缓存未命中时再发起远程查询,完整流程如下:

  1. 浏览器DNS缓存:浏览器会缓存近期查询过的域名-IP映射关系,缓存有效期较短(通常为几分钟至几小时),查询时优先匹配,命中则直接获取IP地址;

  2. 操作系统DNS缓存:若浏览器缓存未命中,将查询操作系统自带的DNS缓存,如Windows系统的hosts缓存、Mac系统的DNS缓存;

  3. 本地hosts文件:操作系统缓存未命中时,读取本地hosts文件,该文件可手动配置域名与IP的映射关系,常用于开发测试场景(如配置“127.0.0.1 localhost”);

  4. 本地DNS服务器:以上缓存均未命中时,向本地DNS服务器(通常由网络运营商提供,如电信、联通DNS服务器)发送查询请求,运营商服务器会缓存常用域名的解析结果;

  5. 递归与迭代查询:若本地DNS服务器未缓存目标域名解析结果,将通过“递归+迭代”的方式逐层查询,依次向根域名服务器、顶级域名服务器(如.com、.cn服务器)、目标域名服务器发起请求,最终获取目标IP地址,并返回给浏览器同时进行缓存。

DNS查询的核心机制可分为递归查询与迭代查询:客户端与本地DNS服务器之间采用递归查询,即客户端仅需等待最终解析结果,由本地DNS服务器完成全程查询操作;DNS服务器之间采用迭代查询,即各服务器仅告知后续查询的目标服务器地址,不负责全程查询,直至获取最终IP地址。

(三)TCP/TLS握手:可靠安全连接的建立

获取目标服务器IP地址后,浏览器需与服务器建立通信连接,其中HTTP协议基于TCP协议实现可靠数据传输,HTTPS协议则在TCP协议之上增加TLS协议,实现数据加密与身份校验,保障通信安全。

1. TCP三次握手:可靠连接的建立

TCP(传输控制协议)的核心特性是可靠传输,三次握手是建立TCP连接的必要流程,其目的是确认双方的发送能力与接收能力均正常,避免历史延迟请求引发的错误连接,保障连接可靠性。三次握手流程如下:

  1. 客户端向服务器发送SYN报文,发起连接请求,告知服务器客户端准备建立连接;

  2. 服务器接收SYN报文后,返回SYN+ACK报文,确认接收客户端请求,同时向客户端发起连接请求;

  3. 客户端接收SYN+ACK报文后,返回ACK报文,确认接收服务器请求,完成三次握手。

三次握手的合理性可通过对比分析验证:若仅采用两次握手,服务器发送SYN+ACK报文后即确认连接建立,但无法确认客户端是否能接收自身报文,若客户端ACK报文丢失,服务器将持续等待,造成资源浪费;若采用四次握手,将在三次握手基础上增加额外确认步骤,不会提升连接可靠性,反而会增加通信延迟,降低传输效率。

2. TLS握手:安全通信的保障

HTTPS协议是HTTP协议与TLS(传输层安全协议)的结合,相比HTTP协议的明文传输,HTTPS通过TLS握手实现身份校验与数据加密,避免数据被窃取、篡改。TLS握手的核心操作如下:

  1. 加密算法协商:客户端与服务器协商一致,确定双方均支持的加密算法(如AES对称加密、RSA非对称加密),确保后续数据加密与解密可正常执行;

  2. 服务器证书校验:服务器向客户端发送由权威CA机构颁发的SSL证书,客户端校验证书的合法性(包括证书有效期、是否被篡改等),确认服务器身份的真实性,避免中间人劫持;

  3. 对称密钥生成:证书校验通过后,客户端与服务器协商生成对称密钥,后续所有HTTP请求与响应数据均通过该密钥加密/解密,兼顾安全性与传输效率;

  4. 握手完成确认:双方确认TLS握手完成,后续通信数据将采用协商好的对称密钥进行加密传输,保障通信安全。

与HTTP协议相比,HTTPS协议的核心差异的是增加了TLS握手环节,通过身份校验与数据加密,解决了HTTP协议明文传输的安全隐患。

(四)HTTP请求与响应:资源的传输交互

TCP(或TLS+TCP)连接建立完成后,浏览器向服务器发起HTTP请求,服务器接收请求并处理后,返回HTTP响应,完成Web资源的传输交互,这是整个链路中资源传递的核心环节。

1. HTTP请求报文

HTTP请求报文由请求行、请求头、空行、请求体四部分组成,简化示例如下:

GET /index.html HTTP/1.1  # 请求行:请求方法 + 资源路径 + HTTP版本
Host: www.example.com     # 请求头:传递额外请求信息
Cookie: username=test
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/120.0.0.0
                          # 空行:分隔请求头与请求体
# 请求体:GET请求通常为空,POST请求用于传递表单等参数

常用HTTP请求方法包括:GET(用于获取Web资源,如打开页面)、POST(用于提交数据,如登录、表单提交)、PUT(用于修改资源)、DELETE(用于删除资源),不同请求方法对应不同的服务器处理逻辑。

2. HTTP响应报文

HTTP响应报文与请求报文对应,由响应行、响应头、空行、响应体四部分组成,简化示例如下:

HTTP/1.1 200 OK          # 响应行:HTTP版本 + 状态码 + 状态描述
Content-Type: text/html  # 响应头:传递资源相关信息
Content-Length: 1024
Cache-Control: max-age=3600

<html><head><title>示例页面</title></head><body>...</body></html>  # 响应体:核心Web资源

3. 常见HTTP状态码

HTTP状态码用于告知浏览器请求处理结果,分为5大类,核心常用状态码如下:

  • 200 OK:请求处理成功,服务器正常返回目标资源,是最常见的状态码;

  • 301 永久重定向:请求的资源已永久迁移至新地址,浏览器将自动跳转至新地址;

  • 302 临时重定向:请求的资源临时迁移至新地址,跳转行为仅在本次请求有效;

  • 304 Not Modified:目标资源未发生修改,浏览器可直接使用本地缓存,提升加载速度;

  • 404 Not Found:请求的资源不存在,通常由URL输入错误、资源被删除导致;

  • 500 Internal Server Error:服务器内部出现错误(如代码报错、服务器宕机),与客户端请求无关。

(五)浏览器解析:渲染前置的结构构建

浏览器接收服务器返回的HTTP响应后,若响应体为HTML资源,不会直接渲染显示,需先完成HTML、CSS、JS的解析,构建DOM树、CSSOM树及渲染树(Render Tree),为后续页面渲染提供基础结构,这是页面渲染的前置环节。

1. HTML解析与DOM树构建

浏览器对HTML的解析遵循自上而下、逐行解析的原则,将HTML文档中的标签、文本、属性等,转换为浏览器可识别的文档对象模型树(DOM Tree)。DOM Tree的根节点为标签,各子节点对应HTML中的各类元素,层级结构与HTML文档保持一致。

该解析过程的核心特点是:遇到未添加defer/async属性的<script>标签时,会阻塞HTML解析。原因在于JavaScript代码可能对DOM进行操作(如修改、删除DOM节点),浏览器需先执行完JavaScript代码,再继续解析后续HTML内容,避免解析结果与JS操作冲突。

2. CSS解析与CSSOM树构建

CSS解析与HTML解析可并行执行,不依赖HTML解析顺序,但会阻塞页面渲染。浏览器将页面中所有CSS样式(内联样式、内部样式、外部样式)解析后,构建CSS对象模型树(CSSOM Tree),该树明确了每个DOM节点对应的样式规则(如字体、颜色、尺寸等)。

若JavaScript代码中存在获取元素样式的操作(如getComputedStyle()),浏览器将先完成CSS解析与CSSOM树构建,再执行对应的JavaScript代码,确保JS获取的样式信息准确无误。

3. 渲染树(Render Tree)构建

DOM树与CSSOM树构建完成后,浏览器将两者合并,生成渲染树(Render Tree)。渲染树的核心特点是仅包含页面可见节点,不可见节点(如display: none属性的元素)不会被纳入渲染树,避免无效渲染;而visibility: hidden属性的元素,虽视觉上隐藏但仍占据页面布局空间,会被纳入渲染树。渲染树是后续页面布局、绘制的核心依据。

(六)页面渲染:视觉呈现的核心流程

渲染树构建完成后,浏览器通过布局(Layout)、绘制(Paint)、合成(Composite)三个依次执行的核心步骤,将Web资源渲染显示在屏幕上,形成用户最终看到的页面,该流程直接决定页面的视觉呈现效果与加载效率。

1. 布局(Layout):元素位置与尺寸的计算

布局又称回流或重排,其核心作用是根据渲染树,计算每个可见元素的位置与尺寸,包括元素的宽度、高度、left/top坐标等,明确每个元素在页面中的具体布局位置。

触发布局的常见场景包括:元素尺寸或位置修改(如修改width、height、margin属性)、页面窗口大小调整、DOM节点的添加或删除等,布局操作会触发后续绘制与合成步骤,对页面加载效率有一定影响。

2. 绘制(Paint):元素视觉样式的绘制

绘制又称重绘,其核心作用是根据布局计算的结果,在浏览器的绘制层上,为每个元素绘制视觉样式,包括颜色、边框、背景、文字、图片等,将元素的视觉属性呈现出来。

触发绘制的常见场景包括:元素视觉样式修改(如修改color、background-color、border-color属性),但元素尺寸与位置未发生变化,此时仅触发绘制与合成步骤,无需重新执行布局,效率高于布局操作。

3. 合成(Composite):分层渲染与屏幕显示

合成又称分层合成,其核心作用是将绘制完成的多个绘制层,通过GPU(图形处理器)进行分层合成,将所有绘制层整合为一个完整的页面,最终渲染显示在屏幕上。

GPU分层合成的优势在于效率高,不同绘制层相互独立,修改某一层的元素时,无需重新绘制整个页面,仅需重新合成该层即可,可显著提升页面交互的流畅度。例如,修改元素的transform属性(GPU加速属性)时,仅触发合成步骤,无需执行布局与绘制,效率最优。

(七)完整流程汇总

从输入URL到页面显示的完整技术流程可总结为:用户输入URL后,浏览器先完成URL解析与补全,明确通信协议、域名、端口等核心信息;通过DNS解析系统,将域名转换为对应的IP地址;与服务器建立TCP连接,HTTPS协议额外执行TLS握手确保通信安全;连接建立后,浏览器发送HTTP请求,服务器处理后返回HTTP响应;浏览器解析HTML构建DOM树、解析CSS构建CSSOM树,合并生成渲染树;最后通过布局、绘制、合成三个步骤,将页面渲染显示在屏幕上,完成整个流程。

(八)追问常见

1. DNS 是递归还是迭代?

DNS查询的核心机制分为递归查询与迭代查询,二者应用场景不同、职责明确:客户端与本地DNS服务器之间采用递归查询,即客户端无需参与中间查询过程,仅需等待本地DNS服务器返回最终的IP解析结果,全程由本地DNS服务器完成逐层查询操作;DNS服务器之间(包括本地DNS服务器与根域名服务器、顶级域名服务器、目标域名服务器之间)采用迭代查询,即各服务器仅向发起查询的服务器告知后续查询的目标服务器地址,不负责全程查询,直至某一服务器返回最终IP地址,查询流程终止。

2. HTTPS 比 HTTP 多了哪一步?

与HTTP协议相比,HTTPS协议的核心差异是增加了TLS(传输层安全协议)握手环节。HTTP协议基于TCP协议进行明文传输,数据易被窃取、篡改,无身份校验机制;而HTTPS协议在TCP三次握手建立连接后,会额外执行TLS握手流程,完成加密算法协商、服务器证书校验、对称密钥生成等操作,实现通信数据的加密传输与服务器身份的真实性校验,从而解决HTTP协议明文传输的安全隐患,保障网络通信的安全性。

3. TCP 三次握手为什么是三次?

TCP三次握手的核心目的是确认通信双方的发送能力与接收能力均正常,同时避免历史延迟请求引发的错误连接,保障TCP连接的可靠性,其次数设定具有明确的合理性,既不能减少为两次,也无需增加至四次。若仅采用两次握手,服务器发送SYN+ACK报文后即确认连接建立,但无法确认客户端是否能接收自身发送的报文,若客户端的ACK报文丢失,服务器会持续等待连接,造成服务器资源浪费;若采用四次握手,会在三次握手的基础上增加额外的确认步骤,该步骤无法提升连接的可靠性,反而会增加网络通信延迟,降低数据传输效率,因此三次握手是兼顾可靠性与效率的最优选择。

三、结论

从输入URL到页面显示的过程,是浏览器、网络协议与服务器协同工作的集中体现,涵盖URL解析、DNS查询、TCP/TLS连接、HTTP请求响应、浏览器解析与渲染六大核心环节,各环节环环相扣、缺一不可。其中,URL解析与DNS查询为资源定位提供基础,TCP/TLS连接保障通信的可靠与安全,HTTP请求响应实现资源传输,浏览器解析与渲染完成页面视觉呈现。

深入理解该技术流程,不仅能够帮助开发者优化页面加载速度、提升用户体验,解决开发中的各类网络与渲染相关问题,同时也是计算机网络、前端开发等领域面试的核心考点。

从输入 URL 到页面展示的完整链路解析

作者 NEXT06
2026年2月22日 11:43

“从输入 URL 到页面展示,这中间发生了什么?”

这是一道计算机网络与浏览器原理的经典面试题。它看似基础,实则深不见底。对于初级开发者,可能只需要回答“DNS 解析、建立连接、下载文件、渲染页面”即可;但对于高级工程师而言,这道题考察的是对网络协议栈、浏览器多进程架构、渲染流水线以及性能优化的系统性理解。

本文将剥离表象,深入底层,以专业的视角还原这一过程的全貌。

一、 URL 解析与 DNS 查询

1. URL 结构拆解

URL(Uniform Resource Locator),统一资源定位符。浏览器首先会对用户输入的字符串进行解析。如果不符合 URL 规则,浏览器会将其视为搜索关键字传给默认搜索引擎;如果符合规则,则拆解为以下部分:

scheme://host.domain:port/path/filename?query#fragment

  • Scheme: 协议类型(HTTP/HTTPS/FTP 等)。
  • Host/Domain: 域名(如 juejin.cn)。
  • Port: 端口号(HTTP 默认为 80,HTTPS 默认为 443)。
  • Path: 资源路径。
  • Query: 查询参数。
  • Fragment: 锚点(注意:锚点不会被发送到服务器)。

2. DNS 解析流程

网络通讯是基于 TCP/IP 协议的,是通过 IP 地址而非域名进行定位。因此,浏览器的第一步是获取目标服务器的 IP 地址。

DNS 查询遵循级联缓存策略,查找顺序如下:

  1. 浏览器缓存: 浏览器会检查自身维护的 DNS 缓存。
  2. 系统缓存: 检查操作系统的 hosts 文件。
  3. 路由器缓存: 检查路由器的 DNS 记录。
  4. ISP DNS 缓存: 也就是本地 DNS 服务器(Local DNS),通常由网络服务提供商提供。

如果上述缓存均未命中,则发起递归查询迭代查询

  1. 递归查询: 客户端向本地 DNS 服务器发起请求,如果本地 DNS 不知道,它会作为代理去替客户端查询。
  2. 迭代查询: 本地 DNS 服务器依次向根域名服务器顶级域名服务器权威域名服务器发起请求,最终获取 IP 地址并返回给客户端。

进阶优化:

  • DNS Prefetch: 现代前端通过  提前解析域名,减少后续请求的延迟。
  • CDN 负载均衡: 在 DNS 解析阶段,智能 DNS 会根据用户的地理位置,返回距离用户最近的 CDN 节点 IP,而非源站 IP,从而实现内容分发加速。

二、 TCP 连接与 HTTP 请求

拿到 IP 地址后,浏览器与服务器建立连接。这是数据传输的基础。

1. TCP 三次握手

TCP(Transmission Control Protocol)提供可靠的传输服务。建立连接需要经过三次握手,确认双方的收发能力。

  • 第一次握手(SYN) : 客户端发送 SYN=1, Seq=x。客户端进入 SYN_SEND 状态。此时证明客户端有发送能力。
  • 第二次握手(SYN+ACK) : 服务端接收报文,回复 SYN=1, ACK=1, seq=y, ack=x+1。服务端进入 SYN_RCVD 状态。此时证明服务端有接收和发送能力。
  • 第三次握手(ACK) : 客户端接收报文,回复 ACK=1, seq=x+1, ack=y+1。双方进入 ESTABLISHED 状态。此时证明客户端有接收能力。

核心问题:为什么是三次而不是两次?
主要是为了防止已失效的连接请求报文段又传送到了服务端,产生错误。如果只有两次握手,服务端收到失效的 SYN 包后误以为建立了新连接,会一直等待客户端发送数据,造成资源浪费。

2. TLS/SSL 握手(HTTPS)

如果是 HTTPS 协议,在 TCP 建立后,还需要进行 TLS 四次握手以协商加密密钥(Session Key)。过程包括交换支持的加密套件、验证服务器证书、通过非对称加密交换随机数等,最终生成对称加密密钥用于后续通信。

3. 发送 HTTP 请求

连接建立完毕,浏览器构建 HTTP 请求报文并发送。

  • 请求行: 方法(GET/POST)、URL、协议版本。
  • 请求头: User-Agent、Accept、Cookie 等。
  • 请求体: POST 请求携带的数据。

服务器处理请求后,返回 HTTP 响应报文(状态行、响应头、响应体)。浏览器拿到响应体(通常是 HTML 文件),准备开始渲染。

三、 浏览器解析与渲染(核心重点)

这是前端工程师最需要关注的环节。现代浏览器采用多进程架构,主要包括Browser 进程(主控)、网络进程渲染进程

当网络进程下载完 HTML 数据后,会通过 IPC 通信将数据交给渲染进程(Renderer Process)。渲染主流程如下:

1. 解析 HTML 构建 DOM 树

浏览器无法直接理解 HTML 字符串,需要将其转化为对象模型(DOM)。
流程:Bytes(字节流) -> Characters(字符) -> Tokens(词法分析) -> Nodes(节点) -> DOM Tree

注意:遇到 

2. 解析 CSS 构建 CSSOM 树

浏览器下载 CSS 文件(.css)并解析为 CSSOM(CSS Object Model)。
关键点

  • CSS 下载不阻塞 DOM 树的解析。
  • CSS 下载阻塞 Render Tree 的构建(因此会阻塞页面渲染)。

3. 生成渲染树(Render Tree)

DOM 树与 CSSOM 树结合,生成 Render Tree。

  • 浏览器遍历 DOM 树的根节点,在 CSSOM 中找到对应的样式。
  • 忽略不可见节点:display: none 的节点不会出现在 Render Tree 中(但 visibility: hidden 的节点会存在,因为它占据空间)。
  • 去除元数据:head、script 等非视觉节点会被去除。

4. 布局(Layout / Reflow)

有了 Render Tree,浏览器已经知道有哪些节点以及样式,但还不知道它们的几何信息(位置、大小)。
布局阶段会从根节点递归计算每个元素在视口中的确切坐标和尺寸。这个过程在技术上被称为 Reflow(回流)

5. 绘制(Paint)

布局确定后,浏览器会生成绘制指令列表(如“在 x,y 处画一个红色矩形”)。这个过程并不直接显示在屏幕上,而是生成图层(Layer)的绘制记录。

6. 合成(Composite)与显示

这是现代浏览器渲染优化的核心。

  • 分层:浏览器会将页面分为不同的图层(Layer)。拥有 transform (3D)、will-change、position: fixed 等属性的元素会被提升为单独的合成层。
  • 光栅化(Raster) :合成线程将图层切分为图块(Tile),并发送给 GPU 进行光栅化(生成位图)。
  • 显示:一旦所有图块都被光栅化,浏览器会生成一个 DrawQuad 命令提交给 GPU 进程,最终将像素显示在屏幕上。

脚本阻塞与优化
为了避免 JS 阻塞 DOM 构建,可以使用 defer 和 async:

  • defer: 异步下载,文档解析完成后、DOMContentLoaded 事件前按照顺序执行。
  • async: 异步下载,下载完成后立即执行(可能打断 HTML 解析),执行顺序不固定。

四、 连接断开

当页面资源加载完毕,且不再需要通信时,通过 TCP 四次挥手 断开连接。

  1. 第一次挥手(FIN) : 主动方发送 FIN,进入 FIN_WAIT_1。
  2. 第二次挥手(ACK) : 被动方发送 ACK,进入 CLOSE_WAIT。主动方进入 FIN_WAIT_2。此时连接处于半关闭状态。
  3. 第三次挥手(FIN) : 被动方数据发送完毕,发送 FIN,进入 LAST_ACK。
  4. 第四次挥手(ACK) : 主动方发送 ACK,进入 TIME_WAIT。等待 2MSL(报文最大生存时间)后释放连接。

为什么需要 TIME_WAIT?  确保被动方收到了最后的 ACK。如果 ACK 丢失,被动方重传 FIN,主动方还能在 2MSL 内响应。

五、 面试高分指南(场景模拟)

场景:面试官问:“请详细描述从输入 URL 到页面展示发生了什么?”

回答策略范本

1. 总述(宏观骨架)
“这个过程主要分为两个阶段:网络通信阶段页面渲染阶段。网络阶段负责将 URL 转换为 IP 并获取资源,渲染阶段负责将 HTML 代码转化为像素点。”

2. 网络通信阶段(突出细节)

  • “首先是 DNS 解析。浏览器会依次查询浏览器缓存、系统 hosts、路由器缓存,最后发起递归或迭代查询拿到 IP。这里可以提到 CDN 是如何通过 DNS 实现就近访问的。”
  • “拿到 IP 后进行 TCP 三次握手 建立连接。如果是 HTTPS,还涉及 TLS 握手协商密钥。”
  • “连接建立后发送 HTTP 请求。需要注意 HTTP/1.1 的 Keep-Alive 可以复用 TCP 连接,而 HTTP/2 更是通过多路复用解决了队头阻塞问题。”

3. 页面渲染阶段(展示深度)

  • “浏览器解析 HTML 构建 DOM 树,解析 CSS 构建 CSSOM 树,两者合并生成 Render Tree。”
  • “接着进行 Layout(回流)  计算位置大小,然后进行 Paint(重绘)  生成绘制指令。”
  • “这里有一个关键点是 Composite(合成) 。现代浏览器会利用 GPU 加速,将 transform 或 opacity 的元素提升为独立图层。修改这些属性不会触发 Reflow 和 Repaint,只会触发 Composite,这是性能优化的核心。”

4. 脚本执行(补充)

  • “在解析过程中,遇到 JS 会阻塞 DOM 构建。为了优化首屏,我们通常使用 defer 属性让脚本异步加载并在 HTML 解析完成后执行。”

总结
“整个流程结束于 TCP 四次挥手断开连接。这就构成了一个完整的浏览闭环。”

❌
❌