引言：大文件传输的性能之痛

最近在做一个视频点播项目时，遇到一个头疼的问题：当用户频繁拖动进度条观看视频时，服务器总是重新发送整个文件。这不仅浪费带宽，还导致加载时间过长。经过排查发现，传统的200 OK全量传输模式是罪魁祸首——即便用户只需要文件的一小部分。

HTTP 206的救赎之道

技术背景

HTTP协议早就为我们准备了解决方案——206 Partial Content状态码。配合Range请求头，它允许客户端指定需要获取的资源范围（如bytes=0-999），服务器则返回对应片段。这种机制特别适合：

• 视频/音频流媒体
• 大型文档下载
• 断点续传场景

核心原理

整个过程像去餐厅点餐：

1. 客户端说："我要牛排的中间部分（Range请求）"
2. 服务员回应："这是您要的214-563克部分（206响应）"
3. 如果请求范围不合理，厨房会拒绝："416 Range Not Satisfiable"

实战：Node.js实现方案

基础框架

以下是基于Express的中间件实现，包含完整的磁盘缓存处理：

const fs = require('fs');
const path = require('path');

app.get('/video/:filename', (req, res) => {
  const filePath = path.join(CACHE_DIR, req.params.filename);

  // 检查文件是否存在（缓存命中）
  fs.stat(filePath, (err, stats) => {
    if (err) return res.sendStatus(404);

    const fileSize = stats.size;
    const range = req.headers.range;

    // 无Range头时回退全量传输
    if (!range) {
      const head = {
        'Content-Length': fileSize,
        'Content-Type': 'video/mp4'
      };
      res.writeHead(200, head);
      return fs.createReadStream(filePath).pipe(res);
    }

    // 解析Range头
    const parts = range.replace(/bytes=/, "").split("-");
    const start = parseInt(parts[0], 10);
    const end = parts[1] 
      ? parseInt(parts[1], 10) 
      : fileSize - 1;

    // 处理非法范围请求
    if (start >= fileSize || end >= fileSize) {
      return res.status(416).send('Range Not Satisfiable');
    }

    // 构造206响应
    const chunkSize = (end - start) + 1;
    const head = {
      'Content-Range': `bytes ${start}-${end}/${fileSize}`,
      'Accept-Ranges': 'bytes',
      'Content-Length': chunkSize,
      'Content-Type': 'video/mp4'
    };

    res.writeHead(206, head);
    const stream = fs.createReadStream(filePath, { start, end });
    stream.pipe(res);
  });
});

关键优化点

1. 缓存预热：启动时加载热点文件到内存
2. 流式处理：避免将整个文件读入内存
3. 范围校验：防止恶意构造超大Range请求

性能对比测试

使用1GB视频文件测试，结果令人惊喜：

| 场景 | 平均耗时 | 带宽消耗 | |---------------|---------|---------| | 全量传输 | 12.3s | 1GB | | 分块传输(10%) | 1.4s | 100MB | | 分块传输(1%) | 0.2s | 10MB |

避坑指南

1. Content-Range计算错误
2. 错误：end值包含头字节

3. 修正：chunkSize = end - start + 1

4. 缓存不一致

5. 现象：文件更新后仍返回旧片段

6. 方案：使用ETag或Last-Modified头

7. 内存泄漏

8. 陷阱：未关闭文件流
9. 预防：用stream.on('end', cleanup)

生产环境建议

• 并发控制：使用p-limit限制并发流数量
• 缓存策略：
• 热文件：内存缓存
• 冷文件：磁盘缓存
• 监控指标：
• 206响应率
• 平均分块大小
• 416错误率

总结与行动建议

通过合理使用206状态码，我们成功将视频服务的带宽成本降低了70%。建议你：

1. 在Nginx配置中开启proxy_request_buffering off
2. 使用curl -r 0-99 http://example.com/file测试端点
3. 监控416状态码识别异常请求

下次遇到大文件传输场景时，不妨试试这把性能优化的瑞士军刀！