http的文件上传和下载原理

目录

一：上传

1：http请求格式

2：文件上传类型分析

1：md5秒传

2：分片上传

1. 什么是分片上传

2. 分片上传的场景

3：断点续传

1. 什么是断点续传

2. 应用场景

3. 实现断点续传的核心逻辑

4. 实现流程步骤

二：下载原理

1：获取文件大小

2：文件下载

一：上传

1：http请求格式

        文件上传的是根据 http 协议的规范和定义，完成请求消息体的封装和消息体的解析，然后将二进制内容保存到文件。在上传一个文件时，需要把 form 标签的enctype设置为multipart/form-data,同时method必须为post 方法。

        请求头（注意这里的请求头并不是指http header）： Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryDCntfiXcSkPhS4PN 表示本 次请求要上传文件，其中 boundary 表示分隔符，如果要上传多个表单项，就要使用 boundary 分割， 每个表单项由———XXX 开始，以———XXX 结尾。

        消息体- Form Data 部分 每一个表单项又由Content-Type和Content-Disposition组成。 Content-Disposition: form-data 为固定值，表示一个表单元素，name 表示表单元素的 名称，回车换 行后面就是name的值，如果是上传文件就是文件的二进制内容。 Content-Type：表示当前的内容的 MIME 类型，是图片还是文本还是二进制数据。

        客户端发送请求到服务器后，服务器会收到请求的消息体，然后对消息体进行解析，解析出哪是普通表单哪些是附件。

2：文件上传类型分析

1：md5秒传

        通俗的说，你把要上传的东西上传，服务器会先做MD5校验，如果服务器上有一样的东西，它就直接给你个新地址，其实你下载的都是服务器上的同一个文件，想要不秒传，其实只要让MD5改变，就是对文件本身做一下修改（改名字不行），例如一个文本文件，你多加几个字，MD5就变了，就不会秒传了.

        秒传核心逻辑 ：a、利用redis的set方法存放文件上传状态，其中key为文件上传的md5，value为是否上传完成的标志 位， b、当标志位true为上传已经完成，此时如果有相同文件上传，则进入秒传逻辑。如果标志位为false， 则说明还没上传完成，此时需要在调用set的方法，保存块号文件记录的路径，其中key为上传文件md5 加一个固定前缀，value为块号文件记录路径

2：分片上传

1. 什么是分片上传

分片上传，就是将所要上传的文件，按照一定的大小，将整个文件分隔成多个数据块（我们称之为 Part）来进行分别上传，上传完之后再由服务端对所有上传的文件进行汇总整合成原始的文件。

2. 分片上传的场景

1. 大文件上传

2. 网络环境环境不好，存在需要重传风险的场景

3.大文件上传

        大文件上传一般采用分片上传的方式，这样可以提高文件上传的速度，前端拿到文件流后进行分片，然 后与后端进行通讯传输，一般还会结合断点继传，这时后端一般提供三个接口： 第一个接口获取已经上传的分片信息 第二个接口将前端分片文件进行传输 第三个接口是将所有分片上传完成后告诉后端进行文件合并。

3：断点续传

1. 什么是断点续传

        断点续传是在下载或上传时，将下载或上传任务（一个文件或一个压缩包）人为的划分为几个部分，每 一个部分采用一个线程进行上传或下载，如果碰到网络故障，可以从已经上传或下载的部分开始继续上 传或者下载未完成的部分，而没有必要从头开始上传或者下载。

2. 应用场景

        断点续传可以看成是分片上传的一个衍生，因此可以使用分片上传的场景，都可以使用断点续传。

3. 实现断点续传的核心逻辑

        在分片上传的过程中，如果因为系统崩溃或者网络中断等异常因素导致上传中断，这时候客户端需要记录上传的进度。在之后支持再次上传时，可以继续从上次上传中断的地方进行继续上传。 为了避免客户端在上传之后的进度数据被删除而导致重新开始从头上传的问题，服务端也可以提供相应 的接口便于客户端对已经上传的分片数据进行查询，从而使客户端知道已经上传的分片数据，从而从下 一个分片数据开始继续上传。

4. 实现流程步骤

a、方案一，常规步骤

将需要上传的文件按照一定的分割规则，分割成相同大小的数据块；

初始化一个分片上传任务，返回本次分片上传唯一标识；

按照一定的策略（串行或并行）发送各个分片数据块；

发送完成后，服务端根据判断数据上传是否完整，如果完整，则进行数据块合成得到原始文件。

b、方案二、实现的步骤

        前端（客户端）需要根据固定大小对文件进行分片，请求后端（服务端）时要带上分片序号和大小；

        服务端创建conf文件用来记录分块位置，conf文件长度为总分片数，每上传一个分块即向conf文件 中写入一个127，那么没上传的位置就是默认的0,已上传的就是Byte.MAX_VALUE 127（这步是实 现断点续传和秒传的核心步骤）；

        服务器按照请求数据中给的分片序号和每片分块大小（分片大小是固定且一样的）算出开始位置， 与读取到的文件片段数据，写入文件。

二：下载原理

1：获取文件大小

在具体的HTTP交互中，客户端是如何获取消息长度的呢?

主要基于以下几个规则：

