项目标题拿到的第一反应就是“这又是一个在真实生产环境里把人逼到墙角的问题”。能源化工行业的生产监控视频不是你在办公室用Wi-Fi传个电影那么简单。厂区监控点位分散车间和机房之间隔着好几条管线走廊光纤链路动不动就被施工挖断车间里的Wi-Fi在金属罐区衰减得惨不忍睹更别说还有等保、内控审计对传输加密的硬性要求。把动辄1GB以上的监控录像从现场传到调度中心网络一抖就前功尽弃这种痛感没做过工业信息化项目的人很难体会。我做的方案核心就一件事用JS改造WebUploader这个老牌上传组件给它加上加密分片上传和断点续传能力。WebUploader是百度FEX团队开源的组件虽然官方停更了很久但企业内网上大量系统早就在用它API稳定、队列和进度管理成熟与其推倒重来不如在它身上做外科手术。下面这篇文章就完整记录我改造的思路、关键代码和踩过的坑给同样在工业场景里和“大文件烂网络”死磕的朋友一点参考。1. 项目背景与需求拆解1.1 能源化工场景下的上传难点能源化工行业的监控视频和互联网行业的上传需求差距非常大我觉得先得把这些差异摊开看不然做出来的方案就是空中楼阁。第一是文件体积大得离谱。普通办公室传个PPT几十MB已经嫌大了生产监控录像可是按小时分段的。以一台1080P摄像头为例码率做到2Mbps一小时录像就是900MB厂区关键装置区通常开4Mbps甚至更高码率一个小时视频段轻松超过1.5GB。即便按30分钟一段切分单文件也有400~700MB。这种文件用普通的FormData整体上传网络稍微波动就是“至暗时刻”。第二是网络环境不可控。厂区里的光纤链路经常因为施工、动物啃咬、弯折过度而断续车间内部的无线桥接在大型金属储罐附近信号衰减非常严重调度中心和厂区之间的网络还可能跨多个子网、过防火墙。我遇到过一条链路的丢包率在高峰时段接近3%这种环境下传大文件断线是常态而不是异常。第三是安全合规不能妥协。监控视频涉及生产安全、安防布防甚至人员行为明文HTTP传输在等保评审和内部审计阶段根本过不了。要求是传输过程必须加密而且最好能做到分片级别的加密这样即使某个分片在网络中被截获也无法还原有效内容。第四是前端运行环境老旧。厂站控制室里的PC很多还是Win7、Win10老版本浏览器停留在Chrome 40甚至IE11。市面上的现代上传方案虽然好用但兼容性直接劝退。WebUploader正是这种环境下的老朋友虽然它的传输层不满足我们的安全要求但壳子文件选择、队列、进度、状态管理是真能用。1.2 为什么选WebUploader而不是新方案很多朋友听到“改造WebUploader”第一反应是都2020年代了为什么不用现成的分片上传库或者云厂商的SDK原因很现实。一是系统里已经跑着基于WebUploader的旧逻辑改造成本最低的路径就是保留壳、替换传输层二是WebUploader的分片机制、队列管理、进度回调都已经验证过多年稳定性有保证三是很多能源化工项目在部署时不能随便引入依赖一堆云服务的SDK。我自己也试过用axios重新搭一套上传体系最后发现要处理的事情比想象中多太多——文件选取、并发控制、队列顺序、失败重试、进度计算全得自己写。而WebUploader把这些都给我准备好了我只需要干掉它的默认请求换成“自定义加密分片请求”。所以本次改造的核心思路不是推翻重来而是让WebUploader只负责它擅长的文件选择、文件元数据管理、进度事件。真正干活的加密、续传、状态同步全部由我写的JS函数接管。2. 加密续传的总体设计2.1 分片上传的本质分片上传的原理其实不复杂把大文件按固定大小切成N块每块独立上传服务端收到所有分片后按顺序合并。这样做的好处一是上传单元小了网络抖动时只需要重传失败的那一片不用整个文件重来二是可以并发上传利用带宽三是在弱网环境下进度是平滑增长的不会一直卡在某个百分比不动。断点续传则是分片上传的必然延伸。既然文件被切成块那么只要服务端记录了“哪些块已经成功收到”前端在下次上传时就可以跳过这些块只传缺失的块最后再触发合并。这里的核心是“状态一致性”服务端记录的已传分片必须和前端即将上传的分片一一对应否则合并出的文件会坏。2.2 加密放在哪一层加密策略我选择了“先切片、再分片加密”。注意千万不要先对整个文件加密再切片。如果先整体加密你会得到一个无法随机读取的密文流切片后每一片都无法独立解密断点续传和分片校验都无从谈起。正确的流程是前端计算整个文件的MD5用作文件指纹。按固定大小切片比如每片5MB。对每个分片单独做AES加密实际是每个分片的原始字节 - AES-CBC加密。上传加密后的分片二进制同时携带分片索引和文件MD5。服务端收到某个分片后用协商好的密钥解密将原文写入磁盘临时文件。所有分片传齐后服务端按索引顺序合并并校验合并后文件的MD5是否等于前端上报的MD5。这样即使某个密文分片在半路被截获攻击者也拿不到有效视频数据。同时由于每个分片独立加密续传时可以只传缺失分片完全不影响加密体系。有朋友可能会问AES密钥放在前端不就等于没有加密吗确实前端密钥的安全性有限它只能防止弱网链路上的被动窃听防不了恶意用户逆向。但在能源化工场景里我们真正要防的是“数据在网络传输过程中被旁路抓包”而不是防本厂员工。所以可行的做法是上传前通过服务器的登录会话接口获取一个临时密钥前端只在内存中保存不落盘。如果要更严格可以走HTTPS 密钥协商但内网项目做到“会话密钥 分片密文”已经能满足多数审计要求了。2.3 断点续传的状态记录断点续传要想做到位服务端必须提供两个配套接口状态查询接口根据文件的MD5返回该文件已经成功收到的分片索引集合。分片上传接口接收一个分片校验后落盘并记录索引。前端在上传前先请求状态接口如果返回已存在部分分片就跳过这些分片只上传缺失的。这里有个关键点续传必须保证分片大小和总片数没有变化。如果前端修改了分片大小比如从5MB改成10MB那同样的分片索引对应的字节范围就变了服务端之前存的5MB分片就全部失效。所以我在状态查询时会让服务端同时返回“分片大小、总片数、上次上传时间”前端判断这三个参数都一致才走续传否则清空已传分片重新传。2.4 为什么用MD5而不是文件大小文件大小这种指纹太弱。视频文件经常有转码重封装的场景同一个监控视频可能通过不同工具导出的文件大小完全相同但内容顺序完全不同。只用大小做指纹一旦两个不同的文件在主键上碰撞服务端的临时目录就会混乱合并出来的视频花屏、时间轴断裂排查起来非常痛苦。用MD5之后还能顺手实现“秒传”效果如果同一个文件之前已经完整上传过状态接口返回“已全部接收”前端压根不需要再传分片直接调用合并接口服务端根据已有的分片合并一份新副本即可。我在实际项目里发现厂区早晚高峰视频文件高度相似秒传命中率还挺高大大减轻了网络压力。3. 核心实现改造WebUploader支持加密分片与续传3.1 技术选型与依赖我最终使用的依赖也就四个webuploader1.x版本即可主要用它的UI和队列jQueryWebUploader的依赖老项目里通常已经有了crypto-js用于AES加密spark-md5用于增量计算大文件的MD5如果要兼容老浏览器还需要babel来转译ES6语法。不过我建议只在支持HTML5的浏览器上启用禁用Flash fallback。能源化工项目里不可能为了Flash去装插件这既安全又省心。3.2 WebUploader当“壳”自定义传输层接管上传这是整个改造最核心的设计决策。WebUploader默认的上传逻辑是把分片Blob直接作为multipart字段发送到server配置的地址。我们不能用这个默认逻辑因为那里没法插入“加密分片”这一步。我的做法是初始化WebUploader时不配置server或者配置一个占位地址但永远不会真正让它发请求。通过监听filesAdded拿到文件列表然后调用自己写的uploadFileWithEncryption(file)函数。在这个函数里自己决定什么时候切片、怎么加密、怎么上传。上传过程中通过uploader.trigger(file, uploadProgress, percent)把进度反馈给组件。全部完成后触发uploadSuccess任何失败触发uploadError或uploadFailure。这样WebUploader成了一个纯粹的文件选择器和进度展示框传输细节由自己掌控。看起来绕了一圈但实际上最稳定因为不涉及对WebUploader源码的深度hack升级或排查问题都容易。3.3 分片、加密、续传的关键代码先看初始化部分var uploader WebUploader.create({ pick: { id: #picker, multiple: false }, accept: { title: 视频文件, extensions: mp4,avi,flv,mkv,wmv, mimeTypes: video/* }, // server不设真实地址因为由我们自定义传输 swf: webuploader/Uploader.swf, auto: false, disableGlobalDnd: true, dnd: #dndArea });accept里的扩展名按实际需要配。注意监控导出的文件可能是.dat或私有格式这种情况下得在服务端做白名单前端不能只靠扩展名封死。filesAdded事件后启动自定义上传uploader.on(filesAdded, function(files) { var file files[0]; // file.source 是WebUploader内部的File对象也就是原始浏览器File startEncryptedUpload(file); });startEncryptedUpload函数里我分成三步走。第一步计算整个文件的MD5并查询服务端的续传状态。function calcMD5(file) { return new Promise(function(resolve, reject) { var blobSlice File.prototype.slice || File.prototype.mozSlice || File.prototype.webkitSlice; var chunkSize 8 * 1024 * 1024; var spark new SparkMD5.ArrayBuffer(); var reader new FileReader(); var current 0; var total Math.ceil(file.size / chunkSize); reader.onload function(e) { spark.append(e.target.result); current; if (current total) { loadNext(); } else { resolve(spark.end()); } }; reader.onerror reject; function loadNext() { var start current * chunkSize; var end Math.min(start chunkSize, file.size); reader.readAsArrayBuffer(blobSlice.call(file, start, end)); } loadNext(); }); } function getUploadedChunks(md5) { return $.ajax({ url: /api/video/upload/status, method: GET, data: { md5: md5 } }); }注意这里用FileReader而不是file.arrayBuffer()就是为了兼容IE11和老的Edge。SparkMD5增量计算避免一口气读入几个GB的内存这是大文件计算指纹的基本操作。第二步切片并加密每个分片。这里要处理ArrayBuffer、WordArray和Blob的来回转换。CryptoJS直接加密的是WordArray而我们要操作的是二进制数据最容易踩的坑就是字节序和填充。function arrayBufferToWordArray(ab) { var uint8 new Uint8Array(ab); var words new Array(Math.ceil(uint8.length / 4)); for (var i 0; i words.length; i) { words[i] (uint8[i * 4] 24) | (uint8[i * 4 1] 16) | (uint8[i * 4 2] 8) | uint8[i * 4 3]; } return CryptoJS.lib.WordArray.create(words, uint8.length); } function wordArrayToBlob(wordArray) { var len wordArray.sigBytes; var uint8 new Uint8Array(len); var words wordArray.words; for (var i 0; i len; i) { uint8[i] (words[i 2] (24 - (i % 4) * 8)) 0xff; } return new Blob([uint8]); }加密分片function encryptChunk(arrayBuffer, sessionKey) { var plainWordArray arrayBufferToWordArray(arrayBuffer); var key CryptoJS.enc.Hex.parse(sessionKey); // iv可以使用文件md5的前16字节做种子但生产环境更建议每次会话生成 var iv CryptoJS.lib.WordArray.create([0x00000000, 0x00000000, 0x00000000, 0x00000000]); var encrypted CryptoJS.AES.encrypt(plainWordArray, key, { iv: iv, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }); return encrypted.ciphertext; // WordArray }这里要特别说明IV如果全部置0在同一个密钥下相同明文分片会得到相同密文存在泄露模式的风险。实际项目里我会用“文件MD5取前16字节Hex 分片索引构造block”来生成动态IV。但CryptoJS的IV要求是16字节WordArray我通常会写成这样的工具函数function makeIv(md5, chunkIndex) { var hex md5.substr(0, 16) padStart(chunkIndex.toString(16), 16, 0); return CryptoJS.enc.Hex.parse(hex); }第三步上传加密分片并处理重试和进度。function uploadChunk(file, md5, chunkIndex, chunkTotal, sessionKey) { return new Promise(function(resolve, reject) { var chunkSize 5 * 1024 * 1024; var start chunkIndex * chunkSize; var end Math.min(start chunkSize, file.size); var blob file.source.slice(start, end); var reader new FileReader(); reader.onload function(e) { var plainBuffer e.target.result; var encryptedWordArray encryptChunk(plainBuffer, sessionKey); var encryptedBlob wordArrayToBlob(encryptedWordArray); var fd new FormData(); fd.append(md5, md5); fd.append(chunkIndex, chunkIndex); fd.append(chunkTotal, chunkTotal); fd.append(originalSize, end - start); fd.append(file, encryptedBlob, chunk_ chunkIndex .enc); var xhr new XMLHttpRequest(); xhr.open(POST, /api/video/upload/chunk); xhr.timeout 120000; // 2分钟超时 xhr.onload function() { if (xhr.status 200) { resolve(xhr.responseText); } else { reject(new Error(HTTP xhr.status)); } }; xhr.onerror function() { reject(new Error(network error)); }; xhr.ontimeout function() { reject(new Error(timeout)); }; xhr.send(fd); }; reader.onerror function() { reject(new Error(file read error)); }; reader.readAsArrayBuffer(blob); }); }这里的关键逻辑是用FileReader先读分片然后加密然后把加密后的Blob放进FormData。注意FormData里的file字段名服务端就按这个字段去接。同时携带md5、chunkIndex等元数据服务端才能定位这个分片属于哪个文件。uploadFileWithEncryption函数的整体流程我放在一个async函数里async function startEncryptedUpload(file) { var md5 await calcMD5(file); var sessionKey await fetchSessionKey(); // 从登录会话获取AES密钥 var statusRes await getUploadedChunks(md5); var uploaded statusRes.data.uploadedIndexes || []; var chunkSize 5 * 1024 * 1024; var chunkTotal Math.ceil(file.size / chunkSize); // 如果全部已传直接合并 if (uploaded.length chunkTotal) { await mergeFile(md5, chunkTotal); uploader.trigger(uploadSuccess, file); return; } var failedChunks []; for (var i 0; i chunkTotal; i) { if (uploaded.indexOf(i) 0) { continue; } var success false; for (var attempt 0; attempt 3 !success; attempt) { try { await uploadChunk(file, md5, i, chunkTotal, sessionKey); success true; } catch (e) { failedChunks.push({ index: i, attempt: attempt 1, error: e.message }); if (attempt 2) { uploader.trigger(uploadError, file, new Error(分片 i 超过重试次数)); uploader.stop(true); return; } // 等待1秒、2秒、3秒退避 await sleep((attempt 1) * 1000); } } var percent Math.round((i 1) / chunkTotal * 100); uploader.trigger(uploadProgress, file, percent); } var mergeRes await mergeFile(md5, chunkTotal); uploader.trigger(uploadSuccess, file, mergeRes); }这段代码把重试逻辑写死了最多重试3次、1秒退避。真实生产我建议做成可配置项弱网环境下可以把重试次数提到5次左右间隔指数递增到10秒。3.4 进度与错误处理既然接管了传输层WebUploader的进度条就不会自动更新了必须手动把进度trigger给它。uploader.trigger(uploadProgress, file, percent);注意percent是0~100的整数。WebUploader内部会根据这个值刷新UI。如果某个分片因为网络失败被重传进度条可能会回跳这是正常的用户看到进度整体向前就能接受。另外WebUploader本身有个uploadProgress事件我们可以监听它来做全局的进度展示uploader.on(uploadProgress, function(file, percentage) { $(#progress- file.id).text(Math.round(percentage) %); });错误处理上我建议在自定义上传函数里使用单独的错误事件名比如customUploadError避免和WebUploader的uploadError混淆。UI上要明确告诉你“哪个分片失败了正在第几次重试”而不是笼统一句“上传失败”。3.5 服务端配套接口设计前端改造完成服务端也得跟上。这里我用Node.jsExpress做了个简单的参考实现但换成Java、Go、Python同理。分片接收接口const express require(express); const multer require(multer); const fs require(fs); const path require(path); const crypto require(crypto); const UPLOAD_DIR /data/production_videos/tmp; const SESSION_KEY process.env.VIDEO_UPLOAD_KEY; // 部署时注入 const upload multer({ limits: { fileSize: 6 * 1024 * 1024 } }); app.post(/api/video/upload/chunk, upload.single(file), (req, res) { const { md5, chunkIndex, chunkTotal, originalSize } req.body; const chunkIndexInt parseInt(chunkIndex); const chunkDir path.join(UPLOAD_DIR, md5); if (!fs.existsSync(chunkDir)) { fs.mkdirSync(chunkDir, { recursive: true }); } // 解密分片 const encryptedBuffer fs.readFileSync(req.file.path); const decipher crypto.createDecipheriv(aes-256-cbc, Buffer.from(SESSION_KEY, hex), Buffer.from(md5.substr(0, 32), hex).subarray(0, 16)); const decrypted Buffer.concat([decipher.update(encryptedBuffer), decipher.final()]); // 校验长度 if (decrypted.length ! parseInt(originalSize)) { fs.unlinkSync(req.file.path); return res.status(400).json({ code: 1, msg: 分片解密后长度不符 }); } // 写入分片文件 const partFile path.join(chunkDir, ${chunkIndexInt}.part); fs.writeFileSync(partFile, decrypted); fs.unlinkSync(req.file.path); // 记录状态 const stateFile path.join(chunkDir, state.json); let state { md5, chunkSize: 5 * 1024 * 1024, total: parseInt(chunkTotal), done: [] }; if (fs.existsSync(stateFile)) { state JSON.parse(fs.readFileSync(stateFile, utf-8)); } if (!state.done.includes(chunkIndexInt)) { state.done.push(chunkIndexInt); } fs.writeFileSync(stateFile, JSON.stringify(state)); res.json({ code: 0, data: { chunkIndex: chunkIndexInt } }); });状态查询接口app.get(/api/video/upload/status, (req, res) { const md5 req.query.md5; const stateFile path.join(UPLOAD_DIR, md5, state.json); if (!fs.existsSync(stateFile)) { return res.json({ code: 0, data: { uploadedIndexes: [] } }); } const state JSON.parse(fs.readFileSync(stateFile, utf-8)); res.json({ code: 0, data: { uploadedIndexes: state.done, chunkSize: state.chunkSize, total: state.total } }); });合并接口app.post(/api/video/upload/merge, (req, res) { const { md5, chunkTotal } req.body; const chunkDir path.join(UPLOAD_DIR, md5); const stateFile path.join(chunkDir, state.json); if (!fs.existsSync(stateFile)) { return res.status(400).json({ code: 1, msg: 状态不存在 }); } const state JSON.parse(fs.readFileSync(stateFile, utf-8)); if (state.done.length ! chunkTotal) { return res.status(400).json({ code: 2, msg: 分片不全当前${state.done.length}/${chunkTotal} }); } const filePath path.join(UPLOAD_DIR, md5, ${md5}.mp4); const writeStream fs.createWriteStream(filePath); for (let i 0; i chunkTotal; i) { const partFile path.join(chunkDir, ${i}.part); if (!fs.existsSync(partFile)) { return res.status(400).json({ code: 3, msg: 缺少分片${i} }); } const data fs.readFileSync(partFile); writeStream.write(data); } writeStream.end(); // 这里应该校验合并后的MD5如果与服务端记录的MD5不一致则回滚下次重新上传 res.json({ code: 0, data: { url: /video/${md5}.mp4 } }); });服务端还有个重要工作定时清理临时目录。如果某个文件传了一半就再也不传了几GB的临时分片会一直占着磁盘时间长了能把磁盘写满。我在项目里写了个定时任务每天凌晨扫描所有state.json的更新时间超过48小时未更新的目录直接删除。4. 生产环境下的优化与坑4.1 分片大小和并发数的取舍分片大小我建议设为5MB左右。太小比如1MB会导致请求数量剧增一个1GB文件要发1000多个请求服务端的日志、握手开销、网络往返都在拖后腿太大比如32MB一旦网络抖动单个分片重传成本很高。5MB是一个比较均衡的值。并发数方面我实测在厂区普通2Mbps上行链路上3个并发就已经能把带宽跑满再多并发反而会引起TCP竞争导致每个请求都超时。如果现场网络更弱建议降到2。不要迷信“并发越高越好”工业内网和运营商宽带不一样瓶颈往往在链路本身。4.2 弱网断线重试与断电续传弱网环境下的核心诉求是“不能因为一次网络抖动就把整个上传打死”。前端要针对每个分片独立重试重试次数和退避策略要可调。我用的退避策略是第1次失败后等1秒第2次等3秒第3次等7秒指数增长。如果连续失败超过5次才判定这条链路有问题提示用户检查网络。断电续传的体验是用户在A车间上传了500MB断电了等网络恢复后再次选择同一个视频文件前端计算MD5后命中服务端状态记录直接跳过已传分片只传剩下的部分。这个体验的关键在于状态查询必须在分片上传之前完成而且分片大小和总数必须校验否则续传出来的文件必坏。4.3 MD5计算优化大文件计算MD5是个耗时操作。1GB文件用SparkMD5增量计算在老PC上可能要几十秒。用户选择文件后界面不能卡死我用了一个小trick先读取文件头部、中部、尾部几个64KB片段用分块取样的“快速指纹”快速判断“大概率是同一文件”命中后再做完整MD5。不过这只是工程上的优化安全校验最终还是以完整MD5为准。如果不追求秒传直接全量算MD5也能接受只是要在UI上显示“正在校验文件完整性”的进度。4.4 老浏览器兼容能源化工现场的老机器和老浏览器是绕不开的。WebUploader的HTML5模式在Chrome 40能用但FileReader的readAsArrayBuffer没问题注意不要用Blob.arrayBuffer()这种较新的API。CryptoJS和SparkMD5都是纯JS兼容性没问题。ES6的async/await在IE11下不能用我在生产环境用babel转译成ES5或者干脆用Promise和generator的写法。另外WebUploader依赖jQuery建议用1.12版本避免jQuery 3.x在IE上的坑。5. 常见问题与排查实录5.1 常见问题速查表症状可能原因排查与解决上传一直停在0%Nginxclient_max_body_size太小或者自定义XHR被跨域拦了检查Nginx配置放行client_max_body_size 100m;跨域需要服务端加CORS头断点续传到了99%后报错某一分片被跳过但服务端其实没收到前端状态判断和数据不符核对state里的done数组与分片请求是否一一对应前端续传时打印每个分片的索引看是否越过缺失分片解密后文件播放花屏AES的IV或密钥不一致或者合并顺序乱检查前后端密钥生成逻辑分片合并时用chunkIndex排序不要用文件名排序上传成功但合并出来的视频比原文件大或小服务端把PKCS7填充也算进去了解密后必须去掉paddingCryptoJS的decrypt会自动处理但服务端用Node的crypto时要用autoPadding: true同时校验原始大小同一个文件换台电脑无法续传状态查询接口只以MD5为主键但不同电脑生成的MD5不一致计算错误确保MD5计算基于文件完整二进制不要用file.name或其他元数据参与计算上传到一半页面刷新重选文件后显示“文件不存在”服务端临时目录被定时清理了延长清理周期或者在上传过程中心跳续期state文件的更新时间IE时代浏览器下卡死使用了Promise.finally或async/await但没转译统一用babel-polyfill或者换ES5写法5.2 实战中的一些心得这套方案我在线上跑了大半年最大的体会是加密本身其实不难难的是把加密和续传的边界理清楚。有一次测试人员在弱网环境下连续断电恢复后上传进度从100%跳到“正在合并”合并完成后视频却是坏的。后来查下来问题出在服务端合并时用了文件名排序而文件名是1.part、10.part、2.part这样的字符串字典序成了1,10,2最终合并顺序全乱了。把合并逻辑改成按数字索引排序之后就正常了。这种细节只靠看代码很难发现必须在真实弱网环境里反复断电断网测试。另一个心得是前端千万不要把密钥写死在JS里哪怕你加了混淆也经不起逆向。我给客户演示的时候他们安全部门直接扔了个抓包工具给我看到密钥在请求里出现过一次立刻打回。后来改成登录后从接口临时获取内存中保存请求期间不再传输密钥才过了审计。最后再分享一个小技巧状态接口一定要返回chunkSize和total前端续传前严格比对这些参数否则版本升级时改了分片大小老版本没传完的文件会和新版本的分片对不上轻则重新上传重则服务端把不同版本的分片混在一起合并视频直接损坏。加上这个校验后我再也没遇到过“续传续出坏文件”的投诉。