为什么需要206状态码？

HTTP 206 Partial Content（部分内容）状态码是处理大文件传输的利器，它能实现两个核心价值： 1. 支持断点续传：客户端可以只请求文件的特定部分 2. 节约带宽：避免重复传输已缓存的数据块

传统方案的痛点

在处理大文件（如视频、安装包）时，传统方案面临三个主要问题：

• 带宽浪费：用户中断下载后需要重新传输整个文件
• 缓存效率低：完整的文件缓存导致存储空间占用高
• 延迟明显：小范围内容变更需要重新下载整个资源

206状态码通过Range Request（范围请求）机制完美解决了这些问题。

技术实现解析

HTTP Range请求流程

客户端请求: 
GET /video.mp4 HTTP/1.1
Range: bytes=1024-2047

服务端响应:
HTTP/1.1 206 Partial Content
Content-Range: bytes 1024-2047/102400
Content-Length: 1024

Go语言实现示例

// 处理范围请求的核心逻辑
func handleRangeRequest(w http.ResponseWriter, r *http.Request) {
    // 1. 解析Range头
    rangeHeader := r.Header.Get("Range")
    if rangeHeader == "" {
        http.Error(w, "Range header required", http.StatusBadRequest)
        return
    }

    // 2. 检查缓存（伪代码）
    cacheKey := generateCacheKey(r.URL.Path, rangeHeader)
    if data, exists := diskCache.Get(cacheKey); exists {
        sendCachedResponse(w, data)
        return
    }

    // 3. 读取文件分片
    file, err := os.Open("largefile.mp4")
    if err != nil {
        http.Error(w, err.Error(), http.StatusInternalServerError)
        return
    }
    defer file.Close()

    // 4. 设置响应头
    w.Header().Set("Content-Type", "video/mp4")
    w.Header().Set("Accept-Ranges", "bytes")
    w.Header().Set("Cache-Control", "max-age=3600")

    // 5. 返回206响应
    http.ServeContent(w, r, "", time.Now(), file)
}

性能优化策略

缓存碎片整理

• 定时合并相邻的缓存块
• 采用LRU（最近最少使用）淘汰策略
• 设置合理的最大分片大小（建议1MB-10MB）

内存与磁盘权衡

1. 热数据（频繁访问范围）保存在内存
2. 冷数据持久化到磁盘
3. 使用mmap减少内存拷贝开销

并发处理要点

• 对同一资源范围加读写锁
• 实现请求合并（coalescing）机制
• 限制单个资源的并发范围请求数

生产环境避坑指南

案例1：错误的内容长度计算

// 错误做法
fileInfo, _ := file.Stat()
contentLength := fileInfo.Size() // 对于范围请求应该返回分片大小

// 正确做法
contentLength := endByte - startByte + 1

案例2：缓存验证头缺失

必须包含这些响应头： - ETag（实体标签） - Last-Modified - Vary: Range

案例3：字节范围重叠处理

当收到重叠的范围请求时： 1. 可以返回416（范围不满足）状态码 2. 或合并范围后返回新分片 3. 但需要明确记录合并行为

开放性问题

如何设计支持206的分布式缓存系统？考虑以下挑战： 1. 范围请求的路由一致性 2. 分片数据的分布式存储 3. 缓存的全局一致性保证 4. 跨数据中心的带宽优化