On 22/04/2013 9:46 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
As far as I can see sometimes a sequence of 000 misses is replied to
the same requesting IP (mostly web spiders) but in the meantime they
do get tons of other content.
Some of them (maybe 20%) come in couples something like:
1366622555.453 1488 87.19.154.90 TCP_MISS/000 0 GET
http://yammo.it/index.php? - DIRECT/151.1.96.198 -
1366622555.454 2327 87.19.154.90 TCP_MISS/000 0 GET
http://yammo.it/index.php? - DIRECT/151.1.96.198 -
1366622571.558 292 82.90.127.184 TCP_MISS/000 0 GET
http://www.forumviaggiatori.com/tabindex.php? - DIRECT/5.134.122.135 -
1366622571.575 242 82.90.127.184 TCP_MISS/000 0 GET
http://www.forumviaggiatori.com/popup%0Bg.png - DIRECT/5.134.122.135 -
1366622596.390 1972 193.32.73.24 TCP_MISS/000 0 GET
http://www.romaintheclub.com/24042013-shed-function-goa -
DIRECT/5.134.122.154 -
1366622596.561 166 193.32.73.24 TCP_MISS/000 0 GET
http://www.romaintheclub.com/24042013-shed-function-goa -
DIRECT/5.134.122.154 -
Hmm, some of these are too long to be "happy eyeballs". I'd put the odd
pairing down to spiders or some artifact of the way they are referenced
in the original pages.
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.
We are not using IPv6 yet, and it could be due to actually failed DNS
lookups, as I still have to fix some issues we have with our local
resolvers. Details from DNS stats
Rcode Matrix:
RCODE ATTEMPT1 ATTEMPT2 ATTEMPT3
0 93690 3 0
1 0 0 0
2 1525 1522 1522
3 540 0 0
4 0 0 0
5 0 0 0
If this were the problem you would see "NONE/-" on the access log lines.
* "Happy Eyeballs" clients.
Identified by the short duration of transaction as clients open
multiple connections abort some almost immediately.
Maybe that's why they come in couples?
* 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.
Did not check this one
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).
I don't think it's the case here
Amos
I suspect that most of the misses come from loaded webservers
discarding requests (and so squid never receives a reply) or by actual
firewalls discarding excessive packets.
Any other suggestions?
Note: "Firewalls discarding excessive packets" is another way of saying
PMTUd problems, as the MTU discovery is what tells the firewalls what
size packets to expect.
No more suggestins from me, I think thats pretty much all of them covered.
Amos
