首页 > 安全资讯 >

NodeJs实现可续传的上传协议(tus resumable upload protocol)

13-05-31

这是一个基于http的可续传的协议,主要是不同的HttpMethod和相关的自定义header来实现续传功能。具体的Method和header介绍:1、HEADhead请求是获取文件已上传的状态,服务端返回该文件哪些范围已写入,哪些没写入...

这是一个基于http的可续传的协议,主要是不同的HttpMethod和相关的自定义header来实现续传功能。
具体的Method和header介绍:
1、HEAD
head请求是获取文件已上传的状态,服务端返回该文件哪些范围已写入,哪些没写入。
(PS,我刚发现协议已经变了,以前不是offset)
但是我这个实现和tus也略有不同,我支持一个文件可以多线程同时上传,所以不能完全追寻他的协议。
客户端接收到的header例子:
range:bytes=0-9,20-29
意思表名0-9和20-29这俩个块已被写入,所以续传的时候不需要上传了。
如果接收到的是 range:bytes=0-1023(假如文件就1024长度,那么说明文件已上传完毕)

2、POST
post请求是用于创建文件,header里必须要有声明文件的大小,例如
content-range:*/1023 这说明文件的大小是1024。

 3、PUT
put请求是上传文件用的,如果想实现续传,那么就要把文件拆分为N个小块,按块上传,这样如果断掉,下次可以通过HEAD请求看到哪些块已经上传。

4、GET
get请求就是下载文件,这里不必多说了。

协议大致如此,只是相对于tus原本的协议有所变化(可以多块同时上传,所以并非是顺序上传,在Head请求的返回自然有所变化)。

协议实现思路:
客户端分块上传,服务端接收到每个块之后存储到服务端。如何记住哪些块被上传了呢?
我的实现思路是需要一个metadata的辅助元数据文件来记住这个文件的上传状态、文件大小、文件原名称等等。
现在是用文件存储的metadata,这只是一个demo,如果是真正使用,我想用数据库更合适一些。

我走的弯路:
第一次:
如何实现块能够写入到目标文件里?这个问题也和以前的同事交流过,当时没有找到解决办法。除非顺序写入然后用append的模式。
但是客户端上传确实多线程非顺序上传,服务端该如何保证顺序?
最后的解决办法是把客户端上传的每一个块保存为单个小文件,每次上传完一个块之后判断是不是所有的块上传完毕,如果上传完毕做一次合并。

判断文件块是否写完,我就要遍历每一个小文件,判断他们是否连续。由于nodejs的文件操作需要异步,所以实现起来需要写各种递归,异常痛苦,大家可以看我的GitHub提交的历史版本,最老的版本里面有很多递归。代码非常丑陋,而且难以维护。

第二次:
为了减少递归,我使用global全局缓存,而且限定了文件上传的块的大小必须一样,每上传完一个块,我就把他存储到global缓存里。这样就不需要遍历小文件,减少了很多异步操作,代码清晰了很多。

第三次:
小文件合并的方案虽然可行,但毕竟感觉有些愚蠢,如果是特别大的文件,那可以想象合并和遍历都很慢,管理也不方便。所以如果能解决Nodejs的按offset写入stream的问题就可以解决。我又翻了下Nodejs的文档,发现以前使用的都是w和w+的打开方式,这种打开方式会清空文件的内容,而r和r+不会。
于是我尝试着修改了代码,由于是并发写入,实际上文件写入是不能并发的,所以需要加锁,当块写入的时候判断是否锁住就可以了。
这一下去掉了好多的代码,代码更加的清晰明亮起来。


为什么用NodeJS? 因为这是一个面试题的作业,所以必须用Nodejs。
我在FileMetadata初始化是依然用的fs.readSync,我以前同事告诉我nodejs不可以使用sync方法,这样会hold住整个进程。这实在是太恐怖了。
所以我个人觉得nodejs的弊端也很明显,对代码复杂度的增加显而易见。 至于Javascript的非阻塞的先天优势,其他的语言也可以做到。那为什么还用Nodejs呢?而且Javascript的语法比较弱,很多实现都比较困难。我对nodejs没有太多好感。

 

相关文章
最新文章
热点推荐