大文件上传进度条思路

本文探讨了大文件上传时面临的挑战,包括文件大小限制和进度条显示问题。传统的文件上传方式可能导致响应延迟,而通过前后端配合,可以实现大文件的分块上传和实时进度反馈。文件拆分策略、续传功能以及前端进度条与后台处理的同步是关键。同时,提到使用MD5校验和确保文件完整性。解决方案包括使用Websocket进行同步通信,确保前端进度条与后台处理进度一致,提供更好的用户体验。
摘要由CSDN通过智能技术生成

       和同事谈论这个话题         

        现在很多前端插件都提供文件上传的功能,但是很少有需要后端配合的,这样就造成文件上传的大小有限(比如限制只能上传100M以下的文件),否则会发生很多乱七八糟的问题(具体就不记了,用过的都懂)。

        一般而言上传文件的思路就是先上传到浏览器缓存,再从缓存提交到后台,后台收到全部的数据,做好处理返回成功或者失败,前台再反馈给用户相应的信息。

但是有的时候,你不能限制用户上传的文件的大小,比如很多重要的图像文件,或者镜像文件都是几个G的大小,这时候我们需要前后端配合来解决这个问题,比如先把文件拆成很多小块,分几次传输给后台,编码再传输,有点像大学网络课讲到的TCP传输字节那种先拆再整合(是TCP吧?时间太久,记不太清楚了,总之是这种思路),常打大型游戏的盗版玩家也曾用过MD5类似的东西(同事做法就是参考的MD5的思路)。文件到底拆不拆,拆分成多大,这个很难确定一个界限,太小的肯定不拆,要不然程序复杂度提升太多,文件比较大的时候拆分,要考虑上传文件的用户总的响应时间,对用户的反馈可能造成不及时的问题(通常就是文件上传的进度条问题)

文件上传的进度条的问题

        我第一次遇到这个问题,是大学毕业刚入行的时候,让我写几个简单页面,然后就遇到这个问题,不会写怎么办?造个假的,文件慢慢上传,但是进度条匀速到90%就不动了,如果文件上传成功,就从90%稍快移动到100%,失败就告诉用户上传失败了。同事大笑,并表示他们也有过这种经历,甚至现在赶项目比较紧急还会再使用暂时度过一下难关,果然偷懒的思路都是相同的

        要解决这个问题,还是上面所说的,前后端配合问题,

        a》文件个数代表进度条进度(多文件的时候)

        b》与 (a) 配合,再加上文件大小这一条件

        c》将文件拆分成大小差不多相同的小块,以小块数量作为进度条进度(这个是同事采用的方法)

这里对小块进行标号,还可以实现续传的功能

上述还可能出现很多问题,如:

       前端进度条与后台的关系,前台上传很慢,后台处理速度很快,或者已经上传到浏览器缓存了,后台还没来得及处理,进度条的进度怎么处理,怎么向用户实时展示?这里可以使用weblogic进行同步。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值