Seeing that nobody beat me to it, I did the download manager experiment. There are plugins for Chromium to do multiple connections, but I figured a stand alone program was safer. (No use adding strange software to a reasonable secure browser.)
My linux disty has prozilla in the repo. In true linux tradition, the actual executable is not prozilla but rather proz. I requested 8 connections, but I could never get more than 5 running at a time. I allow 10 in the setup, so something else is the limiting factor. Be that as it may, I achieved multiple connections, which is all that is required to test the rate limiting. Using proz, I achieved about 4Mbps when all connections were running. Just downloading from the browser, the network manager reports rates of 500k to 600k Bytes/second. Conclusion: nginx rate limiting is not "gamed" by using multiple connections to download ONE file using a file manager. The next experiment is to download two different files at 4 connections each with the file manager. I got 1.1mbps and 1.4mbps, which when summed together is actually less than the rate limit. Conclusion: nginx rate limiting still works with 8 connections. Someone else should try to duplicate this in the event it has something to do with my setup. On Mon, 12 Sep 2016 15:30:01 -0700 li...@lazygranch.com wrote: > Most of the chatter on the interwebs believes that the rate limit is > per connection, so if some IP opens up multiple connections, they get > more bandwidth. > > It shouldn't be that hard to just test this by installing a manager > and seeing what happens. I will give this a try tonight, but > hopefully someone will beat me to it. > > Relevant post follows: > ----------- > On 17 February 2014 10:02, Bozhidara Marinchovska > <quintessence at bulinfo.net> wrote: > > My question is what may be the reason when downloading the example > > file with download manager not to match limit_rate directive > > "Download managers" open multiple connections and grab different byte > ranges of the same file across those connections. Nginx's limit_rate > function limits the data transfer rate of a single connection. > > > http://mailman.nginx.org/pipermail/nginx/2014-February/042337.html > ------- > > Original Message > From: Richard Stanway > Sent: Monday, September 12, 2016 2:39 PM > To: nginx@nginx.org > Reply To: nginx@nginx.org > Subject: Re: limit-req and greedy UAs > > limit_req works with multiple connections, it is usually configured > per IP using $binary_remote_addr. See > http://nginx.org/en/docs/http/ngx_http_limit_req_module.html#limit_req_zone > - you can use variables to set the key to whatever you like. > > limit_req generally helps protect eg your backend against request > floods from a single IP and any amount of connections. limit_conn > protects against excessive connections tying up resources on the > webserver itself. > > On Mon, Sep 12, 2016 at 10:23 PM, Grant <emailgr...@gmail.com> wrote: > > https://www.nginx.com/blog/tuning-nginx/ > > > > I have far more faith in this write up regarding tuning than the > > anti-ddos, though both have similarities. > > > > My interpretation is the user bandwidth is connections times rate. > > But you can't limit the connection to one because (again my > > interpretation) there can be multiple users behind one IP. Think of > > a university reading your website. Thus I am more comfortable > > limiting bandwidth than I am limiting the number of > > connections. The 512k rate limit is fine. I wouldn't go any higher. > > > If I understand correctly, limit_req only works if the same connection > is used for each request. My goal with limit_conn and limit_conn_zone > would be to prevent someone from circumventing limit_req by opening a > new connection for each request. Given that, why would my > limit_conn/limit_conn_zone config be any different from my > limit_req/limit_req_zone config? > > - Grant > > > > Should I basically duplicate my limit_req and limit_req_zone > > directives into limit_conn and limit_conn_zone? In what sort of > > situation would someone not do that? > > > > - Grant > > _______________________________________________ > nginx mailing list > nginx@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx > > > _______________________________________________ > nginx mailing list > nginx@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx _______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
