断点续传

1. 使用PHP的创始人 Rasmus Lerdorf 写的APC扩展模块来实现 （ http://pecl.php.net/package/apc ） APC 实现方法： 安装APC，参照官方文档安装，可以使用PECL模块安装方法快速简捷，这里不说明 配置php.ini，设置参数 apc.rfc1867=1 ，使APC支持上传进度条功能，在APC源码说明文档里面有说明 代码范例： 大文件（50G）上传的实现细节： 服务端接收文件数据的处理逻辑代码： 2. 使用PECL扩展模块uploadprogress实现 （ http://pecl.php.net/package/uploadprogress ） uploadprogress 模块实现方法： 使用PECL模块安装方法安装该模块 php.ini 里面设置 uploadprogress.file.filename_template = “/tmp/upd_%s.txt” 代码范例： 进度的处理逻辑比较简单，只是更新数据库中的数据就行了。不需要做其它的处理。 客户端代码如下： 服务端代码如下： 实现后的效果： 强大的文件夹上传，能够轻松支持10W级别的文件夹上传。 速度还不错 文件支持续传，支持刷新浏览器，关闭浏览器，重启电脑之后仍然能够续传。 可以参考这篇文章： http://blog.ncmem.com/wordpress

核心原理： 该项目核心就是文件分块上传。前后端要高度配合，需要双方约定好一些数据，才能完成大文件分块，我们在项目中要重点解决的以下问题。 * 如何分片； * 如何合成一个文件； * 中断了从哪个分片开始。 如何分，利用强大的js库，来减轻我们的工作，市场上已经能有关于大文件分块的轮子，虽然程序员的天性曾迫使我重新造轮子。但是因为时间的关系还有工作的关系，我只能罢休了。最后我选择了百度的WebUploader来实现前端所需。 如何合，在合之前，我们还得先解决一个问题，我们如何区分分块所属那个文件的。刚开始的时候，我是采用了前端生成了唯一uuid来做文件的标志，在每个分片请求上带上。不过后来在做秒传的时候我放弃了，采用了Md5来维护分块和文件关系。 在服务端合并文件，和记录分块的问题，在这方面其实行业已经给了很好的解决方案了。参考迅雷，你会发现，每次下载中的时候，都会有两个文件，一个文件主体，另外一个就是文件临时文件，临时文件存储着每个分块对应字节位的状态。 这些都是需要前后端密切联系才能做好，前端需要根据固定大小对文件进行分片，并且请求中要带上分片序号和大小。前端发送请求顺利到达后台后，服务器只需要按照请求数据中给的分片序号和每片分块大小（分片大小是固定且一样的）算出开始位置，与读取到的文件片段数据，写入文件即可。 为了便于开发，我 将服务端的业务逻辑进行了如下划分，分成初始化

一、概述 所谓断点续传，其实只是指下载，也就是要从文件已经下载的地方开始继续下载。在以前版本的HTTP协议是不支持断点的，HTTP/1.1开始就支持了。一般断点下载时才用到Range和Content-Range实体头。 HTTP协议本身不支持断点上传，需要自己实现。 二、Range 用于请求头中，指定第一个字节的位置和最后一个字节的位置，一般格式： Range:用于客户端到服务端的请求，可以通过改字段指定下载文件的某一段大小及其单位，字节偏移从0开始。典型格式： Ranges: (unit=first byte pos)-[last byte pos] Ranges: bytes=4000- 下载从第4000字节开始到文件结束部分 Ranges: bytes=0~N 下载第0-N字节范围的内容 Ranges: bytes=M-N 下载第M－N字节范围的内容 Ranges: bytes=-N 下载最后N字节内容 1.以下几点需要注意： (1)这个数据区间是个闭合区间，起始值是0，所以“Range: bytes=0-1”这样一个请求实际上是在请求开头的2个字节。 (2)“Range: bytes=-200”，它不是表示请求文件开始位置的201个字节，而是表示要请求文件结尾处的200个字节。 (3)如果last byte pos小于first byte pos

