iOS中如何提高上传大文件的效率

我有个需求是从iOS上传一个大约30MB左右的大文件到服务端，现在我就用了ASI的那个FormRequest，但是文件太大了，传起来超级慢，而且中间一旦出现问题，就得重新传输。
我现在想到两个优化的办法

1. 分割文件，并行传输。就是把大文件切割成5部分，然后同时运行五个异步进程，然后服务端再合并。但我有个担心是，iPhone真的可以并行处理5个上传链接吗？而且会不会受带宽影响，效率还不如一个文件传。
2. 另一个是断点续传，在时间上进行分割。但我没有找到什么好的断点方案，也没有思路，求一个思路或者方案。

---

断点的话，服务器纪录一个传递的文件偏移位置，每次请求从返回的head中读取偏移量，然后，客户端通过NSFileHandle通过偏移读取文件到buffer再发送到服务器。

	NSFileHandle *readHandle = [NSFileHandle fileHandleForReadingAtPath:filePath];
	[readHandle seekToFileOffset:offset];
    NSInputStream *fileStream = [NSInputStream inputStreamWithData:[readHandle readDataOfLength:1024*8]];

对于1,你切割成5个做异步，不如一个文件做断点，切割还增加了客户端和服务器对文件操作的开销。

---

请问七牛断点续传怎么写 ，，用cancellationSigna 返回YES 可以实现暂停继续，如果程序退出时，下次上传怎么续传呢

---

断点续传对客户端的要求不高，30MB其实是一个小文件，没必要起过多线程来做，这样对客户端的效率提升估计不是很大而且会导致server端的操作复杂。简单的方法就是@felix021说的,由server记录上次文件已传输并落地或者cache住的文件偏移，和客户端进行类似HTTP交互的一问一答即可，如果某次客户端上传失败，续传时先查询server就可以知道从哪里继续了。

---

断点续传需要什么特别的方案吗？不就是在服务器端记录一下上传进度，重传的时候找服务器要回来就行了。

---

七牛的做法是，服务端计算用户上传块的checksum和crc32值，每上传成功一个chunk就返回相应的上下文。客户端保存上下文进行断点续上传。

参考 API: http://docs.qiniutek.com/v3/api/io/#r...