一. 简介
前端还在传文件给后端吗？你们的服务器扛得住吗？什么 …… 老板砸钱加机器？！告辞！/ 狗头
前后端文件传输波及数据较大，往往会成为很多我的项目的性能瓶颈。常见的传输方式也有不少，相对来说，OSS 直传可能加重很大压力。
本文咱们来列举下常见的和 oss 直传的几种传输方式，并列举其优劣。
二. 常见形式
1. 表单上传
表单上传文件是最常见的形式，前后端开发小伙伴都很轻松，前端哐哐传，后端哐哐收就成了。其过程如下图所示。
劣势：
- 简略不便，开发量小
- 前后端原生反对，无需额定第三方库反对
2. Base64 上传
Base64 形式上传文件，多常见于小文件，如小图片等，前后端都可间接应用 String 类型发送和接管。不过在前端，须要将文件转成 base64 数据，不仅会减少些性能耗费，还会减少传输数据的体积。而对于后端，如果并不是想间接存储 base64 数据，也还须要将其转成文件再存储，也会减少后端的性能耗费。
该上传形式可实用于Resetful Api，也可实用于文件的加密、回调接口携带文件等等。其过程如下图所示。
劣势：
- 实用于
Resetful Api，可用于加密、回调等场景，较为灵便
劣势：
- 前后端文件与 base64 数据转换须要耗费性能
- 只实用于小文件
三. OSS 直传
此处的 OSS 直传计划都是应用的阿里云的 OSS 产品，以下将介绍三个计划，可实用于不同的场景。
1. Browser.js SDK 上传
该计划可在前端间接通过 browser.js 上传文件到 OSS，可分成三步：
- 前端应用 SDK 直传 OSS
- 前端上传实现后申请后端，告诉上传实现
- 后端检测 OSS 上该文件是否存在（可选）
其流程如下图所示。
Browser.js的形式须要前端装置阿里云的库 ali-oss，而后在前端调用。直传还须要 OSS 账户的 Key 和 Secret，因而为了平安思考，须要建设 RAM 账户，而后前端向后端先申请一个STS 长期拜访凭证来实现直传，其流程如下图所示。
2. Javascript 客户端签名直传
Javascript 客户端签名直传，须要先从后端获取长期签名，其流程与上一步的 browser.js 计划大致相同，不同点在于：
- 无需第三方库反对，间接表单上传
- 原生反对后端上传回调（下一步骤讲述）
其流程如下图所示。
不过该计划做下来，我感觉最大的问题是权限配置有点麻烦 ……/ 泪眼
3. 服务端签名直传并设置上传回调
该计划其实是下面计划——Javascript 客户端签名直传的降级版本，其加上了后端的上传回调性能。不错呦～
前端须要改变的很少，只须要在申请参数中加上 callback 参数即可，该参数为后端加密，在签名申请的响应中一起返回回来，内加密了后端回调接口。在前端直传实现后，后端回调接口将会接管到相干文件参数，包含文件门路、大小、类型等。最初 OSS 会将回调接口 response 转发给前端，响应直传 OSS 的申请。
其流程如下图所示。
四. 比照
传统形式相比直传 OSS，相对来说有三个毛病：
- 上传慢：用户数据需先上传到应用服务器，之后再上传到 OSS。网络传输工夫比直传到 OSS 多一倍。如果用户数据不通过应用服务器直达，而是直传到 OSS，速度将大大晋升。而且 OSS 采纳 BGP 带宽，能保障各地各运营商之间的传输速度。
- 扩展性差：如果后续用户多了，应用服务器会成为瓶颈。
- 费用高：须要筹备多台应用服务器。因为 OSS 上传流量是收费的，如果数据直传到 OSS，不通过应用服务器，那么将能省下几台应用服务器。
当然，对于规模较小、老本较低的我的项目来说，常见的上传形式还是适宜的，毕竟没有最好的，只有最适宜的。
五. 参考文档
- Web 端上传介绍
- JavaScript 客户端签名直传
- 服务端签名直传并设置上传回调
六. 博客原文链接
- 我的博客