IE 的自带下载功能中没有断点续传功能，要实现断点续传功能，需要用到 HTTP 协议中鲜为人知的几个响应头和请求头。 一 . 两个必要响应头 Accept-Ranges 、 ETag 客户端每次提交下载请求时，服务端都要添加这两个响应头，以保证客户端和服务端将此下载识别为可以断点续传的下载： Accept-Ranges ：告知下载客户端这是一个可以恢复续传的下载，存放本次下载的开始字节位置、文件的字节大小； ETag ：保存文件的唯一标识（我在用的文件名 + 文件最后修改时间，以便续传请求时对文件进行验证）； Last-Modified ：可选响应头，存放服务端文件的最后修改时间，用于验证 二 . 一个重要请求头 Range Range ：首次下载时， Range 头为 null ，此时服务端的响应头中必须添加响应头 Accept-Ranges 、 ETag ； 续传请求时，其值表示客户端已经收到的字节数，即本次下载的开始字节位置，服务端依据这个 值从相应位置读取数据发送到客户端。 三 . 用于验证的请求头 If-Range 、 当响应头中包含有 Accept-Ranges 、 ETag 时，续传请求时，将包含这些请求头： If-Range ：对应响应头 ETag 的值； Unless-Modified-Since ：对应响应头 Last-Modified 的值。 续传请求时

需求： 项目要支持大文件上传功能，经过讨论，初步将文件上传大小控制在20G内，因此自己需要在项目中进行文件上传部分的调整和配置，自己将大小都以20G来进行限制。 PC 端全平台支持，要求支持Windows,Mac,Linux 支持所有浏览器。 支持文件批量上传 支持文件夹上传，且要求在服务端保留层级结构。文件夹数量要求支持到10W。 支持大文件断点续传，要求刷新浏览器，重启浏览器，重启电脑后仍然能够继续上传。文件大小要求能够支持到20个G。 支持自动加载本地文件，要求能够自动加载指定的本地文件。 支持文件批量下载，要求不要在服务器打包。因为20G的文件在服务器打包时间比较长。 支持文件夹下载，要求不要在服务器打包，下载到本地后要求保留层级结构 文件列表面板支持路径导航，新建文件夹 一. 大文件上传基础描述： 　　各种WEB框架中，对于浏览器上传文件的请求，都有自己的处理对象负责对Http MultiPart协议内容进行解析，并供开发人员调用请求的表单内容。 比如： Spring 框架中使用类似CommonsMultipartFile对象处理表二进制文件信息。 而.NET 中使用HtmlInputFile/ HttpPostedFile对象处理二进制文件信息。 优点：使用框架内置对象可以很方便的处理来自浏览器的MultiPart二进制信息请求，协议分析操作不用开发人员参与。 缺点

