论文部分内容阅读
网上的资源体积越来越“臃肿”，想要用小水管一次下载完想要的东西是越来越难了。正是“断点续传”这么一个方便却不起眼的功能让“前功尽弃”这个词在下载时没了用处。其实，别小看这么个小功能，它背后的学问还是不小哩。
一问一答——最常见的断点续传
不管是文件复制还是下载，也不管是使用什么协议，神奇的断点续传需要具备两个重要的要素：服务器端的支持和下载客户端（或者复制软件）的支持，缺少其中任何一个都不能断点续传。在“早年”BT等P2P传输方式还没有流行起来之前，HTTP协议几乎是互联网上垄断型的文件传输方式。像网络蚂蚁、FlashGet等一批老牌下载软件，正是因为浏览器作为客户端不支持“断点续传”，而在那个时代呼风唤雨。在HTTP协议下，断点续传的两个要素体现得非常明显，整个过程就像是客户端和服务器端的一问一答（见图1）。比如要从www.cfan.com.cn下载文件Cfan.zip的话，“对话”如下：
客户端我想要下载Cfa.zip文件，使用Http1.1协议
服务器端服务器已经成功处理了请求的信息
你要下载的文件的总长度是9002字节
之后下载Cfan.zip的过程就开始了，服务器会不断地传输数据，客户端则在接受数据的同时，不断记录下已经完成的字节数。假设在接收了2009字节之后下载中断，在需要重启传输的时候，“对话”如下：
客户端 我想要下载Cfan.zip文件，使用Http1.1协议
这个文件的前2009个字节我已经有了，不用再传了
服务器端 服务器已经成功处理了部分请求
你要下载的文件的总长度是9002字节
服务器将不传输所有9002字节中的前2009字节
自言自语——古老的“断点续传”
作为名字里面就带着与生俱来的职责的FTP协议（FTP是File Transfer Protocol，文件传输协议，说明天生它就是干这个的），虽然相当古老，但现今在一些0day组织交流原始资源的时候还在广泛使用，而对断点续传，许多的老牌FTP软件如FlashFXP、CuteFTP等也有着很好的支持。
当FTP客户端要进行断点续传的时候，整个过程基本上就是客户端不断地自说自话（见图2），服务器端点头同意（返回代表成功的2xx信息）或者摇头否决（返回代表失败的4xx或5xx信息）的过程。客户端主要使用的是retr和rest这两个命令，前者告诉服务器端要传输的是哪个文件，后者告诉服务器断点的位置。整个过程中客户端同样会监视已下载的字节数。例如在下载Cfan.zip文件的时候中断，前2009字节已经传输，则重启传输时客户端发送的信息就是：
“我的用户名是xxxx，密码是xxxx”
……
“服务器，前2009个字节不用传输了”
“我要下载的文件是Cfan.zip”
客户端在说完“一句话”之后，会在服务器点头同意（返回2xx）之后才“说”下一句。之所以先报告断点再说要下载的文件，是因为在FTP协议中，rest 0命令会紧接着pass命令发出，用来测试服务器是否支持断点续传。
文件复制——延伸中的“断点续传”
在TB级别的硬盘已经开始普及的今天，复制或者移动几十GB的数据越来越平常。因此一些“专攻”文件复制的软件，比如Total Copy、Copy Handler等等，也像下载工具一样提供了文件复制时的断点续传功能。这些软件在复制文件的过程中，也会不断地记录下正在复制的文件名称、目标路径以及最重要的——复制完成的字节数。一旦出现了复制过程中断，重启复制进程之后便会首先检查这些记录下来的信息，并且根据记录中已经完毕的字节数，从中断点开始传输。在使用“网络邻居”等局域网功能时，这种“断点续传”就显得尤其实用了。
一问一答——最常见的断点续传
不管是文件复制还是下载，也不管是使用什么协议，神奇的断点续传需要具备两个重要的要素：服务器端的支持和下载客户端（或者复制软件）的支持，缺少其中任何一个都不能断点续传。在“早年”BT等P2P传输方式还没有流行起来之前，HTTP协议几乎是互联网上垄断型的文件传输方式。像网络蚂蚁、FlashGet等一批老牌下载软件，正是因为浏览器作为客户端不支持“断点续传”，而在那个时代呼风唤雨。在HTTP协议下，断点续传的两个要素体现得非常明显，整个过程就像是客户端和服务器端的一问一答（见图1）。比如要从www.cfan.com.cn下载文件Cfan.zip的话，“对话”如下：
客户端我想要下载Cfa.zip文件，使用Http1.1协议
服务器端服务器已经成功处理了请求的信息
你要下载的文件的总长度是9002字节
之后下载Cfan.zip的过程就开始了，服务器会不断地传输数据，客户端则在接受数据的同时，不断记录下已经完成的字节数。假设在接收了2009字节之后下载中断，在需要重启传输的时候，“对话”如下：
客户端 我想要下载Cfan.zip文件，使用Http1.1协议
这个文件的前2009个字节我已经有了，不用再传了
服务器端 服务器已经成功处理了部分请求
你要下载的文件的总长度是9002字节
服务器将不传输所有9002字节中的前2009字节
自言自语——古老的“断点续传”
作为名字里面就带着与生俱来的职责的FTP协议（FTP是File Transfer Protocol，文件传输协议，说明天生它就是干这个的），虽然相当古老，但现今在一些0day组织交流原始资源的时候还在广泛使用，而对断点续传，许多的老牌FTP软件如FlashFXP、CuteFTP等也有着很好的支持。
当FTP客户端要进行断点续传的时候，整个过程基本上就是客户端不断地自说自话（见图2），服务器端点头同意（返回代表成功的2xx信息）或者摇头否决（返回代表失败的4xx或5xx信息）的过程。客户端主要使用的是retr和rest这两个命令，前者告诉服务器端要传输的是哪个文件，后者告诉服务器断点的位置。整个过程中客户端同样会监视已下载的字节数。例如在下载Cfan.zip文件的时候中断，前2009字节已经传输，则重启传输时客户端发送的信息就是：
“我的用户名是xxxx，密码是xxxx”
……
“服务器，前2009个字节不用传输了”
“我要下载的文件是Cfan.zip”
客户端在说完“一句话”之后，会在服务器点头同意（返回2xx）之后才“说”下一句。之所以先报告断点再说要下载的文件，是因为在FTP协议中，rest 0命令会紧接着pass命令发出，用来测试服务器是否支持断点续传。
文件复制——延伸中的“断点续传”
在TB级别的硬盘已经开始普及的今天，复制或者移动几十GB的数据越来越平常。因此一些“专攻”文件复制的软件，比如Total Copy、Copy Handler等等，也像下载工具一样提供了文件复制时的断点续传功能。这些软件在复制文件的过程中，也会不断地记录下正在复制的文件名称、目标路径以及最重要的——复制完成的字节数。一旦出现了复制过程中断，重启复制进程之后便会首先检查这些记录下来的信息，并且根据记录中已经完毕的字节数，从中断点开始传输。在使用“网络邻居”等局域网功能时，这种“断点续传”就显得尤其实用了。