【03】第一章 | 轻松入门,从基础下载方式讲起

Fairyex
01月03日

第一章 | 轻松入门,从基础下载方式讲起

| 本文为付费栏目文章,您已订阅,可阅读全文 |

热身:最基础的下载方式 —— HTTP(S)

这个链接看起来很熟悉是吗?当下载提示弹出来的一刻,你有没有认识到这种最直接最为人熟知也是最多人使用的下载方式,和访问网页这一行为之间的区别?
答案是没有区别。
让我们先来看看 HTTP(全写:HyperText Transfer Protocol)协议的定义:
HTTP 是一个用于客户端终端(用户)和服务器端(网站)之间请求和应答的协议。
我想你一定不会喜欢文章中充斥着这种晦涩的语言,这是本文的解释:
信息即是你在互联网上能访问到的所有东西,包括文本,图像,视频和各种格式的文件,协议是指网络中两台设备之间进行通信所必须共同遵守的规定或规则,HTTP 规定了每次请求的格式,用什么方法传输数据,在各种命令下服务器和浏览器要采取什么响应。
一句话解释:HTTP 制定了双方该怎么说,用什么方式让对方听到,碰到各种情况如何回应。浏览器和服务器都遵守这个规矩,可以避免出现「鸡同鸭讲」的问题。
你想要打开少数派首页的时候,浏览器「客户端」会通过对少数派的服务器直接说我想要访问少数派的首页,服务器听到了之后就会动态地生成包括最新文章的首页数据返回给浏览器。
这里的首页数据就是很多个不同格式的文件。之所以我们会常识性地把浏览网页和下载文件区分开,是因为浏览器里面内置了可以将这些数据视觉化的解释引擎「简单理解:解码器」,当首页数据文件下载完毕时立即渲染出可以直接「看」的网页;而一些它「读不懂」的数据,则会提示你保存到设备让其他可以「读懂」的程序打开它。

浏览器中打开控制台(快捷键 Windows:F12;Mac OS:Command + Option + I),在资源(Sources)中能看到浏览器「下载」了哪些文件来显示网页。
举两个实际的例子帮助各位理解:当我们用现代浏览器打开一个 TXT 或者 PDF 文件的时候,往往不会弹出下载框,而是直接在窗口里可以看到内容。原因是现代浏览器内置的解码器比起原始的浏览器多了不少,原本需要下载的 txt 和 pdf 也可以像网页一般浏览了。

在 Chrome 中直接浏览 PDF 文件
另一个例子网龄比较长的派友可能还记得,曾经有一种从 IE 缓存目录提取缓存数据然后重命名就可以下载各种在线音频和视频的方法。这种方法侧面证明了浏览互联网内容即是一个不断下载文件的过程。

带资源嗅探的浏览器可以轻松下载在线视频
读到这里,大家对这种下载方式应该有个形象的了解了吧。那么我们再来列举一下作为一种传统的下载方式它的优点和缺点。

优点

  • 不需要专用的下载工具。使用普通浏览器甚至不需要浏览器都可以随时随地保存文件。例如我们平时打开需要联网的 App 时获取的数据,就是通过 http 「下载」到本地之后再进行解析。
  • 文件名,格式和下载域名直接可见,可以一定程度避免下载到错误的文件。
  • 轻松达到满速。在服务器带宽足够或有好的 CDN 情况下下载速度可以轻松达到物理宽带满速。这里的「带宽」指的是一秒钟能传输的最大信息量,并非实际的速度。单位是 Mbps(Mega bit per second),例如运营商说的 100M(兆)光纤就是 100Mbps 的光纤,注意单位是「bit(位)」。我们常说的下载速度是 MB/s(Mega Byte per second),注意单位是「Byte(字节)」。虽然缩写相同,但是它们是完全不同的单位,关系是 1Byte=8bit,也就是说 100M 光纤理论上能达到的最大下载速度就是 100/8=12.5MB/s。
