使用multipart/form-data上传文件很简单,大多数情况下都能正常工作,直到您开始专注于上传大文件。如果我们仔细观察文件上传期间发生的情况:
客户端发送带有文件内容的POST请求
Web服务器接受请求并启动数据传输(如果文件大小超过限制,则返回错误413)
Web服务器开始填充缓冲区(取决于文件和缓冲区大小),将其存储在磁盘上,并通过套接字/网络发送到后端
后端验证身份验证(一旦文件上传完成,请查看)
后端读取文件并剪切几个标题Content-Disposition、Content-Type,再次将其存储在磁盘上,然后执行所有需要对文件进行的操作
为避免这样的开销,我们将文件转储到磁盘上(Nginx client_body_in_file_only),并管理回调以在后续处理中发送。然后队列工作程序会获取文件并执行所需操作。这对于服务器之间的通信非常顺畅,但我们必须解决客户端上传的类似问题。
我们还拥有客户端S3上传解决方案。没有后端交互发生。对于视频上传,我们使用Zencoder将视频转换为h.264基线/ AAC格式进行管理。目前我们使用基于s3-swf-upload-plugin的修改版Flash上传程序,结合非常高效但使用Flash的Zencoder JS SDK。
问题是如何使用HTML5文件上传程序实现相同的目标?Filepicker.io和Zencoder是否解决了这个问题?没有后端交互,推荐的管理HTML5文件上传的方式是什么?
要求如下:
- HTML5,不使用Flash - 上传视频并进行后处理以使其与HTML5播放器和移动设备兼容 - 上传图像并进行后处理(调整大小、裁剪、旋转) - 上传文档(如PDF)并具有预览功能。
client_body_in_file_only
不会导致更多的磁盘访问,从而降低性能吗?Nginx 文档说它主要用于调试。 - aergistal