-
2019-05-22 15:18:41
最近研究了一下关于文件下载的相关内容,觉得还是写些东西记下来比较好。起初只是想研究研究,但后来发现写个可重用性比较高的模块还是很有必要的,我想这也是大多数开发人员的习惯吧。
对于HTTP协议,向服务器请求某个文件时,只要发送类似如下的请求即可:GET /Path/FileName HTTP/1.0
Host: www.server.com:80
Accept: */*
User-Agent: GeneralDownloadApplication
Connection: close每行用一个“回车换行”分隔,末尾再追加一个“回车换行”作为整个请求的结束。
第一行中的GET是HTTP协议支持的方法之一,方法名是大小写敏感的,HTTP协议还支持OPTIONS、HAED、POST、PUT、 DELETE、TRACE、CONNECT等方法,而GET和HEAD这两个方法通常被认为是“安全的”,也就是说任何实现了HTTP协议的服务器程序都会实现这两个方法。对于文件下载功能,GET足矣。GET后面是一个空格,其后紧跟的是要下载的文件从WEB服务器根开始的绝对路径。该路径后又有一个空格,然后是协议名称及协议版本。
除第一行以外,其余行都是HTTP头的字段部分。Host字段表示主机名和端口号,如果端口号是默认的80则可以不写。Accept字段中的*/* 表示接收任何类型的数据。User-Agent表示用户代理,这个字段可有可无,但强烈建议加上,因为它是服务器统计、追踪以及识别客户端的依据。 Connection字段中的close表示使用非持久连接。
关于HTTP协议更多的细节可以参考RFC2616(HTTP 1.1)。因为我只是想通过HTTP协议实现文件下载,所以也只看了一部分,并没有看全。
如果服务器成功收到该请求,并且没有出现任何错误,则会返回类似下面的数据:
HTTP/1.0 200 OK
Content-Length: 13057672
Content-Type: application/octet-stream
Last-Modified: Wed, 10 Oct 2005 00:56:34 GMT
Accept-Ranges: bytes
ETag: "2f38a6cac7cec51:160c"
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Wed, 16 Nov 2005 01:57:54 GMT
Connection: close不用逐一解释,很多东西一看几乎就明白了,只说我们大家都关心内容吧。
第一行是协议名称及版本号,空格后面会有一个三位数的数字,是HTTP协议的响应状态码,200表示成功,OK是对状态码的简短文字描述。状态码共有5类:
1xx属于通知类;
2xx属于成功类;
3xx属于重定向类;
4xx属于客户端错误类;
5xx属于服务端错误类。
对于状态码,相信大家对404应该很熟悉,如果向一个服务器请求一个不存在的文件,就会得到该错误,通常浏览器也会显示类似“HTTP 404 - 未找到文件”这样的错误。Content-Length字段是一个比较重要的字段,它标明了服务器返回数据的长度,这个长度是不包含HTTP头长度的。换句话说,我们的请求中并没有Range字段(后面会说到),表示我们请求的是整个文件,所以Content-Length就是整个文件的大小。其余各字段是一些关于文件和服务器的属性信息。这段返回数据同样是以最后一行的结束标志(回车换行)和一个额外的回车换行作为结束,即“/r/n/r/n”。而“/r/n/r/n”后面紧接的就是文件的内容了,这样我们就可以找到“/r/n/r/n”,并从它后面的第一个字节开始,源源不断的读取,再写到文件中了。
以上就是通过HTTP协议实现文件下载的全过程。但还不能实现断点续传,而实际上断点续传的实现非常简单,只要在请求中加一个Range字段就可以了。
假如一个文件有1000个字节,那么其范围就是0-999,则:
Range: bytes=500- 表示读取该文件的500-999字节,共500字节。
Range: bytes=500-599 表示读取该文件的500-599字节,共100字节。
Range还有其它几种写法,但上面这两种是最常用的,对于断点续传也足矣了。如果HTTP请求中包含Range字段,那么服务器会返回206(Partial Content),同时HTTP头中也会有一个相应的Content-Range字段,类似下面的格式:
Content-Range: bytes 500-999/1000
Content-Range字段说明服务器返回了文件的某个范围及文件的总长度。这时Content-Length字段就不是整个文件的大小了,而是对应文件这个范围的字节数,这一点一定要注意。一切好像基本上没有什么问题了,本来我也是这么认为的,但事实并非如此。如果我们请求的文件的URL是类似http://www.server.com/filename.exe这样的文件,则不会有问题。但是很多软件下载网站的文件下载链接都是通过程序重定向的,比如pchome的ACDSee的HTTP下载地址是:
这种地址并没有直接标识文件的位置,而是通过程序进行了重定向。如果向服务器请求这样的URL,服务器就会返回302(Moved Temporarily),意思就是需要重定向,同时在HTTP头中会包含一个Location字段,Location字段的值就是重定向后的目的 URL。这时就需要断开当前的连接,而向这个重定向后的服务器发请求。
好了,原理基本上就是这些了。其实装个Sniffer好好分析一下,很容易就可以分析出来的。不过NetAnts也帮了我一些忙,它的文件下载日志对开发人员还是很有帮助的。
本文引自:http://hi.baidu.com/chinessnetstone/blog/item/603d20094009468ad0581b23.html更多相关内容 -
http协议及基于http协议的文件下载
2019-10-11 12:27:415. 基于HTTP协议的文件下载 5.1 文件整体下载 5.2 文件分段(Range)下载 5.2.1 获取文件的大小 5.2.2 下载分段文件 5.3 文件分块(chunk)下载 1. HTTP 协议概述 日常我们使用网络用得最多的无疑是在Web ...目录
1. HTTP 协议概述
日常我们使用网络用得最多的无疑是在Web 浏览器(下文统一使用浏览器)上查找资料、看视频、看书、看新闻等等,而在浏览器中只需要输入一些搜索就可以得到想要的信息,这归根于搜索引擎的好处,但是实际上每个网页其实由多个资源组成。我们的浏览器就是一个HTTP 客户端,通过HTTP 协议访问服务器,得到服务器中的HTML 页面、文本文件、图片、音频等资源,并且将这些资源搬运到浏览器(客户端)显示给我们。
HTTP 协议是Hyper Text Transfer Protocol(超文本传输协议)的缩写,是用于从万维网(WWW:World Wide Web )服务器传输超文本到本地浏览器的传输协议,它是基于TCP/IP 协议通信的,因此它也是基于<客户端-服务器>模型运作的,是一个应用层协议,可以用它来传输服务器的各种资源,如文本、图片、音频等。
HTTP 协议的特点:
1. 简单:当客户端向服务器请求服务时,只需传送请求方法和路径即可获取服务器的资源,请求方法常用的有GET、HEAD、POST 等,每种方法规定了客户端与服务器通信的类型不同。
2. 快捷:由于HTTP 协议简单,使得HTTP 服务器的程序规模小,因而通信速度很快。
3. 灵活:HTTP 允许传输任意类型的数据对象,传输的类型由Content-Type 加以标记。
4. 无连接:无连接的含义是限制每次连接只处理一个请求,服务器处理完客户的请求,并收到客户的应答后,即断开连接,简单来说就是每进行一次HTTP 通信,都要断开一次TCP 连接,可随着HTTP 的普及,文档中包含大量图片的情况多了起来,每次请求完都要断开TCP 连接,无疑增加通信量的开销,为了解决TCP的连接问题,HTTP1.1 提出了持久连接的方法,即任意一端只要没有明确提出断开连接,则保持TCP 连接状态,这样子就就减少了TCP 连接的重复建立和断开所造成的额外开销,减轻了服务端的负载。注意,在HTTP1.1 版本之后才出现持久连接的方法。
5. 无状态:HTTP 协议是无状态协议,无状态是指协议对于事务处理没有记忆能力,即HTTP 协议无法根据之前的状态进行本次的请求处理,这就意味着如果后续处理需要前面的信息,它必须重传数据,这样的情况可能导致HTTP 协议传输的数据量增大,当然,凡事都有两面性,在另一方面,在服务器不需要先前信息时它的应答就较快,可以减少服务器的资源消耗,其实这种无状态对于用户来说也是不友好的,因此为了解决无状态的问题,引入了Cookie 技术,这是一种可以让服务器知道用户上一次做了什么操作,并且记录下来,它是存储在客户端之中的,比如我们在淘宝上买东西,我们选择了几个商品,但是到了结账会跳转到另一个页面,此时如果服务器不知道我们选择了哪些商品,那怎么能结账成功呢?所以Cookie 就是用来绕开HTTP 的无状态性的“手段”之一,服务器可以设置或读取Cookies 中包含信息,让服务器知道我们选择了什么商品,借此维护用户跟服务器会话中的状态,当然,Cookie 会被加密存储在客户端中,直到过期或者手动清除。
2. URL 与资源
我们可以把整个英特网看做是一个巨大的图书馆,里面的资源应有尽有,并且是对我们是开放的,我们想要找一本书,那么我们就需要直到他存放在哪里,然后去找到它。网络中的资源也是应有尽有,那么怎么样才能在网络的海洋中找到我们想要的资源呢?因此URI(Uniform Resource Identifiers)就被设计出来,用于统一管理资源,就像我们去图书馆找书一样,我们必须通过图书馆的系统,找到书所在的位置,而不是让我们自己一本一本书去找。
URL 全称是Uniform Resource Locator,中文叫统一资源定位符,是互联网上用来标识某一处资源的绝对地址,使用它我们就必然能找到资源,除非资源已经被转移了。URI 是一个通用的概念,由两个子集组成,分别是URL 和URN,URL 是通过资源的位置来标识资源,而URN 更高级一点,只需通过资源名字即可识别资源,与他们所处的位置是无关的,目前暂时还未推广URN。
大部分URL 都会遵循URL 的语法,一个URL 的组成有多个不同的组件,一个URL的通用格式如下
<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>
当然,绝大部分的URL 是不会包含所有组件的内容的.
URL 组件 scheme(方案) 指定访问服务器获取资源时使用哪种协议,有HTTP、HTTPS、FTP、SMTP 等协议。 user(用户) 某些方案访问资源时候需要指定用户名,才有权限获取资源。 password(密码) 用户名后面可能需要密码进行验证,用户名与密码直接使用 “:” 冒号分隔连接。 host(主机) 资源宿主服务器的主机名或者IP 地址(点分十进制)。 port(端口) 资源宿主服务器正在监听的端口号,很多方案都有默认的端口号,而无需我们自己填写,比如HTTP 默认使用80 端口,HTTPS 默认使用443 端口。端口不是一个URL 必须的部分,如果省略端口部分,将采用默认端口。 path(路径) 服务器本地资源的路径。类似于电脑中的文件路径一样,使用“/”将路径与端口隔离。从域名后的第一个“/”开始到最后一个“/”为止,虚拟目录也不是一个URL 必须的部分,在路径之后是需要一个文件名,这就是URL 指定的资源。文件名部分也不是一个URL 必须的部分,如果省略该部分,则使用默认的文件名 params(参数) 某些方案会使用这个组件来输入参数,可以拥有多个参数,使用“;”符号与路径分隔开。 query(查询) 某些方案会使用这个组件传递参数以激活应用程序,查询组件的内容没有通用的格式,用“?”字符与其他组件分隔开 frag(片段) 一小片或者一部分资源的名字,引用对象时,不会将片段组件内容传输给服务器,这个字段是在客户端内部使用的,通过“#”字符与其他组件分隔开。 比如:https://blog.csdn.net/XieWinter,它就是一个URL,这是最简单的一个URL 格式,通过其可以访问相应的资源。
3. HTTP报文
HTTP 报文是由3 个部分组成,分别是:对报文进行描述的“起始行”,包含属性的“首部”,以及可选的“数据主体”,对于请求报文与应答报文,只有“起始行”的格式是不一样的。
http 请求报文
<method> <request-url> <version> // 起始行 <headers> // 首部 <entity-body> // 数据主体
http 应答报文
<version> <status> <reason-phrase> // 起始行 <headers> // 首部 <entity-body> // 数据主体
起始行和首部就是由行分隔的 ASCII 文本组成,每行都以由两个字符组成的行终止序列作为结束,其中包括一个回车符(ASCII 码 13)和一个换行符(ASCII 码 10), 这个行终止序列可以写做 CRLF。
这两种HTTP 报文的各个部分简单描述:
- 方法(method):HTTP 请求报文的起始行以方法作为开始,方法用来告知服务器要做些什么,常见的方法有GET、POST、HEAD 等,比如“GET /forum.php HTTP/1.1” 使用的就是GET 方法。
- 请求URL(request-URL):指定了所请求的资源。
- 版本(version):指定报文所使用的HTTP 协议版本,其中<major>指定了主要版本号, <minor>指定了次要版本号,它们都是整数,其格式如下:
HTTP/<major>.<minor>
- 状态码(status):这是在HTTP 应答报文中使用的,状态码是在每条响应报文的起始行中返回的一个数字码,描述了请求过程中所发送的情况,比如成功、失败等,不同的状态码有不同的含义
200 常见的返回OK,404错误等,206 状态码将会文件分段下载中使用。
- 原因短语(reason-phrase):这其实是给我们看的原因短语,因为数字是不够直观,它只是状态码的一个文本形式表达而已。
- 首部(header):HTTP 报文可以有0 个、1 个或者多个首部,HTTP 首部字段向请求和响应报文中添加了一些附加信息,从本质上来说,它们是一个<名字:值>对,每个首部都包含一个名字,紧跟着一个冒号“:”,然后是一个可选的空格,接着是一个值,最后以CRLF 结束,比如“Host: blog.csdn.net”就是一个首部。
- 数据主体(entity-body):这部分包含一个由任意数据组成的数据块,其实这与我们前面所讲的报文数据区域是一样的,用于携带数据,HTTP 报文可以承载很多类型的数字数据:图片、视频、音频、HTML 文档、软件应用程 序等。
4. 使用Postman 获取数据
既然了解了HTTP 协议与HTTP 报文的相关知识,我们就来使用Postman 软件了解一下HTTP 协议的传输过程。
官网:https://www.getpostman.com/
安装后打开软件,就可以使用软件进行测试HTTP 协议,可以很直观看到发送的HTTP 报文是什么,也能很直观看到响应的数据。
可以简单注册一下,就可以记录发送的命令,相当不错。
或者
查看发送HTTP 请求报文
Postman 功能很强大,只是用到其最简单的功能。
5. 基于HTTP协议的文件下载
5.1 文件整体下载
文件整体下载比较简单,只需要知道资源的位置下载就可以。
5.2 文件分段(Range)下载
在嵌入式设备或者资源有限的设备中,可能需要下载的文件的大小,自身资源不能一次性的满足,需要分段下载才行。文件分段下载的前提条件是,支持文件分段下载,否则,即便采用分段获取的,下载的也是整个文件大小,比如GitHub上面的就会下载整个文件的大小。
文件下载的流程如下:
- 获取文件的大小
- 下载各分段文件
- 文件拼接
- 文件完整性检查
5.2.1 获取文件的大小
因为需要分段下载,因此,首先需要知道文件的大小,才方便计算分段,当然,不分段也不是不可以,但处理起来,没有先获取文件大小规范。
可以直接获取资源链接的网站,检查响应的消息头字段中是否存在 如下字段,存在则支持,否则,不支持
Accept-Ranges: bytes
这就需要用到消息头字段添加 Range 字段
Range: bytes=0-1024 获取最前面1025个字节 Range: bytes=-500 获取最后500个字节 Range: bytes=1025- 获取从1025开始到文件末尾所有的字节 Range: 0-0 获取第一个字节 Range: -1 获取最后一个字节
请求成功后服务器会返回状态码206, 并返回如下字段指示返回结果, 0-1024指示返回分段范围, 7877指示文件总大小
Content-Range: bytes 0-1024/7877因此采用如下,获取文件大小:
Range: 0-0 获取第一个字节
示例:
5.2.2 下载分段文件
分段下载分为两种,一种就是一次请求一个分段,一种就是一次请求多个分段。
下面两种都会有介绍,但是,实际上,除非为了多线程多段下载(PC下载软件 Internet Download Manager ),否则,在嵌入式开发中一般还是采用一次请求一个分段。
根5.2.1 可知文件大小,如示例文件大小为 3700512 字节。
具体怎么分段,根据设备资源来分配,原理是一样都。
假如分三段 0-999999,1000000-1999999,2000000-3700511
一次请求一个分段
- 第一段消息头字段添加
Range: bytes=0-999999 获取最前面1000000个字节
-
第二段消息头字段添加
Range: bytes=1000000-1999999 获取第二个1000000个字节
-
末段消息头字段添加
Range: bytes=2000000-3700511 获取最后一段 或另一种方式 Range: bytes=2000000- 获取最后一段 // 这种更好些
一次请求多个分段
至此,文件下载完成,文件的拼接,如果是 类似都 xxx.bin文件,那么保存的时候,同一块地址连续保存就完成来拼接来。因为这里主要也是想表达通过http 服务分段下载文件,来升级程序,实现 FOTA 功能 ,其它方法暂不多说;
文件下载完成后,需要校验文件都完整性,否则不完整都程序,一旦升级将造成死机的情况。
5.3 文件分块(chunk)下载
Transfer-Encoding: chunked 表示输出的内容长度不能确定,普通的静态页面、图片之类的基本上都用不到这个。但动态页面就有可能会用到,但也注意到大部分asp,php,asp.net动态页面输出的时候大部分还是使用Content-Length,没有使用Transfer-Encoding: chunked。
Transfer-Encoding: chunked使用,就不必申请一个很大的字节数组了,可以一块一块的输出,更科学,占用资源更少。
这在http协议中也是个常见的字段,用于http传送过程的分块技术,原因是http服务器响应的报文长度经常是不可预测的,使用Content-length的实体搜捕并不是总是管用。分块技术的意思是说,实体被分成许多的块,也就是应用层的数据,TCP在传送的过程中,不对它们做任何的解释,而是把应用层产生数据全部理解成二进制流,然后按照MSS(Maxitum Segment Size 最大分段大小,一般客户端资源有限,大小受其限制)的长度切成一分一分的,一股脑塞到tcp协议栈里面去,而具体这些二进制的数据如何做解释,需要应用层来完成,所以在这之前,一块整体应用层的数据需要等它分成的所有TCP segment到达对方,重新组装后,应用程序才使用自己的解码方法还原它们。
HTTP1.1采用了持久的连接,也就是一次TCP的连接不马上释放,允许许多的请求跟响应在一个TCP的连接上发送,所以客户机与服务器需要某种方式来标示一个报文在哪里结束和在下一个报文在哪里开始。简单的方法是使用呢content-length,但这只有当报文长度可以预先判断的时候才起作用,而对于动态的内容或者在发送数据前不能判定长度的情况下,可以使用分块的方法来传送编码。
Web服务器有时生成HTTPResponse无法在Header就确定消息大小的,这时一般来说服务器将不会提供Content-Length的头信息,而采用Chunked编码动态的提供body内容的长度。进行Chunked编码传输的HTTP Response会在消息头部设置:Transfer-Encoding: chunked表示Content Body将用Chunked编码传输内容。
Chunked编码使用若干个Chunk串连而成,由一个标明长度为0的chunk标示结束。每个Chunk分为头部和正文两部分,头部内容指定下一段正文的字符总数(十六进制的数字)和数量单位(一般不写),正文部分就是指定长度的实际内容,两部分之间用回车换行(CRLF)隔开。在最后一个长度为0的Chunk中的内容是称为footer的内容,是一些附加的Header信息(通常可以直接忽略)。
chunk编码其实是一种动态数据传输协议,针对大数据可以动态传输,网页可以动态显示。
chunk编码格式如下:
[chunk size][\r\n][chunk data][\r\n][chunk size][\r\n][chunk data][\r\n][chunk size = 0][\r\n][\r\n]
chunk size是以十六进制的ASCII码表示,比如33 37 35,计算成长度应该是:0x375(885),表示从回车之后有连续的885字节的数据。
chunk数据以0长度的chunk块结束。
分块传输的前提条件是,服务器支持该方式!!!且为http1.1协议。
注:本节没有详细介绍HTTP及其消息头字段,只是从FOTA都角度,来说明相关都东西,深入都需要查询相关协议。
-
MQTT-3.1.1标准协议文档中文版
2019-05-05 06:12:33MQTT-3.1.1标准协议文档 中文版 适合具体学习使用,MQTT协议 3.1.1中文版 OASIS标准 2014年 10月 29日 -
JT/T808协议文档
2018-12-05 15:09:48JT/T808协议文档,这里介绍了JT/T808协议基本构成,报文类型,以及协议开发流程 -
采用C#语言,实现通过FTP协议获取服务器的文件列表和下载文件
2016-01-09 17:03:30采用C#语言,实现通过FTP协议获取服务器的文件列表和下载文件-Using C# language, to achieve access to the server via FTP protocol file list and download files -
qt实现https协议文件下载
2014-02-20 14:09:22这个是根据http下载改编的,专门针对https协议的文件下载 -
文件下载协议 HTTP、FTP、P2P
2018-07-24 22:42:54要点: ... P2P 无论是 HTTP 的方式,还是 FTP 的方式,都有一个比较大的缺点,就是难以解决单一服务器的带宽压力, 因为它们使用的都是传统的客户端服务器的方式。 后来,一种创新的、称为 P2P 的方式...下载一个...要点:
HTTP与FTP
P2P
无论是 HTTP 的方式,还是 FTP 的方式,都有一个比较大的缺点,就是难以解决单一服务器的带宽压力, 因为它们使用的都是传统的客户端服务器的方式。
后来,一种创新的、称为 P2P 的方式流行起来。P2P就是peer-to-peer。资源开始并不集中地存储在某些设备上,而是分散地存储在多台设备上。这些设备我们姑且称为 peer。
P2P定义
- 下载一个文件可以使用 HTTP 或 FTP,这两种都是集中下载的方式,而 P2P 则换了一种思路,采取非中心化下载的方式
- P2P 也是有两种,一种是依赖于 tracker 的,也即元数据集中,文件数据分散;另一种是基于分布式的哈希算法,元数据和文件数据全部分散
-
首先简述HTTP下载和FTP下载的区别:
我们先要知道,使用Web浏览器时,这两个协议之间的差异几乎不会对使用的方便性及下载时间产生影响。不过,两者却拥有各自不同的结构。
HTTP下载
- HTTP是一种为了将位于全球各个地方的Web服务器中的内容发送给不特定多数用户而制订的协议。也就是说,可以把HTTP看作是旨在向不特定多数的用户“发放”文件的协议。
- HTTP使用于从服务器读取Web页面内容。Web浏览器下载Web服务器中的HTML文件及图像文件等,并临时保存在个人电脑硬盘及内存中以供显示。
- 使用HTTP下载软件等内容时的不同之处只是在于是否以Web浏览器显示的方式保存,还是以不显示的方式保存而已。结构则完全相同。因此,只要指定文件,任何人都可以进行下载。
-
FTP下载
FTP即文件传输协议
FTP 采用两个 TCP 连接来传输一个文件。
- 控制连接:服务器以被动的方式,打开众所周知用于 FTP 的端口 21,客户端则主动发起连接。该连接将命令从客户端传给服务器,并传回服务器的应答。常用的命令有:list——获取文件目录;reter——取一个文件;store——存一个文件。
- Peer-to-peer 是一类允许一组用户互相连接并直接从用户硬盘上获取文件的网络
- Peer-to-peer网络是一个运行于个人电脑上的应用,通过网络在用户间分享文件。P2P网络通过连接个人电脑分享文件而不是通过中央服务器
- P2P是一种分布式网络,网络的参与者共享他们所拥有的一部分硬件资源(处理能力、存储能力、网络连接能力、打印机等),这些共享资源需要由网络提供服务和内容,能被其它对等节点(peer)直接访问而无需经过中间实体。在此网络中的参与者既是资源(服务和内容)提供者(server),又是资源(服务和内容)获取者(client)
- 数据连接:每当一个文件在客户端与服务器之间传输时,就创建一个数据连接。
-
另一方面,FTP是为了在特定主机之间“传输”文件而开发的协议。因此,在FTP通信的起始阶段,必须运行通过用户ID和密码确认通信对方的认证程序,
FTP下载和HTTP下载的区别之一就在与此。
FTP 的两种工作模式:
每传输一个文件,都要建立一个全新的数据连接。FTP 有两种工作模式,分别是主动模式(PORT)和被动模式(PASV),这些都是站在 FTP 服务器的角度来说的。
P2P特点
- 无中央服务器,打破了C/S模式
- 用户之间互联并分享文件。
BitTorrent
想要下载一个文件的时候,你只要得到那些已经存在了文件的 peer,并和这些 peer 之间,建立点对点的连接,而不需要到中心服务器上,就可以就近下载文件。
一旦下载了文件,你也就成为 peer 中的一员,你旁边的那些机器,也可能会选择从你这里下载文件,所以当你使用 P2P 软件的时候,例如 BitTorrent,往往能够看到,既有下载流量,也有上传的流量,也即你自己也加入了这个 P2P 的网络,自己从别人那里下载,同时也提供给其他人下载。
可以想象,这种方式,参与的人越多,下载速度越快,一切完美。
种子(.torrent)文件
但是有一个问题,当你想下载一个文件的时候,怎么知道哪些 peer 有这个文件呢? 这就用到种子啦,也即咱们比较熟悉的.torrent 文件。.torrent 文件由两部分组成,分别是:announce(tracker URL)和文件信息。(tracker谷歌翻译为跟踪器)
文件信息里面有这些内容:
- info 区:这里指定的是该种子有几个文件、文件有多长、目录结构,以及目录和文件的名字
- Name 字段:指定顶层目录名字
- 每个段的大小:BitTorrent(简称 BT)协议把一个文件分成很多个小段,然后分段下载
- 段哈希值:将整个种子中,每个段的 SHA-1 哈希值拼在一起
工作过程:
- 下载时,BT 客户端首先解析.torrent 文件,得到 tracker 地址,然后连接 tracker 服务器。
- tracker 服务器回应下载者的请求,将其他下载者(包括发布者)的 IP 提供给下载者。
- 下载者再连接其他下载者,根据.torrent 文件,两者分别对方告知自己已经有的块,然后交换对方没有的数据。
此时不需要其他服务器参与,并分散了单个线路上的数据流量,因此减轻了服务器的负担。
这个过程也可以看出,这种方式特别依赖 tracker。tracker 需要收集下载者信息的服务器,并将此信息提供给其他下载者,使下载者们相互连接起来,传输数据。
虽然下载的过程是非中心化的,但是加入这个 P2P 网络的时候,都需要借助 tracker 中心服务器,这个服务器是用来登记有哪些用户在请求哪些资源。
所以,这种工作方式有一个弊端,一旦 tracker 服务器出现故障或者线路遭到屏蔽,BT 工具就无法正常工作了。
去中心化网络(DHT)
为了向彻底去中心化迈步前进,后来就有了一种叫作DHT(Distributed Hash Table)的去中心化网络。
每个加入这个 DHT 网络的人,都要负责存储这个网络里的资源信息和其他成员的联系信息,相当于所有人一起构成了一个庞大的分布式存储数据库。
有一种著名的 DHT 协议,叫Kademlia 协议。这个和区块链的概念一样,很抽象。
任何一个 BitTorrent 启动之后,它都有两个角色。一个是peer,监听一个 TCP 端口,用来上传和下载文件,这个角色表明,我这里有某个文件。另一个角色DHT node,监听一个 UDP 的端口,通过这个角色,这个节点加入了一个 DHT 的网络。
迅雷离线下载的原理是什么?
答:离线下载,即利用服务器“替”网友的电脑下载的方式。具高速、不用挂机的优点而颇受欢迎。如果用户要下载一些电影或者游戏资源,往往要长时间挂机,不仅浪费时间而且消耗大量的带宽。 离线下载其实就是下载工具的服务器代替用户先行下载,多用于冷门资源。比如,用户的正常下载最大速度能达到200KB/S,但是某个资源是冷门资源,下载速度只能达到10KB/S,用户就得下很久,如果用户使用离线下载技术,就可以让服务商的服务器代替用户下载,用户就可以关掉下载工具或者机器,节约时间和电费。等到离线下好了,用户再从下载工具的服务器上以200KB/S(理论上会员等级越高越快,但最高速度仍然受限制于你的本身宽带)的速度下到自己的电脑上。即使对于热门资源,离线下载也能省却许多挂机等待的时间,最重要的是能够腾出电脑宽带做其他的事情。
操作过程:(1)用户通过客户端或Web界面提交一个下载请求。 (2)公司服务器端接受请求,服务器首先查询用户提交的下载链接是否被下载过;如果没有,开启多线程实施下载(或用迅雷自己特有的P2P方式);如果有,直接把已下载的数据文件(或只是文件的链接)放入用户服务器端的在线空间。 (3)下载完成后,用户在线登录到在线空间,取回下载的文件。其间也可以采用迅雷自己的P2P方式,从已下载或正在下载相同文件的用户那里取得数据。 (4)离线下载多针对冷门资源,或资源少的文件。待服务器端不是替用户下载完成后,用户还需要利用下载软件从服务器上下载文件。相比直接下载,增加了下载资源速度,节约了时间。
简单来说,就是如果要下载的资源已经存在于迅雷的服务器中,那么直接用P2P的方式从迅雷的服务器中取回。如果下载的资源尚未下载,那么可以将下载任务交由服务器代为完成(委托模式啊,哈哈),由于服务器的带宽性能等远胜于普通用户,所以下载效率更高,最重要的是服务器是365 * 7 * 24小时在线的,可以用时间堆死它。
-
dicom协议中文文档
2017-07-12 23:15:26医学文件dicom协议,完整中文版,无水印 -
delphi压缩后使用http协议base64上传下载6G超大文件
2021-11-21 16:43:39delphi压缩后使用http协议base64上传下载6G超大文件 注:服务端软件,使用高勇出品GYRestServer系列。欢迎使用,加QQ群咨询:174483085 一、知识点: 1、Delphi自带的压缩解压单元system.zlib.pas中核心函数的...delphi压缩后使用http协议base64上传下载6G超大文件
注:服务端软件,使用高勇出品GYRestServer系列。欢迎使用,加QQ群咨询:174483085
一、知识点:
1、Delphi自带的压缩解压单元system.zlib.pas中核心函数的使用
2、服务端http协议ContentType(mime-type)相关列表类型的注册
3、Base64编码的规则
4、为何要分块断点续传,并使用TFileStream文件流替代内存流TMemoryStream
5、Buffer.size对Base64分块断点续传的影响
6、优化上传下载的速度与并发性能的综合考虑
二、直接看视频了解核心关键内容
从本博客资源下载:
链接: https://pan.baidu.com/s/1Zpxfe5fJruuJW68x3dDTSw
提取码:iqvo三、其它的补充说明
3.1、优化上传下载的速度与并发性能的综合考虑
参考本博客博文:
浅谈服务器http并发数的影响因素_pulledup的博客-CSDN博客
https://blog.csdn.net/pulledup/article/details/121383350
3.2、服务端http协议ContentType(mime-type)相关列表类型的注册
参考本博客博文:
delphi MimeType for Restful及delphi mime-type和文件扩展名对照表_pulledup的博客-CSDN博客delphi MimeType for Restful MimeType是你让编写的应用Restful化编程所必须的。delphi支持哪些MimeType,如何知道这些MimeType与文件扩展名的对应关系,以及它们是文本种类、二进制种类还是未定义的。一、先上代码 : 已附上面源码下载。由于代码引用了跨平台的文件存取,使用源码注意事项:1、在FormCre...
https://blog.csdn.net/pulledup/article/details/105774767delphi XE应用Restful时Rest组件的delphi XE ContentType即delphi XE mime type怎样获取和表达_pulledup的博客-CSDN博客delphi XE应用Restful时Rest组件的delphi XE ContentType即delphi XE mime type怎样获取和表达一、usesREST.Types;//var //DefaultRESTRequestParameterKind: TRESTRequestParameterKind = TRESTRequestParameterKind.pkGETor...
https://blog.csdn.net/pulledup/article/details/105749158
3.3、Buffer.size对Base64分块断点续传的影响
为何使用Base64?
如果你仅仅是上传下载,而无需下载后H5加载,可以不必非得使用TBase64Encoding来编解码。可参考本博客博文:
否则,请使用Base64,它可以对html和URL进行编解码。请直接使用高勇出品GYRestServer系列及其配套客户端GYRestClient.pas中的相关代码进行客制化。
Base64内容传输时需要注意的事项:
//http分块上传或下载时,需注意: block := (6*25)*7 * 1024 * 1;//=1050KB //:来超2021-11-19:提升服务器并发性能:拷贝分块大小,delphi默认32kb //block := 1024 * 1024 * 1;//:拷贝分块大小,每次拷贝1M: //:(一次上传,最多不能超过25M,似乎超过了,就没有响应) //:Buffer不正确会对Base64分段产生无规律的不可预期的影响: //:Base64----4组每组6位编码----块:6位字节的整数倍--以替换8位1组的二进制 //:W3C标准: https://datatracker.ietf.org/doc/html/rfc2045 //:delphi默认buffer.size=32k,太小了: //:1.1、客户会感觉太慢了 //:1.2、某些服务器也可能做了限制:不允许连续发小包给它,它人为你是在http攻击 //:buffer.size=N个KB,太大了: //:2.1、客户端内存不允许:上限好像是忘了65535KB? 32768KB? 总之最好不要超过1M //:2.1、服务器并发时, //:内存(取决于服务器内存的大小) //:磁盘(取决服务器硬盘通道即单位时间IO速度)、 //:网路带宽(取决你服务器的带宽) //:它们受不了大的“冲击波"
Base64 内容传输的W3C标准说明:
3.4、为何需使用TFileStream文件流替代内存流TMemoryStream
并发时,压缩解压也好、上传下载也好,或使用内存流TMemoryStream,内存的开销太大、而且内存很昂贵,使用文件流TFileStream替代内存流,会有效避免此问题。
用Delphi自带的system.zlib.pas库单元函数压缩解压时,要特别注意:
3.4.1、必要期待你能用常用的压缩解压工具,去打开system.zlib压缩文件,因为它是Delphi专用的压缩格式,加了密的;不过这样也很安全;
3.4.2、无论压缩环节还是解压环节均不要TStream.CopyFrom
因为这样,会丢失字节。而应当老实的用字节数组,逐个字节的读取或写入。
-
各类接口协议文档
2013-10-23 11:21:47各类接口协议文档包括amba\spi\i2c\uart等等 -
使用HTTP协议下载文件
2014-12-07 00:26:04为了测试方便,在自己的电脑上开一个web服务Tomcat,在Tomcat的webapps文件夹里放测试下载用的文件 在cmd的ipconfig指令下查看自己的主机的IP地址。 之前没有接触过Tomcat,就先按网上介绍的安装教程下载Tomcat,并... -
OPC官方统一架构(UA)协议文档
2019-04-08 10:55:32OPC统一架构协议文档(2015),Part 1: 概述和概念,Part 2: 信息安全模型,Part 3: 地址空间模型,Part 4: 服务,Part 5: 信息模型,Part 6: 映射,Part 7: 配置文件,Part 8: 数据访问,Part 9: 报警和条件,Part ... -
zmodem官方协议文档
2018-04-21 09:40:31zmodem通信协议,不是源码。适用于想自己开发zmodem嵌入式代码,用于通过串 口、USB烧写字库、程序等文件。 -
采用http协议实现文件下载功能源代码
2009-06-18 13:50:35采用C语言并根据HTTP协议实现HTTP文件的下载功能,有较高的实现效率,占用资源低,可作为一个单独的功能移植到手机上,提供一种相对简单的文件下载机制。 -
交通部 JTT 809协议 2019 pdf.zip
2020-08-18 16:07:09交通部 JTT 809协议 2019 pdf文件 -
tealium-ios:使用此... 下载或使用这些文件中的任何一个,即表示您同意接受许可协议的约束并遵守该许可协议
2021-05-09 04:55:20适用于iOS的Tealium移动库 该库已被取代。 它可以继续在Tealium平台上运行,但是我们强烈建议您... 下载或使用任何这些文件,即表示您同意受许可协议的约束并遵守该许可协议。 Tealium Inc.版权所有(C)2012-2021 -
PMbus协议规范最新文档完整版
2020-06-30 16:16:01发邮件找美国佬申请提供的,里面说明了所有PMbus规定的数据格式,转换格式,I2C发送指令的模式,正版文件放心下载, -
MQTT5.0协议中文版
2020-07-16 20:24:48MQTT5.0协议,包含word版和pdf版两个文件,内容详实,翻译可靠,是学习mqtt5.0的好帮手 -
libcurl学习笔记(2)——通过HTTP协议下载文件
2020-09-16 14:42:10libcurl 主要功能就是用不同的协议连接和沟通不同的服务器~也就是相当封装了的 sockPHP 支持 libcurl(允许你用不同的协议连接和沟通不同的服务器)。 libcurl 当前支持 http,https, ftp, gopher, telnet, dict, ... -
MQTT协议完整中文版版.pdf
2019-12-14 09:30:16物联网IOT协议MQTT协议完整中文版手册,适用于需要完整学习MQTT协议的介绍、使用、结构了解等等需要 -
hdmi协议手册.rar
2020-12-01 18:39:58hdmi 1.4官方协议手册,hdmi 2.0官方协议手册,hdmi 2.0b官方协议手册,hdmi 2.1官方协议手册 -
c语言通过http协议下载
2012-03-02 10:25:50程序功能 1、通过http语言,在后台下载资源,实现软件更新 2、程序使用c语言实现,效率高 3、想知道软件如何更新,想近一步了解http协议,或者很闲,可以参考一下。 -
Modbus协议中文pdf免费下载地址
2021-04-14 22:15:38本着开源的精神,给大家分享 资源。 Modbus中文版免费下载地址 -
Delphi/XE2 使用TIdHttp控件下载Https协议服务器文件
2018-06-20 09:41:10之前的一篇博文详细描述了使用TIdhttp控件下载http协议的文件,在我项目的使用过程中发现对于下载Https协议中的文件与Http协议的文件不同,毕竟Https在HTTP协议基础上增加了SSL协议。接下来我们就来看看如何下载... -
AutoSAR标准协议4.2.2
2020-01-19 14:09:03AutoSAR标准协议规范4.2.2,里面包含了AutoSAR组织所规定的AutoSAR架构的标准规范协议原文档。对AutoSAR的学习有一定的借鉴意义 -
RTCM3.3协议全
2018-11-20 11:26:27全新RTCM3.3协议完整版 RTCM STANDARD 10403.3 DIFFERENTIAL GNSS (GLOBAL NAVIGATION SATELLITE SYSTEMS) SERVICES – VERSION 3 DEVELOPED BY RTCM SPECIAL COMMITTEE NO. 104 OCTOBER 7, 2016 COPYRIGHT©2016 ... -
USB2.0协议完整版(官方网站下载版-英文版)
2016-01-15 09:54:32该文档包含USB2.0相关的所有协议内容(不包含类协议),文档有USB2.0协议、USB2.0 OTG补充协议、USB2.0电气特性、USB2.0插头尺寸说明等(无分数要求无偿分享,求发扬无偿分享) -
HTTP协议实现文件下载
2017-08-04 15:04:45* @param fileName 文件保存时的名称 */ public static void writeImageToDisk ( byte [ ] img , String fileName ) { try { File file = new File ( "D:\\" + fileName ) ; ... -
文件传输协议介绍
2019-06-11 16:23:30文件传输协议介绍 文件传输协议是一种极为普遍的档案分享服务,让你可以将你的档案从储存装置传送到ASUSTOR NAS。ASUSTOR NAS 所支援的文件传输协议可分为: CIFS (网络文件共享系统) 通常是指 SMB,SAMBA 或 ... -
PB通过Http协议上传、下载文件
2019-02-17 20:51:39PB通过Http协议上传、下载文件 PB自身也有http组件,但使用起来较为繁琐。VDN作者将http功能通过API的形式封装为HttpClient组件,PB直接调用即可,通过该组件可以便捷的实现文件上传、文件下载或Blob上传、下载到...