那么为什么要用两个单位呢?这是因为数据传输的最小单位是 bit,也就是二进制中的 0 或者 1,而文件储存的最低单位是 Byte,由 8 个 bit 组成,根据排列不同有 2 的 8 次方即 256 种排列方法,可以代表包括数字,大小写字母和常用字符。(这也是为啥 1Byte=8bit,同理一个中文字占 2 byte,因为 2 的 16 次方等于 65536,16bit 才足够覆盖常见中文字符)

IBM 最早的电脑上采用的 EBCDIC 编码表就是 8bit,很多人认为这也是 1Byte=8bit 的重要原因
所以数据传输领域经常用 bit 做单位(传输的是 0/1),下载和上传速度用 Byte 做单位(因为下载或上传 1byte 以上的数据才有意义)。
CDN(Content Delivery Network,内容分发网络),是为了解决网络延时,响应速度和稳定率的一种技术。假设某个网站只有在上海有服务器,那么上海的用户访问网站就比需要经过多个运营商节点跳转的云南用户快上不少。
这时候网站购买了 CDN 服务,在空闲时将网站访问量大的数据复制到覆盖全国的多个服务器上,用户访问网站时自动调用最近的 CDN 服务器上的网站数据,不会再因为距离过远导致数据加载速度降低。既提高了用户体验,又实现了负载均衡和数据备份,现在大部分网站和游戏都部署了 CDN。

缺点

  • 文件是否能被下载完全取决于源地址的所有者,如果请求的文件从源地址删除,移动或重命名,就没有办法下载到。
  • 开放式请求,服务器会记录下载者的 IP 地址和其他数据,易造成隐私泄露。
  • 下载时文件数据易被中间人篡改,文件数据不安全。由于 HTTP 传输文件时是直接明文传输数据,所以黑客很容易通过监听你的设备流量轻松提取下载的文件,就像边听别人的谈话边抄下来一样。同时黑客还可以充当下载双方的「中间人」,随意拦截修改这些明文数据,伪造正常的请求返回给双方,让服务器和客户端都认为是在和对方通信,让下载方不知道这些文件其实是被篡改过的。
  • 在固定服务器带宽下,下载人数越多速度越慢,并且大多数服务器会主动限速。大多数情况使用多线程下载工具可以解决问题。

提示:只通过采用 https(全写:Hyper Text Transfer Protocol over Secure Socket Layer;简单理解:HTTP 的安全版)的网站下载文件的方法可以一定程度上保证文件数据的安全。具体可以查看本教程第七章关于下载安全问题的部分。

断点续传与多线程下载加速的原理

说到 HTTP 下载,那不得不提到一些现在或者曾经非常好用的 HTTP 下载器,比如 Windows 上老牌的 IDM(Internet Download Manager),活在人们心中的网络蚂蚁和网际快车,被誉为手机版 IDM 的 ADM(Advanced Download Manager)等。它们之所以受到人们的喜爱与称赞,是因为它们提供了曾经是杀手锏级别的两个功能 —— 断点续传与多线程下载,这两个功能节省了大家巨量的下载时间,但是你知道这两个功能是怎样工作的吗?

断点续传的原理

断点续传的原理其实非常简单。我们平时下载的文件,无论是 MP3,FLV 还是其他随便什么格式,服务器都是采用流(Stream)的方式传到我们的本地设备上。就像往杯里倒水一样,不管是橙汁还是牛奶都是一样地从瓶里流到杯里,带宽即相当于瓶口的宽度,决定你能倒多快。
以一个 1MB 的文件为例,当你下载了 512KB 然后按下暂停下载按钮的时候,什么也不会发生。只有在你下次继续下载的时候,支持断点续传的客户端才会以字节数的方式直接在请求头(Header,每次请求就像寄信,Header 就像是信封上的信息,包含双方地址身份信息和其他自定义信息)告诉服务器我需要从第 512000 字节开始下载,支持断点下载的服务器(现在不支持这个的服务器已经濒临灭绝了……)就会从 512000 字节开始传输流并返回一个表示「这是续传」的特殊状态码 206(状态码用来表示目标服务器或者域名解析服务器对这个请求的「态度」,像是我们常见的 404 就是表示「我不存在」的状态码)以说明这个不是重新下载的流。

