👋 手搓 gzip 实现的文件分块压缩上传

👋 手搓 GZIP 实现的文件分块压缩上传

1 前言

已经半年多的时间没有闲下来写文章了。一方面是重新迷上了玩游戏，另一方面是 AI 时代的到来，让我对普通技术类文章的阅读频率减少了很多，相应的，自己动笔的动力也减缓了不少。

但经过这段时间的摸索，有一点是可以确定的：具有一定技术深度、带有强烈个人风格或独特创意的文章，在 AI 时代仍具有不可替代的价值。

所以，本篇来了。

在上一篇文章中，我们实现了在浏览器中记录结构化日志，现在，我们需要将这部分日志上传到云端，方便工程师调试。

我们面临的首要问题就是，文件太大了，必须分片上传。

我们将从零构建一套大文件上传系统。和普通的大文件上传系统（如阿里 OSS、七牛云常见的方案）相似，我们具备分片上传、断点续传的基础能力。但不同的是，我们为此引入了两个高阶特性：

AWS S3 预签名直传（Presigned URL） ：降低服务端带宽压力。
独立分片 Gzip 压缩：在客户端对分片进行独立压缩，但最终在服务端合并成一个合法的 Gzip 文件。

阅读本篇，你将收获：

Gzip (RFC 1952) 与 Deflate (RFC 1951) 协议的底层实现原理。
基于 AWS S3 实现大文件分片直传的完整架构。
一个生产级前端上传 SDK 的设计思路。

2 基础方案设计

在正式开始设计之前，我们需要先了解以下知识：AWS 提供服务端的大文件上传或下载能力，但不直接提供直传场景（presign url）的大文件分片上传能力。

基于 AWS 实现的常规流程的大文件上传 flow 为：

后端先启用 CreateMultipartUpload，得到 uploadId，返回前端
- 在启用时，需遵循以下规则：
  - ✅ 分段上传的最大文件大小为 5TB
  - ⚠️ 最大分段数为 10000
  - ⚠️ 分段大小单次限制为 5MB-5GB，最后一段无限制
- 需提前定义 x-amz-acl
- 需提前定义使用的校验和算法 x-amz-checksum-algorithm
- 需提前定义校验和类型 x-amz-checksum-type
在上传时，可以通过 presign url 上传
- 每一段都必须在 header 中包含 uploadId
- 每一段都建议计算校验和，并携带到 header 中（声明时如定义了 **x-amz-checksum-algorithm 则必传）**
- 每一段上传时，都必须携带分段的序号 partNumber
- 上传后，返回每一段的 ETag 和 PartNumber，如果使用了校验和算法，则也返回；该返回数据需要记录下来
上传完成后，调用 CompleteMultipartUpload
- 必须包含参数 part，使用类似于：
- ⚠️ 除了最后一段外，单次最小 5MB，否则 complete 阶段会报错

好在这并不意味着我们要在「直传」和「分片上传」中间二选一。

来看到我们的架构图，我们在 BFF 总共只需要三个接口，分别负责「创建上传任务」「获取分片上传 URL」「完成分片上传」的任务，而实际上传时，调用预授权的 AWS URL。

更细节的部分，可以参考这份时序图。

2.1 关键接口

📤 创建上传任务

接口地址 ：POST /createSliceUpload
功能：
- 检查文件是否已存在
- 检查是否存在未完成的上传任务
- 创建新的分片上传任务

返回示例：

✅ 文件已存在：

js 复制代码

{
  "id": "xxx",
  "fileName": "example.txt",
  "url": "https://..."
}

🔄 任务进行中：

js 复制代码

{
  "id": "xxx",
  "fileName": "example.txt",
  "uploadId": "abc123",
  "uploadedParts": [1, 2, 3]
}

🆕 新建任务：

js 复制代码

{
  "id": "xxx",
  "fileName": "example.txt",
  "uploadId": "abc123",
  "uploadedParts": []
}

🔗 获取分片上传 URL

接口地址 ：POST /getSlicePresignedUrl
功能：获取指定分片的预签名上传 URL

请求参数：

js 复制代码

