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
lists@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 <emailgrant@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