到这里断点续传还要解决一个问题,就是当暂停下载文件之后,服务器上的文件被修改了,如果接着下载的话最后文件数据肯定是错的。所以支持断点续传的客户端在请求续传时,除了告诉服务器已经下载的大小,还会告诉服务器这个文件在上次暂停时最后修改的时间(服务器文件在这之后修改过的话时间就对不上了)或者整个文件的文件指纹(由文件大小和内容计算得出,就像指纹一样,内容不同的文件不会有一样的指纹)。
服务器比较之后决定是续传还是从头开始传输文件流给客户端,为了避免服务器端重新传输文件流而客户端认为是续传的文件流,从头开始下载的时候服务器会返回另一个表示「我很正常」状态码(200)。用 200、206 两个状态码即可保证客户端和服务器不会误解对方。

多线程下载加速的原理

多线程下载其实是利用断点续传的一个机智技巧,在说明为什么之前我们来做道简单的数学题(为方便理解设定 1M 带宽等于 1M/s 下载速度,实际下载速度应为 1/8 左右,同时所有人都有比下载速度高的带宽)。
一般的服务器(除去那些故意限制用户速度的)是通过同时下载的线程数平均分配下载带宽,假设一个服务器上的某个文件最高享有 100M 的带宽,同时有 50 个线程下载的时候每个线程分到的下载速度即是 2m/s。可是单纯的服务器认为一个人只能用一个线程来下载,怎想到其中 10 个线程都是同一个人用多线程下载器请求的,那这个人分到了多少下载速度?
20M/s!知道多线程下载为什么能够提升下载速度了吧,那么多线程实际上是怎样「欺骗」服务器的呢?答案是利用断点续传,简单来讲,一个 10 线程的下载器在接到下载一个文件的请求之后:
  • 首先做的就是向服务器请求这个文件的大小然后切成 10 份。
  • 接着每一个线程假装断点续传,分别在请求下载的请求头中告诉服务器我要从 1/10,2/10,3/10…9/10 开始下载,服务器天真地以为这真的是一个断点续传的请求于是便从这个线程要求的地方开始传输文件流。
  • 只需要 1/10 时间(完美情况下)文件已经下载完毕,下载器再在本地把这十块文件拼起来,一次机智的多线程下载就这样子完成啦。
多线程另外一个可以加快下载速度的原因是 TCP(Transmission Control Protocol 传输控制协议,HTTP 客户端与服务器传输数据的方法)设计之初非常为他人着想,能用少带宽办到的事情绝对不会申请更多的带宽,尽量留给其他人更多的带宽。这对于互联网环境当然是好事,但对于下载者来讲「舍己为人」可不行,于是人们开始利用多线程打破这个限制。

虽然多线程下载听起来很美好,但随着时间的推移,多线程下载的好处正变得越来越不明显。过去大家都在用单线程下载的时代,你用一个网络蚂蚁或者网际快车就能抢到能跑满宽带的带宽。现在大家都开始使用多线程下载器,甚至大部分浏览器都自带了多线程下载,比如前面的例子里面剩下的 49 个人也开始使用 10 线程的下载器,就算你仍然用多线程下载,分到的速度还是会变成 100M/500*10=2M/s,你再也不能比别人快上几倍了。

