之前公司里面要做视频播放，总结开发过程，写了一篇文章《如何优雅地实现网页播放视频》。近期，项目中又有在网页上传、下载文件的需求，并且要求能够支持大文件和“高并发”，与此前的视频播放在技术上存在一些联系，经过研究和动手实践后，整理如下，方便有需要的人。
1.文件下载
1.1 简单实现
如果是单纯实现功能，不考虑文件大小、服务器负载等各种情况，几行代码就能实现一个文件下载接口。这里以Go语言为例，下载windows系统D盘下的test.pdf文件。
package main
import (
"net/http"
"os"
)
func main() {
server := http.Server{Addr: ":8080"}
http.HandleFunc("/download", func(w http.ResponseWriter, r *http.Request) {
bytes, _ := os.ReadFile("D:\\test.pdf")
header := w.Header()
header.Set("Content-type", "application/octet-stream")
header.Set("Content-Disposition", "attachment;filename=test.pdf")
w.Write(bytes)
})
server.ListenAndServe()
}
以上代码直接读取文件内容，并将内容写入HTTP response，真的是非常简单、粗暴。各种编程语言的web库通常会在此基础上做一些包装，内置一些响应头设置、HTTP Status设置、异常处理等操作，能够更简单地实现文件下载。
Fiber (go)
import "github.com/gofiber/fiber/v2"
func main() {
app := fiber.New()
app.Get("/download", Download)
app.Listen(fmt.Sprintf(":%v", 8080))
}
func Download(c *fiber.Ctx) error {
c.SendFile("D:\\test.pdf")
}
Sanic (python)
from sanic.response import file
@app.route("/")
async def handler(request):
return await file("/path/to/whatever.png")
1.2 问题分析
以上办法实现虽然简单，但同时也存在问题。将文件从磁盘或其它存储（如OSS）写入http response的时，文件内容首先要读取到内存，如果文件特别大，甚至请求频率特别高时，服务器的内存必然会消耗殆尽，最终引发程序崩溃。
1.3 解决方案
为了解决此类问题，计算机领域的大佬们早就想好了解决方案，在制定http协议时，规定了可以在request header中携带Range（例如Range值为"bytes=0-1023"，表示只获取文件起始的1kb内容），告知服务端只获取部分内容，这种办法叫做分片传输（chunked transfer）。将一个体积较大的文件切割成若干体积较小的块，将原来的一次性获取变成多次获取，最终再将获取到的所有内容在客户端组装成一个完整的问题。
1.4 服务端实现
以Go语言为例，在Fiber库的基础上，实现分片下载逻辑，以下代码演示的是本地文件下载，如果是从OSS等其它存储下载，原理大致相同。
func Download(c *fiber.Ctx) error {
const filename = "D:\\test.pdf"
f, err := os.Open(filename)
if err != nil {
return errors.WithStack(err)
}
defer f.Close()
fileinfo, _ := f.Stat()
rangeData, err := c.Range(int(fileinfo.Size()))
if err != nil {
return errors.WithStack(err)
}
// TODO disallow multirange request
if _, err := f.Seek(int64(rangeData.Ranges[0].Start), 0); err != nil {
return errors.WithStack(err)
}
start := rangeData.Ranges[0].Start
end := rangeData.Ranges[0].End
length := end - start + 1
// TODO check chunk size
b := make([]byte, length)
if _, err := f.Read(b); err != nil {
return errors.WithStack(err)
}
// TODO You should read the md5 value from database where the file metadata stored, rather than calculating it every time you download the file.
hash, _ := cryptor.Md5File(filename)
c.Response().Header.Add("x-file-hash", hash)
c.Response().Header.Add("Accept-Ranges", "bytes")
c.Response().Header.Add("Content-Type", "application/octet-stream")
c.Response().Header.Add("Content-Disposition", fmt.Sprintf(`attachment; filename="%s"`, url.QueryEscape(fileinfo.Name())))
c.Response().Header.Add("Content-Range", fmt.Sprintf("bytes %v-%v/%v", start, end, fileinfo.Size()))
return c.Status(206).SendStream(bytes.NewReader(b), length)
}
其中c.Range()这个函数根据http request header中的Range值以及文件体积，进行一些校验和修正，以防客户端没有正确传递Range值导致各种异常情况。同时，Range是支持多范围(multirange)请求的，例如"bytes=0-1023,1024-2047"表示获取文件起始的第1kb和第2kb内容，为了保证整个系统简单可控，直接限定不允许多范围请求，杜绝客户端一次请求特别多个chunk的情况。此外，服务端还要检查请求的每一块内容大小是否超过允许的范围，这应该由服务端控制，不能交给客户端自由选择，否则依然会存在前文提及的内存问题。
1.5 客户端实现
服务端的下载接口准备完毕后，客户端还有一些必须的工作要完成，才能完整地实现分片下载。
1.5.1 获取文件大小
为了将文件按照与服务端约定的chunk size分片请求文件内容，首先需要获取文件大小，此时可以提供一个获取文件元信息的接口，也可以与下载文件公用一个接口，只不过先用一个bytes=0-0或者bytes=0-1的Range，“试探”性地获取文件内容，从response header中获取Content-Range值（例如bytes 0-0/1024，其中的1024即文件大小，单位为byte），从而得到文件大小。
1.5.2 下载所有文件块
获取到文件大小后，客户端根据与服务端约定好的chunk size（例如1024 * 1024，即1MB）对文件分割，将原本一次性获取文件内容转变为多次请求，每一次只请求部分内容。
很容易想到的办法是，将文件分片，计算得到每一片的Range范围，依次下载每一块内容，每次下载后如果还有未下载的块，就继续递归地下载接下来一块内容。
export const download_chunks = (path: string, size: number) => {
const chunk_size = 1024 * 1024; // 1M
const chunks = Math.ceil(size / chunk_size);
let chunk = 0;
const download_chunk = () => {
const start = chunk_size * chunk;
const end = ((start + chunk_size) >= size) ? (size - 1) : (start + chunk_size - 1);
const range = `bytes=${start}-${end}`;
// 省略下载文件部分的代码，用一行log代替
console.log("download chunk:" + (chunk + 1), range);
chunk++;
if (chunk <= chunks - 1) {
download_chunk();
}
};
download_chunk();
};
但由于是递归调用，也很容易想到函数调用栈溢出的情况，这在不同浏览器上也有不同表现。经测试，Firefox上的报错为Uncaught InternalError: too much recursion，而Chrome上的报错为Uncaught RangeError: Maximum call stack size exceeded，出现问题的调用深度也不是固定的。
为了解决递归调用的问题，对上面的代码进行一些调整，同时补上了下载每个chunk后的数据存储，这里使用的是LOCALFORAGE这个库以简单方式操作IndexedDB 。
export const download_chunks = (path: string, params: any, size: number) => {
const chunk_size = 1024 * 1024;
const chunks = Math.ceil(size / chunk_size);
const download_chunk = (current_chunk: number = 0, batch: number=1000) => {
const start = chunk_size * current_chunk;
const end = ((start + chunk_size) >= size) ? (size - 1) : (start + chunk_size - 1);
const range = `bytes=${start}-${end}`;
const url = `/api/${path.indexOf("/") === 0 ? path.substring(1) : path}`;
const config = {
method: "GET",
headers: {
"token": sessionStorage.getItem("token") || "",
"Range": range
}
}
window.fetch(url, config).then((res: any) => res.blob()).then(
(res: any) => {
localforage.setItem(`replace-with-your-file-id-${current_chunk}`, res);
batch--;
if (current_chunk < chunks - 1) {
if (batch > 0) {
download_chunk(current_chunk + 1, batch);
} else {
setTimeout(() => download_chunk(current_chunk + 1, 1000), 0);
}
}
}
).catch(reason => { console.error(reason) });
};
download_chunk(0, 1000);
};
这里用了setTimeout来取消递归函数无限制地增加调用栈深度，但由于setTimeout本身即使在设置延迟为0的时候，还是有微小的延迟，调用次数非常大时，累积的延迟时间就比较明显了。为了尽可能消除这种影响，我们将1000次递归作为一个批次，超过1000次后，使用setTimeout来重置递归。
这里可能不是最佳方案，如果有更好的办法，欢迎赐教！
1.5.3 组装文件
经过上面的步骤，文件会分片下载，最终保存到IndexedDB，以测试代码8.5M的pdf文件为例，按照每个chunk大小为1M进行分割成9个chunk，在IndexedDB中会存储9条记录。
image.png
接下来的任务就是要从这些数据中获取Blob，并按顺序合并成一个新的Blob，再将这个Blob转成文件下载。
首先准备一个工具函数，从Blob生成文件，并进行下载。
export const blob_to_file = (blob: Blob, filename?: string) => {
let url = window.URL.createObjectURL(blob);
let a = document.createElement('a');
a.style.display = 'none';
a.href = url;
a.download = filename ? filename : "unnamed";
a.target = "_blank";
document.body.appendChild(a);
a.click();
a.remove();
}
然后根据刚刚存储的文件分片，在已知一共有9个Blob的情况下进行文件合并，实际的场景肯定要进行优化以适应所有情况，这里先演示文件合并及下载过程。
const download_file = () => {
const data: Blob[] = [];
for (let i = 0; i <= 8; i++) {
const key = `replace-with-your-file-id-${i}`;
localforage.getItem(key).then(
(v: any) => {
data.push(v);
if (i === 8) {
// var blob = new Blob([...data], { type: 'application/pdf' });
var blob = new Blob([...data]);
blob_to_file(blob, "测试.pdf");
}
}
);
}
};
运行后，按照给定的文件名下载得到了期望的pdf文件，找到下载位置，能够正常打开，至此分片下载流程已经走通了，但是还遗留一些问题需要解决。
1.5.4 下载优化
刚刚下载文件分片存储到IndexedDB时，使用的Key为replace-with-your-file-id-0，replace-with-your-file-id-1...并且合并文件时也是在已知一共多少个分片的情况下，实际项目中肯定不能这样来读取文件数据，尤其在同时下载多个文件的情况下。
那么怎么以简单的方式来解决这个问题呢？首先为了简单，IndexedDB的操作我们只使用localforage.setItem()和localforage.getItem()，实际上除了这两个操作只剩下遍历所有数据了。
为了知道一个文件在IndexedDB中对应哪些数据，我们除了正常的file chunk，再额外存储一条数据，记录文件信息，包括所有的分片在IndexedDB中对应的数据的Key，其结构如下, 这条数据存储的Key可以考虑用文件ID、文件ID+MD5、下载任务ID等等，具体的还要结合业务需求进行选择。
const file_data = {
fileid: "replace-with-your-file-id",
filename: "test.pdf",
type: "application/pdf",
hash: "",
keys: [
"replace-with-your-file-id-0",
"replace-with-your-file-id-1",
"replace-with-your-file-id-2"
]
};
存储了这条额外的数据后，我们就可以根据文件ID或者任务ID等唯一Key从IndexedDB获取file_data，从而找到所有的file chunk。
根据这个思路，将分片下载的代码进一步调整如下
import qs from "qs";
import localforage from 'localforage';
import update from "immutability-helper";
export const download_chunks = (path: string, params: any, size: number) => {
const chunk_size = 1024 * 1024;
const chunks = Math.ceil(size / chunk_size);
const file_data = {
fileid: "replace-with-your-file-id",
filename: "test.pdf",
type: "application/pdf",
hash: "",
keys: new Array<string>()
};
const download_chunk = (current_chunk: number = 0, file_data: object, batch: number = 1000) => {
const start = chunk_size * current_chunk;
const end = ((start + chunk_size) >= size) ? (size - 1) : (start + chunk_size - 1);
const range = `bytes=${start}-${end}`;
console.log("download chunk:" + (current_chunk + 1), range);
const url = `/api/${path.indexOf("/") === 0 ? path.substring(1) : path}`;
if (params) {
path += `?${qs.stringify(params)}`;
}
const config = {
method: "GET",
headers: {
"token": sessionStorage.getItem("token") || "",
"Range": range
}
};
window.fetch(url, config).then((res: any) => res.blob()).then(
(res: any) => {
const file_chunk_key = `replace-with-your-file-id-${current_chunk}`;
localforage.setItem(file_chunk_key, res, () => {
file_data = update(file_data, { keys: { $push: [file_chunk_key] } });
localforage.setItem("task_id/file_id/md5", file_data);
batch--;
if (current_chunk < chunks - 1) {
if (batch > 0) {
download_chunk(current_chunk + 1, file_data, batch);
} else {
setTimeout(() => download_chunk(current_chunk + 1, file_data, 1000), 0);
}
}
});
}
).catch(reason => { console.error(reason) });
};
download_chunk(0, file_data, 1000);
};
调整后，先清空IndexedDB，再尝试下载，再观察IndexedDB中存储的内容，除了之前的9个分片数据，多出了一条数据，记录了文件的相关信息以及所有的file chunk key，后续就可以根据这些key查找具体的分片数据了。
image.png
1.5.6 断点续传（breakpoint transmission）
由于使用了分片下载，并且已下载成功的分片数据已经存储到了浏览器的IndexedDB，即使下载中断了，已下载的部分也不会丢失、不需要重新下载，带下次页面重新打开时，继续从未下载的分片开始下载即可。
不过既然有继续下载的概念，那么程序中必然要相应地增加一个下载任务的概念，并且任务有已完成、未完成、暂停、下载中等状态。因此，前文的用户记录文件信息的file_data可能也要做一些调整。
此外，下载中断后，服务器上的文件可能已经发生了变更，如果不管三七二十一，无视这个变化就直接继续下载，得到的文件很可能因为二进制数据错乱导致文件无法正常使用。所以继续下载前，获取文件的md5值与前次的进行比较，如果一致才继续下载，如果不一致就清空已下载的数据并重新下载。
1.5.7 细节处理
优化完IndexedDB相关的操作后，还有些细节内容没有完成，如果想要给用户完美的体验，这些问题还是需要解决的。
- 下载提示
下载完成后，界面上需要给出提示，自动弹出下载完成窗口，提示用户下一步操作。 - Indexed数据清理
也可以说成“缓存清理”，在合适的时机清除文件所有数据，可以结合业务需要处理，下载一次后清理，还是一定时间后清理都可以考虑。
1.5.8 下载进度 progress
同样的，由于是分片下载，每下载完成一个分片后，就可以方便地计算得到已下载的部分占文件总体积的比例，下载进度同样需要按下载任务记录到IndexedDB，并且页面上要提供相应的UI展示。
当然，由于分片一般会固定大小，当文件本身比较小时，下载进度渐进的幅度就会比较大（例如文件大小为4M，分片大小为1M，下载进度只会按0% -> 25% -> 75 -> 100%变化），甚至当文件体积比分片大小还小时，下载进度只会直接从0%到100%变化了。如果为了下载进度看起来更合理，特地根据文件大小动态调整分片大小也可以考虑，但分片分得太小也是不合适的。
2.文件上传
文件上传相对于文件下载，是一个逆向的过程。结合文件下载的经验，如果要实现分片上传文件，并且支持断点续传，那么真正地开始上传动作前，将文件分割存储到IndexedDB中，就成了比较容易想到的思路。
2.1 服务端实现
参考阿里云OSS的分片上传,服务端逻辑分为三步：
- 1.初始化分片上传事件
初始化的目的主要是为了先确定将要上传的文件，并得到一个唯一标识，后续上传分片时，都需要携带这个标识，这样才能判断上传的分片属于哪个文件。 - 2.上传分片
按照约定的分片大小，将一个体积较大的文件，按照确定的分片大小分批将整个文件上传完毕。 - 3.完成分片上传
待所有的分片上传完成后，发送“通知”，将之前上传的分片组装成一个完整的文件。
2.2 客户端实现
2.2.1 初始化 & 完成
照理说，客户端实现应该与服务端一致，首先要进行初始化请求，同时上传完毕后应再发送一个请求告诉服务端上传完成，通知服务端将将之前上传的分片合并成一个完整的文件。但为了简化操作，服务端可以自行检查，如果某个文件首次上传分片，就进行初始化操作，如果是最后一次上传分片，则将这些分片合并，同时删除这些分片。
2.2.2 文件分割
分割文件时，首先从前端页面获取到要上传的File对象，由于File(interface File extends Blob {})继承了Blob，使用Blob的slice(start, end, contentType)方法按照与服务端约定的chunk size对此文件进行分割。需要注意的是，这里的[start, end)计算范围时使用的是前闭后开的规则，http request header中的Range有所差异。
const blob = new Blob([file], { type: file.type });
2.2.3 文件分片存储到IndexedDB
分片内容存储到IndexedDB的过程与下载文件分片后的操作基本一致，这里不多赘述，文章的最后会放出代码仓库链接。
2.2.4 记录文件上传任务到IndexedDB
同样的，为了知道一个文件被分成了多少块存储在IndexedDB中，我们采用的思路依然是额外存储一条上传文件相关的记录，其中chunks字段记录了这个文件被分割成了哪些块，每一块在IndexedDB中对应的key，以及块的序号、大小、是否已经上传等信息。
2.2.5 从IndexedDB获取文件分片发送至服务端
在所有的文件块在IndexedDB中存储完毕后，接下来就需要将这些文件发送到服务器端。客户端上传分片时，需要传递分片序号，以便服务端按照正确的顺序组装文件。
每上传完成一块后，需要在额外记录文件上传数据的那条记录中更新状态，标记标记哪些块已经上传完成了。一方面方便计算文件上传进度，另外还能在上传任务中断后，下次恢复上传时不至于重新上传之前已经上传过的文件块，只需要继续上传还未上传的部分即可。
2.2.6 上传完成，清理数据
上传完成后，一般不需要考虑特别的场景，将IndexedDB中存储的文件数据清除就行。至于上传任务那条记录，是否要一并删除，问题都不大，页面做好相应的交互及提示，给用户完整的体验就可以。
3.代码实现
后续在编写代码的过程中，重新梳理了思路，尤其在IndexedDB存储上改进了原先的设计，将上传记录、下载记录、文件块分别用一个store存储。
import localforage from "localforage";
export const db_upload = localforage.createInstance({ name: "myapp", storeName: "upload" });
export const db_download = localforage.createInstance({ name: "myapp", storeName: "download" });
export const db_chunk = localforage.createInstance({ name: "myapp", storeName: "chunk" });
其中upload和download中存储的数据结构也进行了改进，
export interface FileData {
id?: string;
hash: string;
name: string;
type: string;
size: number;
chunks: FileChunk[]; // file chunks stored in IndexedDB
};
export interface FileChunk {
index: number;
key: string;
size: number;
uploaded?: boolean;
}
这样上传记录和下载记录直接遍历upload和download这两个store即可，每个记录相关的chunk，则从chunks字段获取，上传记录的chunk还额外多了一个uploaded字段，表示该分片是否已经上传。
结合上面关于上传和下载的过程和思路分析，这里以上传上传文件到服务端本地为例，提供了完整的前后端代码，供参考。实际项目中需要结合业务场景，将本地存储替换为OSS或其它存储。
Github - file-upload-and-download-example
但是，有一些细节处理是没有实现的，代码中标记了TODO，比如：
- 检查分片是否已经上传过，如果已经上传了则忽略；
- 根据文件md5检查文件是否已经存在，如果存在直接进行链接，无需上传（有些地方将这种做法叫做秒传）；
- ...
最后附上两张界面截图
upload
download
网友评论