总结一下大文件分片上传和断点续传的问题。因为文件过大（比如1G以上），必须要考虑上传过程网络中断的情况。http的网络请求中本身就已经具备了分片上传功能，当传输的文件比较大时，http协议自动会将文件切片（分块），但这不是我们现在说的重点，我们要做的事是保证在网络中断后1G的文件已上传的那部分在下次网络连接时不必再重传。所以我们本地在上传的时候，要将大文件进行分片，比如分成1024*1024B，即将大文件分成1M的片进行上传，服务器在接收后，再将这些片合并成原始文件，这就是分片的基本原理。断点续传要求本地要记录每一片的上传的状态，我通过三个状态进行了标记（wait loading finish），当网络中断，再次连接后，从断点处进行上传。服务器通过文件名、总片数判断该文件是否已全部上传完成。 下面来说细节： 1、首先获取文件（音视频、图片） 分两种情况，一种是在相册库里直接获取，一种是调用相机。如果是通过UIImagePickerView来获取（细节不详述，网上一大堆），我们会发现当你选定一个视频的时候，会出现图1的压缩页面，最后我们的app获取的视频就是这个经过压缩后的视频（不是视频库里的原始视频，这里有个注意点，操作完该压缩视频后记得释放，系统不会帮你释放的，需要你手动来操作，下面会说到），然后通过UIImagePickerView的协议方法中的- ( void

需求：项目要支持大文件上传功能，经过讨论，初步将文件上传大小控制在500M内，因此自己需要在项目中进行文件上传部分的调整和配置，自己将大小都以501M来进行限制。 第一步： 前端修改 由于项目使用的是BJUI前端框架，并没有使用框架本身的文件上传控件，而使用的基于jQuery的Uploadify文件上传组件，在项目使用的jslib项目中找到了BJUI框架集成jQuery Uploadify的部分，这部分代码封装在bjui-all.js文件中， 在bjui-all.js文件中的全局变量定义中有以下部分代码，这就是定义的有关于上传的Uploadify控件的重要变量： // 文件上传对象 function FileUploader(fileLoc, mgr) { var _this = this ; this .id = fileLoc.id; this .ui = { msg: null , process: null , percent: null , btn: { del: null , cancel: null ,post: null ,stop: null }, div: null }; this .isFolder = false ; // 不是文件夹 this .app = mgr.app; this .Manager = mgr; // 上传管理器指针 this

需求： 支持大文件批量上传（20G）和下载，同时需要保证上传期间用户电脑不出现卡死等体验； 内网百兆网络上传速度为12MB/S 服务器内存占用低 支持文件夹上传，文件夹中的文件数量达到1万个以上，且包含层级结构。 支持PC端全平台操作系统，Windows,Linux,Mac 支持文件和文件夹的批量下载，断点续传。刷新页面后继续传输。关闭浏览器后保留进度信息。 支持文件夹批量上传下载，服务器端保留文件夹层级结构，服务器端文件夹层级结构与本地相同。 支持断点续传，关闭浏览器或刷新浏览器后仍然能够保留进度。 支持文件夹结构管理，支持新建文件夹，支持文件夹目录导航 交互友好，能够及时反馈上传的进度； 服务端的安全性，不因上传文件功能导致JVM内存溢出影响其他功能使用； 最大限度利用网络上行带宽，提高上传速度； 分析： 对于大文件的处理，无论是用户端还是服务端，如果一次性进行读取发送、接收都是不可取，很容易导致内存问题。所以对于大文件上传，采用切块分段上传 从上传的效率来看，利用多线程并发上传能够达到最大效率。 解决方案： 文件上传页面的前端可以选择使用一些比较好用的上传组件，例如百度的开源组件WebUploader，泽优软件的up6，这些组件基本能满足文件上传的一些日常所需功能，如异步上传文件，文件夹，拖拽式上传，黏贴上传，上传进度监控，文件缩略图，甚至是大文件断点续传，大文件秒传。

这里只写后端的代码，基本的思想就是，前端将文件分片，然后每次访问上传接口的时候，向后端传入参数：当前为第几块文件，和分片总数 下面直接贴代码吧，一些难懂的我大部分都加上注释了： 上传文件实体类： 看得出来，实体类中已经有很多我们需要的功能了，还有实用的属性。如MD5秒传的信息。 public class FileInf { public FileInf(){} public String id = "" ; public String pid = "" ; public String pidRoot = "" ; /** * 表示当前项是否是一个文件夹项。 */ public boolean fdTask = false ; // /// 是否是文件夹中的子文件 /// </summary> public boolean fdChild = false ; /** * 用户ID。与第三方系统整合使用。 */ public int uid =0; /** * 文件在本地电脑中的名称 */ public String nameLoc = "" ; /** * 文件在服务器中的名称。 */ public String nameSvr = "" ; /** * 文件在本地电脑中的完整路径。示例：D:\Soft\QQ2012.exe */ public String pathLoc = ""

文件夹数据库处理逻辑 public class DbFolder { JSONObject root; public DbFolder() { this .root = new JSONObject(); this .root.put( "f_id" , "" ); this .root.put( "f_nameLoc" , " 根目录" ); this .root.put( "f_pid" , "" ); this .root.put( "f_pidRoot" , "" ); } /** * 将JSONArray转换成map * @param folders * @return */ public Map<String, JSONObject> toDic(JSONArray folders) { Map<String, JSONObject> dt = new HashMap<String, JSONObject>(); for ( int i = 0 , l = folders.size();i<l;++i) { JSONObject o = folders.getJSONObject(i); String id = o.getString( "f_id" ); dt.put(id, o); } return dt; } public Map<String,