accf_http and incqlen

[Uwe Doering]

Scott Oertel wrote:
> (I sent this to freebsd-questions, but I didn't receive any replies,
> thought I would try my luck here)
> 
> I setup the http accept filter with apache and I was having a hard time
> understanding this, maybe you guys could help out.
> 
> I've tested this among various version of freebsd, primarily FreeBSD
> 6.3-RELEASE, and with various
> apache configs, and it appears to behave the same across the board.
> 
> So why is it that it "appears" that the TCP connections never terminate,
> just stay in a state of ESTABLISHED, and why doesn't this queue ever
> flush itself, is it normal, if it is, what happens exactly when the
> queue fills up to maxqlen. From the netstat output below, you can see
> that the incqlen is maxed out. I've done quite a bit of searching
> regarding this queue but haven't found any real solid information which
> describes what happens when it fills up, and at the same time this is
> going on, I have 517 established connections to port 80.
> 
> ]# netstat -an|grep "\.80"|grep ESTAB|wc -l
>      519
> [...]

Last time I looked (in FreeBSD 4.x) these were connections that got 
stuck in an early stage, that is, before the HTTP request had been 
received.  The 'accf_http' filter which wants to parse said request 
waits forever in this situation because there is no timeout implemented, 
as far as I recall.  So these would-be HTTP connections pile up over time.

The actual cause are quite likely port scans and such from the Internet. 
  I don't know whether one would eventually run out of resources, but so 
many stuck connections certainly look sick, and you can't see the wood 
for the trees if you need to debug something under these circumstances.

What I did instead was compile Apache 1.3 with the flag

   -DACCEPT_FILTER_NAME=\\\\\"dataready\\\\\"

added to CFLAGS in the ports repository's Makefile.  This way Apache 
uses the 'dataready' filter instead of 'httpready'.  This doesn't cause 
any stuck connections, and it improves the performance as well because 
most modern browsers and proxies send the HTTP request plus the whole 
set of headers in a single data packet anyway, which means that 
unconditionally returning from accept(2) on the first data packet 
received is sufficient.  Under these circumstances the overhead of 
parsing the HTTP request in the kernel, like the 'httpready' filter 
does, no longer makes much sense.

I haven't looked at Apache 2.x so far in this regard.  Perhaps there is 
a similar compile time option.  In any case, maybe this tweak helps in 
your case, too.

Regards,

    Uwe
-- 
Uwe Doering         |  EscapeBox - Managed On-Demand UNIX Servers
gemini at geminix.org  |  http://www.escapebox.net