Hello!

On Mon, Oct 02, 2023 at 03:25:15PM +0530, Devarajan D via nginx wrote:

> > In general, $request_time minus $upstream_response_time is the
> > slowness introduced by the client.
>
> 1. It's true most of the time. But clients are not willing to
> accept unless they see a log from server side. (Say the client
> server itself is running in another hosing services like amazon
> EC2 instance)

Well, $request_time and $upstream_response_time are logs from
server side. Introducing yet another variable which will
calculate the difference just to convince your clients is not
something I would reasonably expect to happen.

> > Further, $request_time can be saved at various request
> > processing stages, such as after reading request headers via
> > the "set" directive, or via a map when sending the response
> > headers. This provides mostly arbitrary time measurements if
> > you need it.
>
> 2. How do we get control in nginx configuration when the last
> byte of request body is received from the client

In simple proxying configurations, nginx starts to read the
request body when control reaches the proxy module (so you can
save start time with a simple "set" in the relevant location), and
when the request body is completely read, nginx will create the
request to the upstream server (so you can save this time by
accessing a map in proxy_set_header).

> > For detailed investigation on what happens with the particular
> > client, debugging log is the most efficient instrument,
> > notably the "debug_connection" directive which makes it
> > possible to activate debug logging only for a particular client
>
> This debug log would definitely help to check the last byte of
> the request body !
>
> 3. But is it recommended to used nginx built with --with-debug
> in production environments

The "--with-debug" is designed to be used in production
environments. It incurs some extra costs, and therefore not the
default, and on loaded servers it might be a good idea to use
nginx compiled without "--with-debug" unless you are debugging
something. But unless debugging is actually activated in the
configuration, the difference is negligible.

> 4. We receive such slow requests infrequently. Enabling debug
> log is producing a huge amount of logs/per request (2MB of log
> file per 10 MB request body upload) and it becomes hard to
> identify the slow request in that. Thats why it is mentioned as
> no straightforward way to measure the time taken by client to
> send the request body completely. 

As previously suggested, using $request_time minus
$upstream_response_time (or even just $request_time) makes it
trivial to identify requests to look into.

> > > Is there a timeout for the whole request?
>
> 5. How to prevent attacks like slow-loris DDos from exhausting
> the client connections when using the open-source version.
> Timeouts such as client_body_timeout are not much helpful for
> such attacks.

Stopping DDoS attacks is generally a hard problem, and timeouts
are not an effective solution either. Not to mention that in many
practical cases total timeout on the request body reading cannot
be less than several hours, making such timeouts irrelevant.

For trivial in-nginx protection from Slowloris-like attacks
involving request body, consider using limit_conn
(http://nginx.org/r/limit_conn).

[...]

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx mailing list
nginx@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx