【发布时间】:2015-11-18 08:43:48
【问题描述】:
使用 multipart/form-data 上传文件非常简单,并且在您开始专注于大文件上传之前大部分时间都运行良好。如果我们look closely 在文件上传期间会发生什么:
客户端发送 POST 请求,其中包含 BODY 中的文件内容
webserver 接受请求并启动数据传输(如果文件大小超过限制,则返回错误 413)
webserver 开始填充缓冲区(取决于文件和缓冲区大小),将其存储在磁盘上并通过套接字/网络发送到后端
后端验证身份验证(文件上传后查看)
后端读取文件并剪掉几个头Content-Disposition,Content-Type,再次存储到磁盘上 后端执行您需要对文件执行的所有操作
为了避免这种开销,我们将文件转储到磁盘(Nginx client_body_in_file_only)并管理回调以进一步发送。然后队列工作人员拿起文件并执行所需的操作。它适用于非常流畅的服务器间通信,但我们必须解决客户端上传的类似问题。
我们还有客户端 S3 上传解决方案。没有后端交互发生。对于视频上传,我们使用 Zencoder 管理视频以转换为 h.264 Baseline / AAC 格式。
目前我们使用基于s3-swf-upload-plugin的修改过的Flash上传器,结合Zencoder JS SDK,效率很高但使用了Flash。
问题。如何使用 HTML5 文件上传器达到相同的目标? Filepicker.io and Zencoder 解决问题了吗?在没有后端交互的情况下管理 HTML5 文件上传的推荐方法是什么?
要求如下:
- HTML5,非 Flash
- 上传经过后处理的视频,使其与 HTML5 播放器和移动设备兼容
- 通过后处理(调整大小、裁剪、旋转)上传图片
- 使用预览功能上传 PDF 等文档
【问题讨论】:
-
我必须进行更多研究,但
client_body_in_file_only不会导致更多磁盘访问并因此降低性能吗? Nginx 文档说它应该主要用于调试。 -
@aergistal 不,它在我们的生产中工作了很多年,一切都很完美。我与 Nginx 核心团队的开发人员进行了交谈,他们确认它对于生产工作负载非常稳定。
标签: javascript html amazon-s3 upload filepicker.io