断点续传

Flume高可用集群 工欲善其事，必先利其器。 感谢以下博主： https://www.cnblogs.com/qingyunzong/p/8994494.html https://blog.csdn.net/peng_0129/article/details/80793440 https://blog.csdn.net/suojie123/article/details/86577935 https://blog.csdn.net/kelong_xhu/article/details/42677045 https://blog.csdn.net/johnnychu/article/details/82780521 flume简介 官网：http://flume.apache.org/ 打开官网【经翻译】 Flume is a distributed, reliable, and available service for efficiently collecting, aggregating, and moving large amounts of log data. It has a simple and flexible architecture based on streaming data flows. It is robust and fault tolerant

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 的值。 续传请求时

View Code 1 using System; 2 using System.IO; 3 using System.Net; 4 using System.Text; 5 using System.Security; 6 using System.Threading; 7 using System.Collections.Specialized; 8 using Sort; 9 10 namespace Sort 11 { 12 // <summary> 13 /// 记录下载的字节位置 14 /// </summary> 15 public class DownLoadState 16 { 17 private string _FileName; 18 19 private string _AttachmentName; 20 private int _Position; 21 private string _RequestURL; 22 private string _ResponseURL; 23 private int _Length; 24 25 private byte[] _Data; 26 27 /// <summary> 28 /// 文件名 29 /// </summary> 30 public string FileName 31 { 32 get 33

在了解HTTP断点续传的原理之前，让我们先来了解一下HTTP协议，HTTP协议是一种基于tcp的简单协议，分为请求和回复两种。请求协议是由客户机(浏览器)向服务器（WEB SERVER）提交请求时发送报文的协议。回复协议是由服务器(web server)，向客户机(浏览器)回复报文时的协议。请求和回复协议都由头和体组成。头和体之间以一行空行为分隔。 　　 以下是一个请求报文与相应的回复报文的例子： GET /image/index_r4_c1.jpg HTTP/1.1 Accept: */* Referer: http://192.168.3.120:8080 Accept-Language: zh-cn Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705) Host: 192.168.3.120:8080 Connection: Keep-Alive HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 Date: Tue, 24 Jun 2003 05:39:40 GMT Content-Type: image/jpeg Accept-Ranges: bytes Last

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

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

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

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

java 两台服务器之间，大文件上传（续传），采用了 Socket 通信机制以及 JavaIO 流两个技术点，具体思路如下： 实现思路： 1 、服：利用 ServerSocket 搭建服务器，开启相应端口，进行长连接操作 2 、服：使用 ServerSocket.accept() 方法进行阻塞，接收客户端请求 3 、服：每接收到一个 Socket 就建立一个新的线程来处理它 4 、客：利用 Socket 进行远程连接，询问已上传进度 5 、客：使用 FileInputStream.skip(long length) 从指定位置读取文件，向服务器发送文件流 6 、服：接收客户端输入流，使用 RandomAccessFile.seek(long length) 随机读取，将游标移动到指定位置进行读写 7 、客 / 服：一个循环输出，一个循环读取写入 8 、示例：以下是具体代码，仅供参考 文件介绍： FileUpLoadServer.java （服务器接收文件类） FileUpLoadClient.java （客户端发送文件类） FinalVariables.java （自定义参数类） SocketServerListener.java （ JavaWeb 启动 Socket 操作类） web.xml （配置文件，跟随项目启动） 断点上传（服务端） package com . cn .

今天用别人封装的libcurl库下载文件，发现下载下来的文件总是缺少头两个字节，用以下配置启用HTTP头信息打印后发现原来是设置了断点续传位置的原因 curl_easy_setopt(m_pCurl, CURLOPT_VERBOSE, 1L); 故了解了一下HTTP断点续传的相关设置 参考文章： 1、 HTTP Header里的Range和Content-Range参数 2、 http断点续传原理：http头 Range、Content-Range 3、 Libcurl实现断点续传 来源： https://www.cnblogs.com/jixiaohua/p/12187052.html