那设置更多的线程数能解决问题吗?能但是效果并不明显,因为传输和线程与服务器请求之间的损耗,除了加重服务器和自己设备内存的压力之外加速效果并不明显,得不偿失。另外,站长们也不是傻子,现在大多数服务器都加上了同一 IP 的线程限制,除非使用类似爬虫一般的代理下载不然达到限制之后再开多少线程都没用。按照目前的情况来讲 20–30 线程能达到一个比较好的加速效果,不过线程数也会「通货膨胀」,大家的确有需要的话再提高多线程下载器的线程哦。

专为传输文件的下载方式 —— FTP

ftp:// 开头的链接相信大家都见过,也下载过,感觉上和 HTTP 下载没有什么两样。那么你知道它和 HTTP 的区别吗?
要说他俩,那就要详细说一下前面提到的它俩的母亲 —— TCP 协议。
TCP 协议和我们熟悉的 IP 一起组成的 TCP/IP 协议族是互联网的基础,TCP 定义了数据如何传输,IP 定义了如何联系互联网上的设备。HTTP,FTP 和其他协议都是从它们身上延伸出来的,可以说 HTTP 和 FTP 是亲兄弟。
不过大哥可不是 HTTP。在 1991 年年轻的 HTTP0.9 初出茅庐然后华丽丽地被无视之前,FTP 已经活跃了十几年,事实上 FTP(1971) 比 HTTP(1989) 的诞生早了 18 年左右,甚至比现在定义的互联网出现的还要早!
大家知道互联网并不是世界上最早的网络吗?互联网的祖先 —— ARPAnet(Advanced Research Projects Agency Network,高等研究计划署网络,音译阿帕网)才是真正的始祖。这个网络采用的通信协议是 NCP(Network Control Program,网络控制程式),那个时候 TCP/IP 和 HTTP 还没影,基于 NCP 的 FTP 就已经出现了,作为阿帕网中计算机之间传输文件的协议。后来阿帕网逐渐变成互联网,NCP 也变成了 TCP/IP,FTP 才把底层协议换成 TCP。所以说,FTP 才是当之无愧的大哥。

最初的阿帕网只有 4 个节点,比现在一个宿舍的节点还少
虽然 HTTP 和 FTP 都是同一个协议拓展出来的,不过亲兄弟不一定是双胞胎。HTTP 多是针对为客户端提供文件传输;FTP 则是为了在特定主机之间相互传输文件而开发的标准(互联网出现之前还没有浏览器这种客户端)。
由于涉及到双向传输数据,因此在连接 FTP 服务器的时候我们必须通过用户名和密码认证自己的身份。

那为什么我们通过 FTP 下载的时候不用输入用户名和密码呢?因为密码是可选的,只要服务器以 Anonymous(中文:匿名)作为用户名,那么它储存的文件任何人都可以访问。
除了结构上有所不同以外,在下载时 HTTP 和 FTP 的方便性和下载时间是一模一样的,这意味着它们的优缺点也差不多。FTP 主要是一些需要在服务器上同时储存和交换大量文件的站点在使用,像是大名鼎鼎的电影天堂就以 FTP 作为下载他们电影的唯一方式(虚构链接,仅作展示):
ftp://ygdy8:ygdy8@yg45.dydytt.net:7080/[\*\*\*\*][English][1080p]The Story of SSpai.mkv
附上 FTP 链接的结构解释:
ftp://[用户名:口令@]ftp服务器域名或 IP:[端口号]/文件路径/文件名。
另外,在很多部电影特别是特工电影中都出现过 FTP 的身影,比如 Netflix 2017 年的电影《王牌保镖》(Hitman’s Bodyguard)第 98 分钟就出现了登录 FTP 输入密码的全过程。感兴趣的朋友可以看下这部电影。

《王牌保镖》片段
匿名 FTP 的特性还受到各个字幕组和游戏破解组的青睐,像是大名鼎鼎的游戏破解组 CPY 就是通过 FTP 发布新的破解游戏。

下节预告

