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
