对象存储

  • 上传资源

    最近更新时间:2017-03-21 11:18:23

    表单上传

    表单上传是指在一个单一的 HTTP POST 请求中完成一个文件的上传,比较适合简单的应用场景和尺寸较小的文件。

    表单上传的使用细节请参考表单上传

    并发上传

    • 分片上传

      分片上传是将一个文件分为多个尺寸相同的小数据块,每个小数据块以一个独立的 HTTP 请求分别上传。所有小数据块都上传完成后,再发送一个请求给服务端将这些小数据块组织成一个逻辑资源,以完成上传过程。

      相比表单上传,分片上传的优势:

      • 适合尺寸较大的文件传输,通过分片来避免单个 HTTP 数据量过大而导致连接超时的现象。
      • 在网络条件较差的环境下,较小尺寸的文件可以有较高的上传成功率,从而避免无休止的失败重试。
      • 超过 4 MB大小的文件可以划分为多个 4 MB大小的数据块并发上传。
      • 支持断点续传。

        然而,相比表单上传,分片上传需要多次 HTTP 请求才能完成上传过程,会有额外的成本开销。另外也增加了代码的复杂度,因此选择是否使用分片上传时应谨慎评估使用的必要性。

        分片上传的使用细节请参考分片上传

    并发上传

    分片上传过程中每个块内部只能按顺序逐一上传该块所切分好的片。而每个块之间相互独立,因此若干个块可以同时进行传输而不会相互干扰,因此我们可以利用这个特征实现并发上传特性。

    每个文件理论上,最大并发上传数量对应该文件可划分的块数量。当然这个理论数量也受到很多其他因素的制约,例如像iOS限定了每个APP最多只能开4个并发HTTP连接,即在iOS上,无论有多少个块,最大的并发上传数量不可能超过4个。并不是并发数量越大上传速度就会越快。因此在实际开发中,通常会使用线程池(Thread Pool)技术来控制并发数量。

    断点续传

    虽然片的存在周期并非永久,但已足以实现断点续传机制。

    每成功上传一个片,客户端都会收到服务端返回一个代表当前已上传多少片的进度信息,我们称之为Context。上传下一个片时应提供前一个片上传成功后返回的Context。因此,这个Context可以认为是片传输进度的一个标记。

    如果上传过程中,服务端发现一个块已经被片数据装满,那么最后一个片上传成功后返回的Context将是一个特殊的值EOB,告诉客户端不要再往这个块附加更多的片。

    如果客户端在每次收到Context信息时都将其持久化到本地,即使客户端程序意外崩溃或正常重启,都可以在启动时读取上一次上传成功的片对应的Context,从而接着继续传输剩余片。这个效果我们称之为断点续传

    断点续上传功能对上传一个需要较长时间(例如一天时间才能上传完毕)的大文件很有价值,毕竟我们很难保证这段很长的时间内客户端都不会被关闭,且网络一直处于连接状态。当前主流的移动平台(iOS、Android、Windows Phone 8)都有监测非活动应用并自动将其关闭的功能,这意味着在移动平台上我们要上传一个大文件时更容易遇到中途程序突然被关闭的情况,断点续传也就更有价值。

    支持断点续传功能之后,在客户端很自然可以支持一个新功能:暂停或恢复某个文传的上传过程。

    上传后续动作

    在上传时开发者可以指定上传完成后服务端的后续动作,例如回调通知(callback)、自定义响应内容、303重定向等。可设置的后续动作与表单上传中完全一致。

    这里需要明确的是,虽然后续动作在生成上传凭证时已经指定,但这些后续动作只在服务端处理完创建文件(mkfile)请求后才会发生,而且也只有mkfile请求的内容可以包含变量

    在线示例

    在线断点继上传示例

    以上内容是否对您有帮助?
  • 提交工单