{
  "id": "xxx",
  "fileName": "example.txt",
  "partNumber": 1,
  "uploadId": "abc123"
}

返回示例：
js 复制代码
```
{
  "uploadUrl": "https://..."
}
```

在 /getSlicePresignedUrl 接口中，我们通过 AWS SDK 可以预签一个直传 URL

js 复制代码

import { UploadPartCommand } from '@aws-sdk/client-s3';
import { getSignedUrl } from '@aws-sdk/s3-request-presigner';

  const uploadUrl = await getSignedUrl(
    s3client,
    new UploadPartCommand({
      Bucket: AWS_BUCKET,
      Key: fileKey,
      PartNumber: partNumber,
      UploadId: uploadId,
    }),
    { expiresIn: 3600 },
  );

✅ 完成分片上传

接口地址 ：POST /completeSliceUpload
功能：合并所有已上传的分片

请求参数：

js 复制代码

{
  "id": "xxx",
  "fileName": "example.txt",
  "uploadId": "abc123",
  "parts": [
    { "ETag": "etag1", "PartNumber": 1 },
    { "ETag": "etag2", "PartNumber": 2 }
  ]
}

返回示例：

js 复制代码

{
  "id": "xxx",
  "location": "https://..."
}

2.2 前端设计

为了方便使用，我们尝试构建一套方便使用的 SDK，设计的 Options 如下

js 复制代码

interface UploadSliceOptions {
  fileName: string;
  id: string;
  getContent: (
    uploadSlice: (params: { content: ArrayBufferLike; partNumber: number; isLast?: boolean }) => Promise<void>,
  ) => Promise<void>;
  acl?: 'public-read' | 'authenticated-read';
  contentType?: string;
  contentEncoding?: 'gzip';
}

这些参数的设计意图是：

fileName: 分片最终合并时呈现的名字
id ：同名文件可能实际并不同，可以使用 hash 值来区分
核心上传逻辑的抽象（getContent 函数）：
- 职责：负责异步地生成或获取每一个文件分片（比如从本地文件中读取一块数据）
- 不直接接收文件内容，而是接收一个回调函数 uploadSlice 作为参数。
  - uploadSlice 的职责是：负责异步地将这一个分片的数据（content）和它的序号（partNumber）发送到服务器。
可选的文件属性（HTTP 头部相关）：
contentType?: string: 可选。指定文件的 MIME 类型（例如 'image/jpeg' 或 'application/pdf'）。这在云存储中很重要，它会影响文件被访问时的 Content-Type 响应头。
contentEncoding?: 'gzip': 可选。指明文件内容是否（或如何）被压缩的。在这里，它明确只支持 'gzip'，意味着如果提供了这个选项，上传的内容会被进行独立分片压缩。

2.2.1 核心功能实现

📤 单个分片上传

uploadSlice 函数实现逻辑如下：

通过 FileClient 获取预签名 URL
使用 fetch API 将分片内容上传到该 URL
获取 ETag，并返回上传结果

js 复制代码

export const uploadSlice = async ({ id, fileName, partNumber, content, uploadId }: UploadSliceParams) => {
  const { uploadUrl: presignedUrl } = await FileClient.getSlicePresignedUrl({
    id,
    fileName,
    partNumber,
    uploadId,
  });

  const uploadRes = await fetch(presignedUrl, {
    method: 'PUT',
    body: content,
  });
  const etag = uploadRes.headers.get('etag');
  if (!etag) throw new Error('Upload failed');
  return {
    ETag: etag,
    PartNumber: partNumber,
  };
};

🔁 分片上传流程控制

uploadSliceFile 实现完整上传逻辑：

创建上传任务，获取 uploadId
若返回完整 URL（如小文件无需分片），则直接返回
调用 getContent 回调，获取各分片内容并上传
对失败的分片进行重试
所有分片上传完成后，调用接口合并分片