这一节我们利用讲解互联网的基础下载方式来给大家热了热身。如果你觉得这节的货不够「干」,那么请准备好水和笔,因为下一节我们会正式走进现代最先进的下载方式,深入探讨各种各样的 P2P 下载原理(BT,PT 下载,eD2k,磁力,Metalink),绝对不容错过。

上一期
推荐序 | 下载时你考虑过隐私问题吗
下一期
答疑汇总 01
 
精选评论(11) 我的评论
  • 红亭下
    卡在百分之九十九点九,有时候改一下下载文件后缀名就好了
    05月10日
    • Fairyex 作者
      对于一些预写入的下载软件这样会造成最后一点点数据丢失
      05月10日
  • V1nc3k1
    很通俗易懂,虽然不是学这方面的专业,但是有点兴趣的小白也是能够理解到,很感谢作者的分享,也终于理解到运营商的百兆光纤和实际的网络是怎么一回事,很形象的解释了太过生硬的词。十分感谢!希望有还有更多的分享!
    02月01日
  • iD-NARUTO
    我想知道为什么迅雷在Windows下有时下到99.9就再也下不动了 是通过bt种子下的
    01月27日 1
    • Fairyex 作者
      分三种情况,如果你卡在 99.9%,点击暂停再开始可以瞬间下完的话,那就是做种者或者服务器想让你呆久点分享数据给别人(根据第三章说到的 BT 下载原理),防止你「下完就跑」。
      如果暂停再继续还是卡在 99.9%,要么是校验的时候发现某些下载的文件块错误需要后台重下(这时候利用网速监控软件是可以看到迅雷有下载速度的),要么就是你下的种子包含的是多个文件,其中有一个或者几个小文件没人做种了。
      基本上就这三种情况。
      01月27日 4
  • 无眼大兵
    如果能在文章的一些专业词汇上加一个可以另开页面跳转的超链接就更好了。
    01月11日 3
  • 常想一二
    既然提了电影,是不是应该把高清资源传到一个ftp服务器里,让我们自己尝试下载试一次,成功的人就拿电影资源当奖赏
    01月10日 1
    • Fairyex 作者
      你猜编辑会不会打死我(狗头)
      01月10日 1
  • davidzfr
    非常棒!一直知道1Byte=8bit,但从来不知道为啥,以及bit是传输数据的单位,byte是文件存储单位,现在明白了其中缘由!
    01月07日 1
  • Henrri
    下次连载是什么时间开始?
    01月07日
    • Fairyex 作者
      一周更新一期,一共 8 期哦
      01月07日
  • 暗樱花
    在家共享pc磁盘里的文件给手机,路由器是千兆,用微软的 SMB协议最多不超过10MB/s,自己用sver-u搭建了FTP服务器后速度就有30MB+/s了,不知是不是SMB协议的问题
    01月05日
    • Fairyex 作者
      你用 Windows 自带的 IIS 搭建 FTP 对比下就知道了
      01月05日
  • 清晨skit
    有什么好一点windows上的ftp客户端可以推荐吗?界面优秀一点的,uwp应用最好。
    01月04日
    • Fairyex 作者
      uwp 目前我是不知道有什么好用的,都太简陋了。Windows 老牌的 filezilla 或者界面(相对)好看点的 XFTP 都可以试一下。
      01月05日
  • Shaowen
    1、记得以前在学校用过一次FTP,印象中它的下载速度要远超HTTP,不知道是不是这样?

    2、FTP可以用在客户端上吗?那样的话,和HTTP有什么区别?

    3、FTP安全性怎么样?
    01月04日
    • Fairyex 作者
      1. 除非学校针对某个协议限速,不然差不多。还有个原因是 FTP 端口不容易被运营商限速(QOS)
      2. 可以,有很多很棒的 FTP 客户端,FTP 针对的是文件传输的稳定性与可靠性。
      3. 这个在之后的安全性章节会谈到,不过简单地说:不怎么样。
      01月04日
  • CYM
    不错不错,很通俗易懂,比喻也很形象,支持!
    01月04日 5