[squid-users] parameter forward_max_retries

[Amos Jeffries]

On 3/06/19 9:20 pm, Niu, Steven (NSB - CN/Qingdao) wrote:
> Hello,  
> 
> I'm sorry for any bother to you. But we are evaluating our solutions and need author's confirmation about the parameter forward_max_retries. 


Then you had best contact the author. This is a mailing list for *users*
of Squid to discuss and learn about the software from each other, and
from those developers like myself who participate here.

AFAIK neither the developer who designed the feature, nor the developer
who re-designed it to operate differently participate in this mailing list.


> Could you give me a yes or no if you have clear answer? I appreciate you response very much! Thank you!
> 
> If the configuration parameter of forward_max_retries is 3, for the following cases, is the assumption true or false? 
> Case 1:  FQDN has 4 IPs from DNS result: ip1, ip2, ip3, ip4. 
> 	If ip1, ip2, ip3 are failed, Squid would not try ip4 since forward_max_retries is 3. 
> Case 2:  FQDN has 2 IPs from DNS result: ip1, ip2. 
> 	If ip1, ip2 are failed, Squid would give final response since no more IP can try. 
> 

The answer depends on which version of Squid you are using, what those
IPs are, what type of HTTP message is being attempted, and how long the
process is taking.


In regards to Squid version:

* The initial design used (n_tries > forward_max_tries). Squid up to
v4.0 use this.

* The redesigned code uses (n_tries >= forward_max_tries). Squid v4 and
later use this.

=> Both versions prevent destinations being contacted when their
expression produces the "true" boolean result.


In regards to IPs:

* Squid which are built with IPv6 disabled completely ignore IPv6
results from DNS. They are not considered in the retries list.

* If the failure occurs at the TCP connect(2) level, then Squid-3.1 and
older do not count these as tries and will attempt all IPs
forward_max_tries times. Squid-3.2 and later will count them as tries.


Please also be aware that many popular websites have dozens of IPs in
their DNS responses. Setting forward_max_tries less than 20 can result
in these very popular websites not being contactable.


In regards to HTTP message type:

* HTTP standards specify some request methods as non-idempotent.
Retrying these requests is forbidden.

* HTTP standards define some response status codes as final and fatal.
These cannot ever be retried by an intermediary.

* HTTP transactions which involve certain stateful application layer
features which break HTTP requirements about statelessness cannot be
retried.
 ==> These features impact retry behaviour of the TCP connection itself.
So the non-retry outcome can be inherited from some past HTTP
transaction(s) activity.

* Any HTTP request with a payload that has begun delivery cannot be retried.

* Any HTTP response which began but did not completely arrive cannot be
retried.


In regards to timing:

* timeouts for TCP connect action, TCP lifetimes, HTTP forwarding, and
I/O actions can terminate any given tries early and cause later ones to
not happen.

* TCP error handling is subject to ICMP (both v4 and v6) being enabled
and working on your network and on *every* network between your proxy
and the origin serves (both outbound and inbound routes).
 -> without ICMP the TCP errors result in 'hung' connections which
usually hit timeout errors before the forwarding re-tries succeed.


Overall;

  Squid always give a final response when that final response is known.
Where that response comes from is far more complicated than your stated
cases consider.


Have you tried testing for yourself the particular sites you are worried
about?

Amos