js 复制代码

  const uploadTask = await FileClient.createSliceUpload({
    fileName,
    id,
    acl,
    contentEncoding,
    contentType,
  });
  
  if (uploadTask.url) {
    return uploadTask.url; // 代表这个 id 的文件实际上已经上传过了
  }
  
  const { uploadedParts = [] } = uploadTask;
  const uploadId = uploadTask.uploadId as string;

  const parts: { PartNumber: number; ETag: string }[] = [...(uploadedParts as { PartNumber: number; ETag: string }[])];
  
  await getContent(async ({content,isLast})=>{
     ...
     const part = await uploadSlice({
         content: new Blob([content]),
         partNumber: currentPartNumber,
         uploadId,
         id,
         fileName,
     });
     parts.push(part);
  })
  
  
  return FileClient.completeSliceUpload(...)

❗ 错误处理与重试机制

最大重试次数：MAX_RETRY_TIMES = 3
重试延迟时间：RETRY_DELAY = 1000ms
若分片上传失败，则按策略重试
合并上传前需校验所有分片是否上传成功

🔄 分片去重处理

合并前对已上传分片进行去重：

按分片序号排序
使用 Set 记录已处理的分片编号
构建唯一的分片列表

2.2.2 使用示例

虽然咋一看有些奇怪，但这种方式对于流式上传支持度更好，且在普通场景也同样适用。如下边这份代码是普通文件的上传 demo

js 复制代码

// 示例：上传一个大文件
const fileId = 'unique-file-id';
const fileName = 'large-file.mp4';
const file = /* 获取文件对象 */;
const chunkSize = 5 * 1024 * 1024; // 每片5MB
const chunks = Math.ceil(file.size / chunkSize);

const fileUrl = await uploadSliceFile({
  fileName,
  id: fileId,
  getContent: async (uploadSlice) => {
    for (let i = 0; i < chunks; i++) {
      const start = i * chunkSize;
      const end = Math.min(file.size, start + chunkSize);
      const chunk = file.slice(start, end);

      await uploadSlice({
        content: chunk,
        partNumber: i + 1, // 分片编号从1开始
      });
    }
  },
});

console.log('文件上传成功，访问地址：', fileUrl);

3 进阶：分块 GZIP 压缩

我们的日志，其以字符串的形式保存，上传时，最终也是要上传成一份文本型文件。

所以，我们可以考虑在上传前进行压缩，以进一步减少上传时的体积------这个过程中，我们可以考虑使用 gzip、brotli、zstd 等算法。

从兼容性考虑 💭，现在 Web 浏览器支持率最高的算法是 gzip 和 brotli 算法。但 brotli 的原理决定了我们可能很难完整发挥出 brotli 算法的效果。

原因有几个。

第一个致命的原因是，brotli(RFC 7932) 是一种 raw stream 格式，它的数据流由一个或多个"元块"(Meta-Block) 组成。流中的最后一个元块会包含一个特殊的 ISLAST 标志位，它相当于一个「文件结束符」

当我们单独压缩每一个分散的文本片段时：

文本A -> 片段A.br (最后一个元块包含 ISLAST=true)
文本B -> 片段B.br (最后一个元块包含 ISLAST=true)
文本C -> 片段C.br (最后一个元块包含 ISLAST=true)
...

当我们把它们合并在一起 时（例如通过 cat A.br B.br C.br > final.br），我们得到的文件结构是： [A的数据... ISLAST=true] [B的数据... ISLAST=true] [C的数据... ISLAST=true]

当一个标准的 Brotli 解码器（比如浏览器）读取这个 final.br 文件时：

解码器开始读取 [A的数据...]。
解码器读取到 A 的最后一个元块，看到了 ISLAST=true 标志。
解码器立即停止解码，因为它认为流已经结束了。
[B的数据...] 和 [C的数据...] 会被完全忽略，当成文件末尾的"垃圾数据"。

最终结果：我们只能成功解压出 文本A，所有后续的文本内容都会丢失。

------即便我们手动将 IS_LAST 修改正确，但「独立压缩」会导致另一个严重问题------压缩率的极大损失。

因为 br 的压缩过程中，需要先建立一个滑动窗口字典。而如果我们对每一个分片都进行压缩，br 实际上需要为每一个分片建立一个字典。

这意味着这个过程中，最核心的字典不断被重置，br 压缩器丢失了用于判断内部重复的关键工具， 进而会导致压缩率极大的下降。

