本篇文章主要介绍了"断点续传 iOS 应用开发中的断点续传实践总结"，主要涉及到断点续传方面的内容，对于IOS开发感兴趣的同学可以参考一下：
断点续传概述断点续传就是从文件上次中断的地方开始重新下载或上传数据，而不是从文件开头。（本文的断点续传仅涉及下载，上传不在讨论之内）当下载大文件的时候，如果没有...
断点续传概述
断点续传就是从文件上次中断的地方开始重新下载或上传数据，而不是从文件开头。（本文的断点续传仅涉及下载，上传不在讨论之内）当下载大文件的时候，如果没有实现断点续传功能，那么每次出现异常或者用户主动的暂停，都会去重头下载，这样很浪费时间。所以项目中要实现大文件下载，断点续传功能就必不可少了。当然，断点续传有一种特殊的情况，就是 iOS 应用被用户 kill 掉或者应用 crash，要实现应用重启之后的断点续传。这种特殊情况是本文要解决的问题。
断点续传原理
要实现断点续传 , 服务器必须支持。目前最常见的是两种方式：FTP 和 HTTP。下面来简单介绍 HTTP 断点续传的原理。
HTTP
通过 HTTP，可以非常方便的实现断点续传。断点续传主要依赖于 HTTP 头部定义的 Range 来完成。具体 Range 的说明参见 RFC2616中 14.35.2 节，在请求某范围内的资源时，可以更有效地对大资源发出请求或从传输错误中恢复下载。有了 Range，应用可以通过 HTTP 请求曾经获取失败的资源的某一个返回或者是部分，来恢复下载该资源。当然并不是所有的服务器都支持 Range，但大多数服务器是可以的。Range 是以字节计算的，请求的时候不必给出结尾字节数，因为请求方并不一定知道资源的大小。Range 的定义如图 1 所示：
图 1. HTTP-Range
图 2 展示了 HTTP request 的头部信息：
图 2. HTTP request 例子
在上面的例子中的“Range: bytes=1208765-”表示请求资源开头 1208765 字节之后的部分。
图 3 展示了 HTTP response 的头部信息：
图 3. HTTP response 例子
上面例子中的”Accept-Ranges: bytes”表示服务器端接受请求资源的某一个范围，并允许对指定资源进行字节类型访问。”Content-Range: bytes 1208765-20489997/20489998”说明了返回提供了请求资源所在的原始实体内的位置，还给出了整个资源的长度。这里需要注意的是 HTTP return code 是 206 而不是 200。
断点续传分析 -AFHTTPRequestOperation
了解了断点续传的原理之后，我们就可以动手来实现 iOS 应用中的断点续传了。由于笔者项目的资源都是部署在 HTTP 服务器上 , 所以断点续传功能也是基于 HTTP 实现的。首先来看下第三方网络框架 AFNetworking 中提供的实现。清单 1 示例代码是用来实现断点续传部分的代码：
