Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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?

share|improve this question
    
I'm not clear on what you mean by "get the count down to three", which makes me suspect you misunderstand the three way handshake. This is a TCP "open connection" transaction and consists of 3 packets total transmitted. Until these 3 complete, there is no data, and is no connection that is valid. As such data never factors into the handshaking overhead. The efficiency increase that would be gained from TCP_DEFER_ACCEPT would be the gap between the completion of the 'accept' TCP 3 way handshake, and the first data packet (I assume, mostly here to comment on the 3 vs 4 way handshake) –  iain Oct 8 '13 at 15:43
    
Also, it's not about avoiding 'swapping in', it's about not wasting resources. If swapping was to become a factor in activating a HTTP worker then you're forcing your worker to swap in prematurely at the accept point before data is ready... and if swapping is happening, that means you're forcing something else out of ram... something that was maybe doing something and gets swapped back in between your accept/data part... whatever resource - CPU, diskIO, in-ram pages, if there's no data, then there's no point causing work. –  iain Oct 8 '13 at 15:45
    
If the worker process is already in memory, isn't that pretty low latency compared to possibly going to disk? The "down to three" is a reference to the article which says that somehow this would make it so that the first packet of data from the client would be on the third packet. –  Bratchley Oct 8 '13 at 15:49
    
Also, the theoretical swap-in is going to happen anyways, this wouldn't change with this TCP option. I don't see how taking the gap out of forming the TCP connection and putting it at the data transfer is beneficial. At least when you're doing it during the TCP connection forming there's the possibility of the two happening in parallel (decreasing the amount of time). –  Bratchley Oct 8 '13 at 15:51
    
Should have just written an answer... In regards to it being an option, well, its not how "normal" unix standards work... Specifically regarding HTTP the key point is that the client (web browser) initiates the conversation with the GET line... So the server doesn't care about the actual connection, just the first data. As opposed to say SMTP which requires the client to wait until the server issues its "220 welcome banner" message. I.e. THAT server needs to know on connect, not on data. –  iain Oct 8 '13 at 15:52

2 Answers 2

up vote 4 down vote accepted

(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.

share|improve this answer

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?"
share|improve this answer
    
It's more than just confidence, you send before the 3way completes and your data is binned. The way TCP connections are set up in modern OS stacks there is actually no connection data logged in tables until the 3rd part of the connection, the requirement of the 3rd message before any resources are consumed is done via the use of "Syn Cookies" and prevents "Syn Attacks" (which are forged-source-ip handshake packet 1. its packet 3 that undermines that forged source ip.). Hence plain up no connection or entry for it exists before this point. –  iain Oct 11 '13 at 4:57
    
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. –  msw Oct 12 '13 at 19:49
    
Increase? From zero? Well yes, I guess literally thats true, but most people would imply there was /some/ chance before packet 3 to increase. And there isn't. It's just the phrase "increase the confidence" that I dont like, and I dont think factoring in 0.001% 'real world major issues' helps keep the issue clear. Sure, nuclear war might happen before the server gets the packet, lots of things could happen. –  iain Oct 13 '13 at 17:00
    
Also I just picked up on the last paragraph, where you imply step 3 is optional. It isn't, absolutely isn't. Reread the paragraph, step 3 is "alice replies with an acknowledgement". that is not optional. bob replying to that (a theoretical 4th step) is. –  iain Oct 13 '13 at 18:55

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.