而对于 gzip 来讲，虽然 gzip body 采用的 deflate 算法同样需要字段，但其窗口大小只有 32KB（br 则是 4-16MB），而我们单个分片单最小大小即是 %MB，所以对于 gzip 来说，分成 5MB 再压缩还是 500MB 直接压缩区别并不大。

所以，我们选择 gzip 来做分块压缩。

Gzip 协议是一种文件格式，它充当一个"容器"。这个容器包裹了使用 DEFLATE (RFC 1951) 算法压缩的数据块，并为其添加了元信息和校验和，以确保文件的完整性和可识别性。

一个 gzip 文件由三个核心部分组成：

Header (头部) ：识别文件并提供元信息。
Body (主体) ：包含 DEFLATE 压缩的数据流。
Footer (尾部) ：提供数据完整性校验。

这意味着，我们进行分块压缩时，可以通过手动创建 header + body + footer 的方式进行分块压缩。

头部至少有 10 个字节。

偏移量 (字节)	长度 (字节)	字段名	固定值 / 描述
0	1	`ID1`	`0x1f` (或 31)。这是识别 `gzip` 文件的"魔术数字"第一部分。
1	1	`ID2`	`0x8b` (或 139)。"魔术数字"第二部分。
2	1	`CM`	`0x08` (或 8)。表示压缩方法 (Compression Method) 为 `DEFLATE`。
3	1	`FLG`	标志位 (Flags)。这是一个极其重要的字节，它的每一位都代表一个布尔值，用于控制是否存在"可选头部"。
4	4	`MTIME`	文件的最后修改时间 (Modification Time)，以 4 字节的 Unix 时间戳格式存储。
8	1	`XFL`	额外标志 (Extra Flags)。通常用于指示 `DEFLATE` 压缩器使用的压缩级别（例如 `0x02` = 最高压缩率，`0x04` = 最快压缩率）。
9	1	`OS`	操作系统 (Operating System)。`0x03` = Unix, `0x00` = Windows/FAT, `0xFF` = 未知。

其中的核心部分是 FLG，即标志位。这是头部第 4 个字节 (偏移量 3)，我们需要按位 (bit) 来解析它：

Bit (位)	掩码 (Hex)	字段名	描述
0 (最低位)	`0x01`	`FTEXT`	如果置 1，表示文件可能是 ASCII 文本文件（这只是一个提示）。
1	`0x02`	`FHCRC`	如果置 1，表示头部包含一个 2 字节的头部校验和 (CRC-16) 。
2	`0x04`	`FEXTRA`	如果置 1，表示头部包含一个扩展字段 (extra field) 。
3	`0x08`	`FNAME`	如果置 1，表示头部包含原始文件名。
4	`0x10`	`FCOMMENT`	如果置 1，表示头部包含注释。
5	`0x20`	`RESERVED`	保留位，必须为 0。
6	`0x40`	`RESERVED`	保留位，必须为 0。
7	`0x80`	`RESERVED`	保留位，必须为 0。

然后，根据 FLG 标志位的设置，紧跟在 10 字节固定头部后面的，可能会按顺序出现以下字段：

FEXTRA (如果 FLG & 0x04 为真):
- XLEN (2 字节): 扩展字段的总长度 N。
- EXTRA (N 字节): N 字节的扩展数据。
FNAME (如果 FLG & 0x08 为真):
- 原始文件名，以 NULL ( 0x00 ) 字节结尾的 C 风格字符串。
FCOMMENT (如果 FLG & 0x10 为真):
- 注释，以 NULL ( 0x00 ) 字节结尾的 C 风格字符串。
FHCRC (如果 FLG & 0x02 为真):
- 一个 2 字节的 CRC-16 校验和，用于校验整个头部（包括所有可选部分）的完整性。

我们的话，我们需要写入 filename，所以转换成代码，就是如下的实现：

js 复制代码

/**
 * 生成标准 GZIP Header（10 字节）
 * 符合 RFC 1952 规范。
 * 可用于拼接 deflate raw 数据生成完整 .gz 文件。
 */
/**
 * 生成包含文件名的标准 GZIP Header
 * @param {string} filename - 要嵌入头部的原始文件名
 */
