Is the limit_rate per tcp session or per HTTP request?

[Stefan Hellkvist]

On Mon, Dec 21, 2015 at 12:26 PM, Ruslan Ermilov <ru at nginx.com> wrote:

> On Mon, Dec 21, 2015 at 11:00:09AM +0100, Stefan Hellkvist wrote:
> > Hi,
> >
> > From reading the code and the docs I have gotten the impression that
> > limit_rate (and limit_rate_after) is per ngx_connection which (I think)
> > means that it is per HTTP request and not per socket. Am I right in this
> > conclusion or is the limit actually per socket/TCP connection?
>
> The docs at http://nginx.org/r/limit_rate says it clearly that the limit
> is set per a request, and describes one of the possible cases how this
> limit can be "avoided" by the client.
>
> The limit is implemented on the ngx_connection_t level which is usually
> mapped 1:1 to a physical connection.
>

In our case we have clients that use pipelining where several requests
share the same tcp session. An ngx_connection_t is mapped 1:1 to the
requests and not to the physical socket in this case, am I right?



>
> > If our conclusion are right - that the limit is per HTTP request and not
> > per socket so that a chunked download would not be limited - does anyone
> > have any suggestion how we would go about to introduce a limit also on
> > socket level? I don't mind hacking away at the code, but perhaps someone
> > out there has already looked into this?
>
> I know that Valentin (CC:ed) was working on the limit_rate module that
> improves things, including variables support and extening the limitation
> beyond only "per request".  It should become possible to limit byte rate
> per IP, for example.
>


That is great news that there is someone looking into it. Would this
limit_rate module also support limiting the rate in pipelined requests? The
use case I am looking at specifically is to control the download rate of a
client that pipelines requests for HLS chunks (Apple's HTTP live
streaming), so the same tcp connection is being used for several
downloadable chunks. I would need to have the limit_rate_after as it is
today, but on socket rather than http request, to allow the video buffer to
fill up quickly during the requests for the first chunks,  but would like
to limit the rate of the following pipelined request once the video
playback buffer is full.

In the wildest of dreams there would be an interface to nginx to
dynamically alter the rate of individual socket connections. through an
application interface. In that way it would be possible for the client to
actually signal to the server what rate it would need at certain phases.

/Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20151221/484c19f6/attachment.html>