Requesting a Nginx Variable - "client_time_taken" (similar to request_time & upstream_response_time)

[Maxim Dounin]

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/