export function createGzipHeader(filename: string): Uint8Array {
  // 1. 创建基础的10字节头部，并将Flags位设置为8 (FNAME)
  const header = new Uint8Array([
    0x1f,
    0x8b, // ID1 + ID2: magic number
    0x08, // Compression method: deflate (8)
    0x08, // Flags: 设置FNAME位 (bit 3)
    0x00,
    0x00,
    0x00,
    0x00, // MTIME: 0
    0x00, // Extra flags: 0
    0x03, // OS: 3 (Unix)
  ]);

  // 动态设置 MTIME
  const mtime = Math.floor(Date.now() / 1000);
  header[4] = mtime & 0xff;
  header[5] = (mtime >> 8) & 0xff;
  header[6] = (mtime >> 16) & 0xff;
  header[7] = (mtime >> 24) & 0xff;

  // 2. 将文件名字符串编码为字节
  const encoder = new TextEncoder(); // 默认使用 UTF-8
  const filenameBytes = encoder.encode(filename);

  // 3. 拼接最终的头部
  // 最终头部 = 10字节基础头 + 文件名字节 + 1字节的null结束符
  const finalHeader = new Uint8Array(10 + filenameBytes.length + 1);

  finalHeader.set(header, 0);
  finalHeader.set(filenameBytes, 10);
  // 最后一个字节默认为0，作为null结束符

  return finalHeader;
}

footer 则相对简单一些，尾部是固定 8 字节的块，由 CRC32 和 ISIZE 组成：

偏移量	长度 (字节)	字段名	描述
0	4	`CRC-32`	原始未压缩数据的 CRC-32 校验和。
4	4	`ISIZE`	原始未压缩数据的大小 (字节数)。由于它只有 4 字节，`gzip` 文件无法正确表示大于 4GB 的文件（解压后的大小）。

这两个值是 gzip 压缩过程中需要从整个文件角度计算的信息，由于两者均可以增量计算，问题不大。（crc32 本身计算量不大，推荐直接使用 sheetjs 库就行）

这样的话，我们就得到了这样的代码：

js 复制代码

export function createGzipFooter(crc32: number, size: number): Uint8Array {
  const footer = new Uint8Array(8);
  const view = new DataView(footer.buffer);
  view.setUint32(0, crc32, true);
  view.setUint32(4, size % 0x100000000, true);
  return footer;
}

3.2 BODY

对我们来说，中间的 raw 流是最麻烦的。

gzip body 中的 DEFLATE 流 (RFC 1951) 并不是一个单一的、连续的东西，它本身就有一套非常重要的"特殊规则"。

DEFLATE 流的真正结构是由一个或多个数据"块" (Block) 拼接而成的。

gzip压缩器在工作时，会根据数据的情况，智能地将原始数据分割成不同类型的"块"来处理。它可能会先用一种块，然后再换另一种，以达到最佳的压缩效果。

DEFLATE 流中的每一个"块"，都必须以一个 3-bit (比特) 的头部开始。这个 3-bit 的头部定义了这个块的所有规则。

这 3 个 bit (比特) 分为两部分：

BFINAL (1-bit): "最后一块"标记
- 1: 这是整个 DEFLATE 流的最后一个块。解压器在处理完这个块后，就应该停止，并去寻找 gzip 的 Footer (CRC-32 和 ISIZE)。
- 0: 后面还有更多的块，请继续。
BTYPE (2-bits): "块类型"
- 这 2 个 bit 决定了紧随其后的整个块的数据要如何被解析。

BTYPE 字段有三种可能的值，每一种都代表一套完全不同的压缩规则：

****规则 1：BTYPE = 00 (无压缩块) 压缩器在分析数据时，如果发现数据是完全随机的（比如已经压缩过的图片、或加密数据），它会发现压缩后的体积反而变大了。

此时，它会切换到 00 模式，意思是："我放弃压缩，直接原文存储。"
结构：
1. (BFINAL, 00) 这 3-bit 头部。
2. 跳到下一个字节边界 (Byte-alignment)。
3. LEN (2 字节): 声明这个块里有多少字节的未压缩数据（长度 N）。
4. NLEN (2 字节): LEN 的"反码"（NOT LEN），用于校验 LEN 是否正确。
5. N 字节的原始数据（原文照搬）。

