给产品经理讲技术|断点续传的奥义

如果你和果果一样是个重度的Chrome用户,那么你一定有过这样的糟糕体验:在Chrome中下载一个文件,下载还未完成时(也许进度已经99%)突然告诉你下载失败了,然后点击重试,傻傻的Chrome竟然不支持断点续传,而是从头开始重新下载这个文件。

后来果果经过一番调查,发现其实Chrome是自带了断点续传掉功能的,只是默认是关闭的,在chrome://flags中有个选项,可以将其打开。再仔细想想,也是合理的,美帝的网速太快了,他们平时也用不着这功能,就默认关闭了。

产品经理

不过果果作为天朝的无证程序员,觉得还是有必要给各位无证产品经理介绍一下断点续传的原理。

首先我们来看下HTTP Header中的两个特殊字段,一个在请求头中叫Range,表示本次请求要求服务器返回的数据范围,另一个在响应头中,是Content-Range,表示本次服务器返回的数据范围。

来看个栗子,我在下载一个文件,有2048B大小,当我收到1024B数据时,由于某种不可预知的原因中断了,这时我只想把剩下没下完的数据拉回来,那么我在请求头面会这样写Range: bytes=1024-,表示我要从1024B开始拉取后面的数据,究竟还剩下有多少数据我也不知道,所以有个“-”单独在那里。然后服务器在响应里面会这样写Content-Range:bytes 1024-/2048,这个表示返回了从1024B到文件结尾的全部数据,同时告诉了我这个文件总共2048B大小。

可以看出,请求头里写Range,可以指定请求某一个片段的数据,相应的响应包里面用Content-Range的表示返回数据片段在整个文件中的位置。

我们再脑洞大开一下,如果我把这个文件分成4个片段,然后再用4个线程来同时下载相应的片段。请求参数类似下图这样:

产品经理

最后把它们拼在一起,那么我们的下载同样大小的文件,就只需要以前1/4的时间了。

其实这也就是多线程下载工具的基本原理,你懂了吗?

关键字:产品经理, 断点续传, 经理, chrome

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部