[squid-users] why three connection attemps to the same IP ?

From: Adrian Buciuman <adibuciuman_at_gmail.com>
Date: Fri, 5 Feb 2010 19:28:54 +0200

Hi,

Running squid 2.6 STABLE 21 from Centos 5.

I've seen a issue with a site. The problem is that the browser locks
for some time, and only afterwards the user is able to interact with
the site. (The site has Flash based content or something similar). My
feeling is that this annoying delay is bigger when using squid than
when using direct connection to Internet. I believe the browser is
waiting for some tracking/adware gifs to load, and the webserver is
down. If using direct connection, the connection to the ads-server
will timeout in 20-30 seconds, the browser will display a
gif-placeholder, and the user can happily use the site (or they can
reload the page to see all the ads :-) ). If using squid, the timeout
will occur after a longer time.

I've used tcpdump to find how is squid managing timeouts and retries.
Is looks squid is retrying a TCP connection to the origin webserver
for 3 times.This retry happens even if the webserver has only one IP.
Each of the three connection attempts consists of multiple SYN sent.
In the default config, Squid will return a failure to the browser
after 3 minutes (connect_timeout is set to 1 minute)

I've made no tests in case of connection actively refused by the
webserver (tcp reset). I don't know if they are (and should be)
treated or not like a tcp timeout for the purpose of retrying.

Since TCP has its own built-in retry mechanism in case of failure to
respond to the initial SYN, the tcp stack would retry even if squid
made a single connection attempt per IP (in this case squid should
limit the number the IPs tried).

Workaround 1: lower the connect_timeout. For instance, to get a total
timeout of 30 seconds, set the connect_timeout to 10 seconds. The
problem with this is that if a web/ftp server is slow to respond to
SYN, the connection may fail.

Workaround 2: set both forward_timeout and connect_timeout to 30
seconds. The problem is that you miss the chance to try a second/third
IP.

The new option forward_max_tries set to 1 may solve this (haven't
tried) , but it has broader consequences and is not yet in stable
releases.

Thanks,

Adrian Buciuman
Received on Fri Feb 05 2010 - 17:28:58 MST

This archive was generated by hypermail 2.2.0 : Sat Feb 06 2010 - 12:00:03 MST