响应为1xx，204，304相应或者head请求，则直接忽视掉消息实体内容。

如果有Transfer-Encoding，则优先采用Transfer-Encoding里面的方法来找到对应的长度。比如说 Chunked模式。

“如果head中有Content-Length，那么这个Content-Length既表示实体长度，又表示传输长度。如果实体长度和传输长度不相等(比如说设置了Transfer-Encoding)，那么则不能设置Content Length。如果设置了Transfer-Encoding，那么Content-Length将被忽视”。其实关键就一点：有了Transfer-Encoding，则不能有Content-Length。

通过服务器关闭连接能确定消息的传输长度。(请求端不能通过关闭连接来指明请求消息体的结束， 因为这样可以让服务器没有机会继续给予响应)。这种情况主要对应为短连接，即非keep-alive模 式。

HTTP1.1必须支持chunk模式。因为当不确定消息长度的时候，可以通过chunk机制来处理这种情况。

在包含消息内容的header中，如果有content-length字段，那么该字段对应的值必须完全和消息主 题里面的长度匹配。

其实后面几条几乎可以忽视，简单总结后如下：

1、Content-Length如果存在并且有效的话，则必须和消息内容的传输长度完全一致。(经过测试，如果 过短则会截断，过长则会导致超时。)

2、如果存在Transfer-Encoding(重点是chunked)，则在header中不能有Content-Length，有也会被忽视。

3、如果采用短连接，则直接可以通过服务器关闭连接来确定消息的传输长度。(这个很容易懂) 结合HTTP协议其他的特点，比如说Http1.1之前的不支持keep alive。

那么可以得出以下结论：

1、在Http 1.0及之前版本中，content-length字段可有可无。

2、在http1.1及之后版本。如果是keep alive，则content-length和chunk必然是二选一。若是非keep alive，则和http1.0一样。content-length可有可无。

2：文件下载

对于HTTP协议，向服务器请求某个文件时，只要发送类似如下的请求即可：

 GET /Path/FileName HTTP/1.0
 Host: www.baidu.com:80
 Accept: */*
 User-Agent: GeneralDownloadApplication
 Connection: close

第一行中的GET是HTTP协议支持的方法之一，方法名是大小写敏感的。每行用一个“回车换行”分隔，末尾再追加一个“回车换行”作为整个请求的结束。

除第一行以外，其余行都是HTTP头的字段部分。Host字段表示主机名和端口号，如果端口号是默认的 80则可以不写。Accept字段中的/表示接收任何类型的数据。User-Agent表示用户代理，这个字段可有可无，但强烈建议加上，因为它是服务器统计、追踪以及识别客户端的依据。Connection字段中的 close表示使用非持久连接。

如果服务器成功收到该请求，并且没有出现任何错误，则会返回类似下面的数据：

 HTTP/1.0 200 OK
 Content-Length: 13057672
 Content-Type: application/octet-stream
 Last-Modified: Wed, 10 Oct 2005 00:56:34 GMT
 Accept-Ranges: bytes
 ETag: "2f38a6cac7cec51:160c"
 Server: Microsoft-IIS/6.0
 X-Powered-By: ASP.NET
 Date: Wed, 16 Nov 2005 01:57:54 GMT
 Connection: close

        第一行是协议名称及版本号，空格后面会有一个三位数的数字，是HTTP协议的响应状态码，200表示成 功，OK是对状态码的简短文字描述。状态码共有5类： 1xx属于通知类； 2xx属于成功类； 3xx属于重定向类； 4xx属于客户端错误类； 5xx属于服务端错误类。

        对于状态码，相信大家对404应该很熟悉，如果向一个服务器请求一个不存在的文件，就会得到该错误，通常浏览器也会显示类似“HTTP 404 - 未找到文件”这样的错误。

        第二行Content-Length字段是一个比较重要的字段，它标明了服务器返回数据的长度，这个长度是不包 含HTTP头长度的。换句话说，我们的请求中并没有Range字段（后面会说到），表示我们请求的是整个文件，所以Content-Length就是整个文件的大小。

        其余各字段是一些关于文件和服务器的属性信息。 这段返回数据同样是以最后一行的结束标志（回车换行）和一个额外的回车换行作为结束，即 “\r\n\r\n”。而“\r\n\r\n”后面紧接的就是文件的内容了，这样我们就可以找到“\r\n\r\n”，并从它后面的 第一个字节开始，源源不断的读取，再写到文件中了。

        以上就是通过HTTP协议实现文件下载的全过程。但还不能实现断点续传，而实际上断点续传的实现非常简单，只要在请求中加一个Range字段就可以了。

        假如一个文件有1000个字节，那么其范围就是0-999，则： Range: bytes=500- 表示读取该文件的500-999字节，共500字节。 Range: bytes=500-599 表示读取该文件的500-599字节，共100字节。 如果HTTP请求中包含Range字段，那么服务器会返回206（Partial Content），同时HTTP头中也会有一 个相应的Content-Range字段，类似下面的格式： Content-Range: bytes 500-999/1000 Content-Range字段说明服务器返回了文件的某个范围及文件的总长度。这时Content-Length字段就不是整个文件的大小了，而是对应文件这个范围的字节数，这一点一定要注意。

0voice · GitHub