如何向浏览器流式传输动态生成的tar归档文件并解决进度与续传问题

一、解决浏览器下载进度显示问题 #

• 使用估算的Content-Length头：既然可以通过所有文件总大小加上tar格式的填充值（每个文件内容按512字节块对齐，不足补0，加上每个文件的512字节头）估算出归档的大致大小，直接将这个估算值设置到HTTP响应的Content-Length头中，替代Transfer-Encoding: chunked。浏览器会基于这个值渲染进度指示器，虽然最终实际大小可能和估算值有微小差异，但用户能直观看到下载进度，误差在可接受范围。
• 可选：实时进度增强：如果需要更精准的进度反馈，可以通过Server-Sent Events（SSE）建立额外连接，服务器在处理每个文件的传输时，向客户端推送已传输字节数、已完成文件数等信息，前端页面基于这些数据自定义进度显示。

二、实现断点续传功能 #

要解决中断恢复问题，需基于HTTP范围请求（Range Requests）实现，核心是让服务器能从指定字节偏移量恢复tar流的生成：

1. 维护下载会话状态：
   • 为每个下载请求生成唯一会话ID（通过Cookie或请求参数传递），服务器端存储会话的关键进度信息：已传输总字节数、已处理完成的文件列表、当前正在传输的文件及其已传输字节偏移、各文件在tar归档中的起始/结束字节位置（基于估算值预计算）。
   • 会话数据可以用内存缓存（如Redis）或轻量级数据库存储，避免占用过多资源。
2. 处理Range请求：
   • 当客户端发送Range: bytes=X-请求（X为上次中断时已下载的字节数），服务器根据会话定位到对应的文件和该文件内的偏移位置。
   • 向后端文件服务器请求对应文件的Range: bytes=Y-部分（Y为该文件在tar流中剩余的起始偏移），继续生成tar流：如果是在文件内容传输中中断，直接续传剩余内容；如果是在文件头或填充部分中断，需要补全对应的tar结构。
   • 响应返回206 Partial Content状态码，同时设置Content-Range: bytes X-Z/TotalEstimated（Z为估算的总字节数）和Content-Length为剩余传输字节数。
3. 后端文件服务器适配：确保提供文件的后端服务器支持Range请求，这样主服务器无需重新下载已传输过的文件内容，节省带宽和时间。

三、客户端流式写入本地文件 #

要实现单个文件下载且不占用大量客户端内存，可使用浏览器的File System Access API：

• 文件句柄获取：通过showSaveFilePicker()让用户选择保存路径，获取可写文件句柄。
• 流式写入：
  • 首次下载：创建新文件并开始写入响应数据流。
  • 断点续传：打开已存在的文件，将写入位置定位到文件末尾，继续追加写入响应数据。
  • 使用ReadableStream处理服务器返回的数据流，分块写入本地文件，避免将整个归档加载到内存。
• 兼容性处理：若需兼容不支持File System Access API的旧浏览器，可通过Service Worker配合IndexedDB暂存分块数据，下载完成后再合并为单个文件，但体验不如直接写入本地文件流畅。

四、额外注意事项 #

• tar归档一致性：如果后端文件可能在下载过程中更新，需为每个文件添加版本标识或哈希值，续传时校验文件内容是否变化。若文件已更新，需重新生成对应部分的tar流，或提示用户重新下载。
• 服务器资源优化：主服务器处理流式tar生成时，要避免内存泄漏，确保每个会话结束后及时清理相关状态数据；同时限制并发下载数，避免服务器资源耗尽。

内容的提问来源于stack exchange，提问作者fanofcomputers