规则 2：BTYPE = 01 (静态霍夫曼压缩)

这是"标准"规则。压缩器使用一套固定的、在 RFC-1951 规范中预先定义好的霍夫曼树（Huffman Tree）来进行压缩。
这套"静态树"是基于对大量英语文本统计分析后得出的最佳通用编码表（例如，'e'、'a'、' ' 的编码非常短）。
优点：压缩器不需要在数据流中包含霍夫曼树本身，解压器直接使用它内置的这套标准树即可。这节省了头部空间。
缺点：如果你的数据不是英语文本（比如是中文或代码），这套树的效率可能不高。
结构：
1. (BFINAL, 01) 这 3-bit 头部。
2. 紧接着就是使用"静态树"编码的 LZ77 + 霍夫曼编码 的数据流。
3. 数据流以一个特殊的"块结束"(End-of-Block, EOB) 符号（静态树中的 256 号符号）结尾。

规则 3：BTYPE = 10 (动态霍夫曼压缩)

这是"定制"规则，也是压缩率最高的规则。
压缩器会先分析这个块的数据，统计出所有字符的准确频率，然后为这个块"量身定做"一套最优的霍夫曼树。
优点：压缩率最高，因为它完美贴合了当前数据块的特征（比如在压缩 JS 时，{ } ( ) . 的编码会变得极短）。
缺点：压缩器必须把这套"定制树"本身也压缩后，放到这个块的开头，以便解压器知道该如何解码。这会占用一些头部空间。
结构：
1. (BFINAL, 10) 这 3-bit 头部。
2. 一个"定制霍夫曼树"的描述信息（这部分本身也是被压缩的）。
3. 紧接着是使用这套"定制树"编码的 LZ77 + 霍夫曼编码 的数据流。
4. 数据流以一个特殊的"块结束"(End-of-Block, EOB) 符号（定制树 中的 256 号符号）结尾。

------不过，于我们而言，我们先通过静态霍夫曼压缩即可。

这个过程中，我们需要借助三方库，目前浏览器虽然支持 CompressionStream API，但并不支持我们进行精确流控制。

js 复制代码

import pako from 'pako';

export async function compressBufferRaw(buf: ArrayBufferLike, isLast?: boolean): Promise<ArrayBufferLike> {
  const originalData = new Uint8Array(buf);

  const deflater = new pako.Deflate({ raw: true });
  deflater.push(originalData, isLast ? pako.constants.Z_FINISH : pako.constants.Z_SYNC_FLUSH);
  if (!isLast) {
    deflater.onEnd(pako.constants.Z_OK);
  }
  const compressedData = deflater.result;
  return compressedData.buffer;
}

我们用一个示例来表示一个完整 gzip 文件的话，方便理解。假设我们压缩一个叫 test.txt 的文件，它的 Gzip 文件 test.txt.gz 在十六进制编辑器中可能如下所示：

js 复制代码

Offset  Data
------  -------------------------------------------------------------
0000    1F 8B         (ID1, ID2: Gzip 魔术数字)
0002    08            (CM: DEFLATE)
0003    08            (FLG: 0x08 = FNAME 标志位置 1)
0004    XX XX XX XX   (MTIME: 4 字节时间戳)
0008    04            (XFL: 最快压缩)
0009    03            (OS: Unix)

(可选头部开始)
000A    74 65 73 74   (t e s t)
000E    2E 74 78 74   (. t x t)
0012    00            (FNAME: NULL 终结符)

(Body 开始)
0013    ED C0 ...     (DEFLATE 压缩流开始...)
...
...     ...           (...此块数据流的末尾包含一个 EOB 符号...)
                      (... DEFLATE 压缩流结束)

(Footer 开始)
XXXX    YY YY YY YY   (CRC-32: 原始 test.txt 文件的校验和)
XXXX+4  ZZ ZZ ZZ ZZ   (ISIZE: 原始 test.txt 文件的大小)

