Real-World Use of TCP_DEFER_ACCEPT?

Question

I was perusing the Apache httpd manual online and came across a directive for enabling this. Found a description in the man page for tcp:

   TCP_DEFER_ACCEPT (since Linux 2.4)
          Allow a listener to be awakened only when data arrives on the
          socket.  Takes an integer value (seconds), this can bound the
          maximum number of attempts TCP will make to complete the
          connection.  This option should not be used in code intended
          to be portable.

Then I found this article but I'm still unclear what kind of workloads this would be useful for. I'm assuming that if httpd has an option specifically for this, it must have some relevance to web servers. I'm also assuming from the fact it's an option and not just how httpd does network connections, that there are use cases where you want it and others where you don't.

Even after reading the article, I'm unclear on what the advantage to waiting for the three way handshake to complete would be. It would seem advantageous to ensure it's not going to need to swap-in the relevant httpd instance by doing so while the handshake is still going on instead of potentially causing that delay after a connection is formed.

For the article, it would also seem to me that no matter the TCP_DEFER_ACCEPT status of a socket, you're still going to need four packets (handshake then data in each case). I don't know how they get the count down to three, nor how that provides a meaningful enhancement.

So my question is basically: Is this just an old obsolete option or is there an actual use case for this option?

Answer 1

(to summarise my comments on the OP)

The three-way handshake that they are refering to is part of the TCP connection establishment, the option in question doesn't relate specifically to this. Also note that data exchange is not part of the three way handshake, this just creates the TCP connection in the open/established state.

Regarding the existance of this option, this is not the traditional behaviour of a socket, normally the socket handler's thread is woken up when the connection is accepted (which is still after the three way handshake completes), and for some protocols activity starts here (e.g. an SMTP server sends a 220 greeting line), but for HTTP the first message in the conversation is the web browser sending its GET/POST/etc line, and until this happens the HTTP server has no interest in the connection (other than timing it out), thus waking up the HTTP process when the socket accept completes is a wasteful activity as the process will immediately fall asleep again waiting for the necessary data.

While there is certainly argument that waking up idle processes can make them 'ready' for further processing (I specifically remember waking up login terminals on very old machines and having them chug in from swap), but you can also argue that any machine that has swapped out said process is already making demands on its resources, and making further unnecessary demands might overall reduce system performance - even if your individual thread's apparent performance improves (which it also may not, an extremely busy machine would have bottlenecks on disk IO which would slow other things down if you swapped in, and if its that busy, the immediate sleep might swap it right back out). It seems to be a gamble, and ultimately the 'greedy' gamble doesn't necessarily pay off on a busy machine, and certainly causes extra unnecessary work on a machine that already had the process swapped in - your approach optimises for a machine with a large memory set of processes that are mostly dormant, and swapping one dormancy for another is no big deal, however a machine with a large memory set of active processes will suffer from extra IO, and any machine that isn't memory limited, suffers, any CPU bound machine will be worse off.

My general advice regarding that level of performance tuning would be to not make programatic decisions about what is best anyway, but to allow the system administrator and operating system to work together to deal with the resource management issues - that is their job and they are much better suited to understanding the workloads of the entire system and beyond. Give options and configuration choices.

To specifically answer the question, the option is beneficial on all configurations, not to the level you'd ever likely notice except under an extreme load of HTTP traffic, but it's theoretically the "right" way to do it. It's an option because not all Unix (not even all Linux) flavours have that capability, and thus for portability it can be configured not to be inclided.

Answer 2

I'm unclear on what the advantage to waiting for the three way handshake to complete would be.

Three-way handshakes are a common protocol in voice telephony:

1. Server: "Good afternoon, Epiphyte Corp."
2. Caller: "Hello, this is Randy."
3. Server: "Yes, how may I help you?"
4. Caller: body of call begins requesting a joke

They are important in TCP for ensuring that the channel is established. If Client started sending body of call before hearing (3) there is a chance that Server isn't listening or isn't ready. Hearing (3) does not guarantee that Server didn't immediately suffer spontaneous combustion after transmission but it does increase the confidence that the Server is ready to receive.

As noted in the Wikipedia on Handshaking:

1. Alice [Server] replies with an acknowledgment message with acknowledgement number y + 1, which Bob [Client] receives and to which he doesn't need to reply.

So if you are willing to forgo a little added certainty that the server is ready, Server can skip step (3) and the client will just assume that the server was ready. This turns the protocol exchange above into:

1. Server: "Good afternoon, Epiphyte Corp."
2. Caller: "Hello, this is Randy."
3. Caller: "Do you know any jokes about Imelda Marcos?"