<div dir="ltr">It is true that the best way to rate limit is the sender. But in the event where the sender is a myriad different browsers, that isn't an option. There is no control at the POST level to throttle an upload. There isn't really any good firewall tool for traffic shaping incoming data per tcp stream either. You can traffic shape to a port, but not as easily per stream.<div><br></div><div>For a particular application I'd like to simulate the effect of uploading at a specific rate. Since I got the desired effect by crudely limiting the rate at which nginx reads its input socket (with usleep) it seemed possible that a mirror of the limit_rate code for sending could be applied to reading as well.</div><div><br></div><div>It wouldn't be ideal, but if the server was dedicated to this and not other things, I'm not sure it would have any disastrous effects?</div><div><br></div><div>thanks</div><div>-Justin</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 14, 2015 at 3:03 AM, B.R. <span dir="ltr"><<a href="mailto:reallfqq-nginx@yahoo.fr" target="_blank">reallfqq-nginx@yahoo.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">I do not get (aha) where you saw limit_rate only applies to the GET method...<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">But yeah limit_rate applies to resposnes.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)"><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">Rate limiting only properly applies to sender, in your case the client, which is the sole entity ablte to properly craft its requests to contain a specified amount of data/time period.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">​The only thi​ng you can limit on intermediaries/receiver is connections/packets, because it is network-related structures which are trivial to handle/buffer.<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">Rate-limiting on a transmitting/receiving end requires buffering content (not envelope, so that means application logic/DPI), and re-crafting forwarded/processed content into suitable network envelopes.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">Way too expensive/dangerous/demanding.<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">You can limit incoming transmissions in nginx based on connections (limit_conn) or requests (limit_req).<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">You can limit incoming transmissions at TCP level in firewalls surch as iptables based on connections and/or packets.<br></div><br><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">​My 2 cents,​</div><div class="gmail_extra"><div><div><font size="1"><span style="color:rgb(102,102,102)">---<br></span><b><span style="color:rgb(102,102,102)">B. R.</span></b><span style="color:rgb(102,102,102)"></span></font></div></div><div><div class="h5">
<br><div class="gmail_quote">On Sat, Apr 11, 2015 at 2:25 PM, Justin <span dir="ltr"><<a href="mailto:justinbeech@gmail.com" target="_blank">justinbeech@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">hmm that is rate limiting req/s<br>
<br>
i am looking for an exact limit_rate equivalent  - which is bytes/second.<br>
<div><div><br>
> On 11 Apr 2015, at 10:13 pm, itpp2012 <<a href="mailto:nginx-forum@nginx.us" target="_blank">nginx-forum@nginx.us</a>> wrote:<br>
><br>
> Lua would be a way to go,<br>
> ea. <a href="https://github.com/fanhattan/lua-resty-rate-limit" target="_blank">https://github.com/fanhattan/lua-resty-rate-limit</a><br>
><br>
> Posted at Nginx Forum: <a href="http://forum.nginx.org/read.php?2,257905,257965#msg-257965" target="_blank">http://forum.nginx.org/read.php?2,257905,257965#msg-257965</a><br>
><br>
> _______________________________________________<br>
> nginx mailing list<br>
> <a href="mailto:nginx@nginx.org" target="_blank">nginx@nginx.org</a><br>
> <a href="http://mailman.nginx.org/mailman/listinfo/nginx" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a><br>
<br>
_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org" target="_blank">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a><br>
</div></div></blockquote></div><br></div></div></div></div>
<br>_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a><br></blockquote></div><br></div>