Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Possible Duplicate:
Why is it 3-way-handshake and not more?

Example: If a client wants to talk to a server, it just tells the server that it wants to establish a connection, then the server confirms. People say that the third step's there so as to let the server knows it can sends data to the client successfully. However, I think the server can implement something like time-out. If the client takes too long to respond, the server can go ahead to: 1. re-send that segment or 2. terminate the connection

So, do we really need the third step? So much overhead in my opinion.

share|improve this question

marked as duplicate by EEAA, Shane Madden, Jeff Ferland, Sven, Tom O'Connor Mar 13 '12 at 11:42

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

The first packet is obviously needed client-to-server to tell the server to create a connection.

The second packet is needed server-to-client to tell the client that the server has accepted the connection.

The third packet is needed client-to-server to tell the server that the client received the second packet. Otherwise, the server would have no way to know that and it might just wonder why the client hasn't sent any data.

No fourth packet is needed. If the third packet gets through, both sides know the connection is open and are fully ready to send data if they wish. If the third packet does not get through, the second packet will be retransmitted, prompting a repeat of the third packet to be sent.

share|improve this answer

By the time the client gets the SYN ACK packet from the server, it considers the connection fully open (and sticks the ACK info in the header of its first data packet, too).

So, in an application where the client talks first, there is zero delay added by the third step in the handshake. In an application where the server talks first, the final ACK step really is necessary - the server can't start sending data packets until it knows that the client is expecting them.

share|improve this answer
If in the last step of the handshake, the connection's open already, why is the ACK header info necessary? And in the case that server talks first, then the second step's done by the client, so the client's ready already. – IcySnow Mar 13 '12 at 5:40
The connection is open for the client when the SYN ACK is received - not for the server. When I say "server talks first", I mean the device with the listening port sends the first data, such as SMTP. – Shane Madden Mar 13 '12 at 6:17

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