至此，我们完成了一套社区前列的分片上传方案。S3 将所有上传的部分按序合并后，在S3上形成的文件结构是：[Gzip Header][Deflate_Chunk_1][Deflate_Chunk_2]...[Deflate_Last_Chunk][Gzip Footer] 这个拼接起来的文件是一个完全合法、可流式解压的 .gz 文件。

4 性能 & 对比

为了验证该方案（Smart S3 Gzip）的实际效果，我们构建了一个基准测试环境，将本文方案与「普通直传」及「传统前端压缩上传」进行全方位对比。

4.1 测试环境

测试文件：1GB Nginx Access Log (纯文本)
网络环境：模拟家用宽带上行 50Mbps (约 6.25MB/s)
测试设备：MacBook Pro (M1 Pro), 32GB RAM
浏览器：Chrome 143

4.2 核心指标对比

核心指标	方案 A：普通直传	方案 B：前端整体压缩	方案 C：本文方案 (分片 Gzip 流)
上传总耗时	~165 秒	~45 秒 (但等待压缩很久)	~38 秒 (边压边传)
首字节发送时间	0 秒 (立即开始)	30 秒+ (需等待压缩完成)	0.5 秒 (首个分片压缩完即发)
峰值内存占用（计算值）	50MB (流式)	2GB+ (需读入全量文件)	100MB (仅缓存并发分片)
网络流量消耗	1GB	~120MB	~121MB (略多出的 Header 开销可忽略)
客户端 CPU 负载	极低 (<5%)	单核 100% (持续一段时间，可能 OOM)	多核均衡 (并发压缩，利用率高)

4.3 深度解析

🚀 1. 速度提升的秘密：流水线效应

在方案 B（整体压缩）中，用户必须等待整个 1GB 文件在本地压缩完成，才能开始上传第 1 个字节。这是一种「串行阻断」模型。而本文方案 C 采用了「流水线（Pipeline）」模型：压缩第 N 个分片的同时，正在上传第 N-1 个分片。对于高压缩率的文本文件（通常压缩比 5:1 到 10:1），网络传输往往比本地 CPU 压缩要慢。这意味着 CPU 的压缩几乎是"免费"的，因为它掩盖在了网络传输的时间里。

💰 2. 成本分析：不仅是快，还省钱

AWS S3 的计费主要包含存储费和流量费。

存储成本：1GB 的日志存入 S3，如果未压缩，每月存储费是压缩后的 5-10 倍。虽然 S3 本身很便宜，但对于 PB 级日志归档，这笔费用惊人。
传输加速成本：如果使用了 S3 Transfer Acceleration，费用是按流量计算的。压缩后上传意味着流量费用直接打一折。

🛡️ 3. 内存安全性

方案 B 是前端的大忌。试图将 1GB 文件读入 ArrayBuffer 进行整体 gzip 压缩，极其容易导致浏览器 Tab 崩溃（OOM）。本文方案将内存控制在 分片大小 * 并发数 (例如 5MB * 5 = 25MB) 的安全范围内，即使上传 100GB 文件也不会爆内存。

4.4 适用场景与局限性

✅ 强烈推荐场景：

日志归档 / 数据备份：CSV, JSON, SQL Dump, Log 文件。压缩率极高，收益巨大。
弱网环境：上传带宽受限时，压缩能显著减少等待时间。

❌ 不推荐场景：

已经压缩的文件：MP4, JPG, ZIP, PNG。再次 Gzip 几乎无压缩效果，反而浪费 CPU。
超低端设备 ：如果用户的设备是性能极差的老旧手机，CPU 压缩速度可能低于网络上传速度，反而成为瓶颈。建议在 SDK 增加 navigator.hardwareConcurrency 检测，自动降级。

5 结语

通过深入理解 HTTP、AWS S3 协议以及 Gzip 的二进制结构，我们打破了"压缩"与"分片"不可兼得的魔咒。这套系统目前已在我们内部的日志回放平台稳定运行，有效减少文件上传时长。

有时候，技术的突破口往往就藏在那些看似枯燥的 RFC 文档里。希望这篇"硬核"的实战总结，能给你带来一些启发。

👋 手搓 gzip 实现的文件分块压缩上传