Nginx的上传模块NginxHttpUploadProgressModule

Nginx提供了NginxHttpUploadProgressModule模块，用来处理文件上传的进度

它不是nginx内置的模块，编译时需要加上一下选项

–add-module=../nginx_uploadprogress_module

配置内容：

#开启上传进度，使用8M空间存储每个连接的进度信息

upload_progress proxied 8m;

#以/upload开头的为上传url

location ^~ /upload

{

#设置body最大值为100m

client_max_body_size 100m;

proxy_pass http://127.0.0.1:8080;

#此url需要跟踪进度信息，该信息在上传完成后会保留30秒

track_uploads proxied 30s;

}

location ^~ /att/progress {

#此url来获取进度信息

report_uploads proxied;

}

在使用该模块时，一点需要注意以下问题：

    track_uploads必须是location中最后一个指令，比如：它必须要放在proxy_pass的后边

    如果通过X-Progress-ID的get参数来获取进度信息，则它必须是url中最后一个参数，如：/progress?user=test&X-Progress-ID=123456

    必须设置client_max_body_size，它的值需要大于单次上传的最大值

    当nginx用作前端的proxy时，它默认会把当前request body的值给缓存到client_body_buffer_size或临时文件中，当client完成上传后，nginx才会把文件给push到后端的server，所以，没有办法从后端的服务器上来获得正确的进度信息，必须在前端的nginx上来配置upload选项





1. 假设用户执行一个上传文件操作，因为用户网速又比较慢，因此需要花半个小时才能把文件传到服务器。squid的同步代理在用户开始上传后就和后台建立了连接，半小时后文件上传结束，由此可见，后台服务器连接保持了半个小时；而nginx异步代理就是先将此文件收到nginx上，因此仅仅是nginx和用户保持了半小时连接，后台服务器在这半小时内没有为这个请求开启连接，半小时后用户上传结束，nginx才将上传内容发到后台，nginx和后台之间的带宽是很充裕的，所以只花了一秒钟就将请求发送到了后台，由此可见，后台服务器连接保持了一秒。同步传输花了后台服务器半个小时，异步传输只花一秒，可见优化程度很大。

2. 在上面这个例子中，假如后台服务器因为种种原因重启了，上传文件就自然中断了，这对用户来说是非常恼火的一件事情，想必各位也有上传文件传到一半被中断的经历。用nginx代理之后，后台服务器的重启对用户上传的影响减少到了极点，而nginx是非常稳定的并不需要常去重启它，即使需要重启，利用kill -HUP就可以做到不间断重启nginx。

3. 异步传输可以令负载均衡器更有保障，为什么这么说呢？在其它的均衡器（lvs/haproxy/apache等）里，每个请求都是只有一次机会的，假如用户发起一个请求，结果该请求分到的后台服务器刚好挂掉了，那么这个请求就失败了；而nginx因为是异步的，所以这个请求可以重新发往下一个后台，下一个后台返回了正常的数据，于是这个请求就能成功了。还是用用户上传文件这个例子，假如不但用了nginx代理，而且用了负载均衡，nginx把上传文件发往其中一台后台，但这台服务器突然重启了，nginx收到错误后，会将这个上传文件发到另一台后台，于是用户就不用再花半小时上传一遍。

4. 假如用户上传一个10GB大小的文件，而后台服务器没有考虑到这个情况，那么后台服务器岂不要崩溃了。用nginx就可以把这些东西都拦在nginx上，通过nginx的上传文件大小限制功能来限制，另外nginx性能非常有保障，就放心的让互联网上那些另类的用户和nginx对抗去吧。

用异步传输会造成问题：

后台服务器有提供上传进度的功能的话，用了nginx代理就无法取得进度，这个需要使用nginx的一个第三方模块来实现。