On Sun, 10 Jan 2021 at 00:00, Daniel Stenberg <dan...@haxx.se> wrote: > - Users expect the timeout to expire after the given time, so if the host has > N addresses, they still don't want the timeout to be multiplied with N.
This is true if we are talking about "timeout", which should refer to the timeout as a whole. But we are talking about "connection timeout" here, most people would assume it is per connection. People set timeout as a whole because any longer than that won't work for their use case. However, we are setting the connection timeout, mostly, because we don't want to waste more time on a hopeless connection. This is still opinion-based, but it probably accurate. If that is the case, I see no conflict here, just different features for different scenarios. > (Once I attended a meeting with lots of HTTP people, where it was suggested > that maybe clients would be better off happy-eyevalling *every* IP address > that is returned - connect to all of them at once and stick only to the one > that connects the fastest... which would also solve this timeout issue!) I guess that would work too, only if DDoS appliances don't see it as a SYN flood. > So what does nginx do when the first IP address just silently drops all TCP > packets? Fail the connection after one second even if there are also 9 working > IP addresses? It will try the next one. I witnessed this myself; the source (origin server) is not dropping packets; it is down entirely. So, no refusal packet or any kind of packet reply to SYN request possible. (Dropping packets would work the same way.) Nginx will retry for the next IP address if the DNS returns multiple addresses. I am not sure if it will continue to 9, but definitely for 2. So the connection timeout is per connection. ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html