On 20/04/2013 5:34 p.m., Marcin Czupryniak wrote:
Hello all!,
checking my logs from time to time I see that there are some requests
which return the TCP_MISS/000 log code, I'm managing a medium sized
Active-Standby transparent caching proxy (direct routing) which is
handling around 100 requests per second (average on daily basis), I
know what the entry means but I'm not exactly sure whether under
normal operating conditions they are normal to see in such amount.
The number of these entries is less than 0,001% of total requests
served (avg 1 entry per 10 seconds), should I worry about it or others
get them too?
How long a duration do they show? any consistency to the type of
requests? is there
In normal traffic this could be the result of:
* DNS lookup failure/timeout.
Identified by the lack of upstream server information on the log line.
This is very common as websites contain broken links, broken XHR
scripts, and even some browsers send garbage FQDN in requests to probe
network functionality. Not to mention DNS misconfiguration and broken
DNS servers not responding to AAAA lookups.
* "Happy Eyeballs" clients.
Identified by the short duration of transaction as clients open
multiple connections abort some almost immediately.
* HTTP Expect:100-continue feature being used over a Squid having
"ignore_expect_100 on" configured - or some other proxy doing the
equivalent.
Identified by the long duration of the transaction, HTTP method type
plus an Expect header on request, and sometimes no body size. As the
client sends headers with Expect: then times out waiting for a
100-continue response which is never going to appear. These clients are
broken as they are supposed to send the request payload on timeout
anyway which would make the transaction complete properly.
3) PMTUd breakage on the upstream routes.
Identified at the TCP level by complete lack of TCP ACK to data packets
following a successful TCP SYN + SYN/ACK handshake. This would account
for the intermittent nature of it as HTTP response sizes vary a only
large packets go over the MTU size (individual TCP packets, *not* HTTP
response message size).
Amos
