httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dean gaudet <>
Subject Re: application level accept() filter for 1.3.x
Date Tue, 02 Jan 2001 17:29:38 GMT
i didn't read your patch i was just commenting on your comment that linux
didn't have accept filtering :)

an HTTP session goes like this:

client -> server:  SYN
server -> client:  SYN|ACK
client -> server:  SYN|ACK
   accept() succeeds here
client -> server:  data
   read() succeeds here

with the TCP_DEFER_ACCEPT and the "dataready" kernel filters, the
accept() is deferred until after that 4th packet is received.  as far
as i understand your patch, it defers passing the accepted socket to a
heavyweight httpd child until that 4th packet appears as well.

when i referred to "first packet" i actually meant that 4th packet... the
first packet of actual data transfer.  the first 3 are handshakes you
can't do much about.  (TTCP which lets data go in the first packet is not
secure / not useable on an open network.)


On Sun, 31 Dec 2000, Theo E. Schlossnagle wrote:

> I saw this...  I think this is great, though I haven't tested how well it work
> -- we don't run 2.4 anywhere yet.  As for comparing an application filter and
> a kernel filter, I don't see how an app filter (my patches specifically) won't
> perform as well.
> I don't do anything but a select on the accepted socket to see if there is
> data ready.  So it serves the same purpose but it doesn't live in the kernel,
> so it induces more context switching.  A kernel level filter, assuming it is
> written correctly, should beat the pants off my "parental accept" patch.
> MSIE and netscape can't send the data in the first packet right?  You have to
> send a few packets to establish the session first.  The problem is latency (of
> a modem or shotty network connection) between the establishment and that first
> data packet.
> Am I losing my mind?  I have seen this sort of thing frequently across very
> high traffic sites.
> With that said, if you are having lulls between connect() and read() on the
> server side and you OS doesn't support accept filtering.  The "parental
> accept" patch should solve the problem.
> dean gaudet wrote:
> > as of linux 2.4 there is a TCP_DEFER_ACCEPT option which behaves like
> > freebsd's "dataready" filter.
> >
> > i'd actually be curious to know how much the "http" filter actually gains
> > over just plain dataready... given that MSIE always sends the headers in
> > the first packet; and so does netscape unless its POSTing.  (netscape
> > splits the headers before the Content-Length/post body.)
> --
> Theo Schlossnagle
> 1024D/A8EBCF8F/13BD 8C08 6BE2 629A 527E  2DC2 72C2 AD05 A8EB CF8F
> 2047R/33131B65/71 F7 95 64 49 76 5D BA  3D 90 B9 9F BE 27 24 E7

View raw message