1
A server normally responds with SYN ACK in a 3-way handshake.
What would happen if it just responded with ACK?
1
A server normally responds with SYN ACK in a 3-way handshake.
What would happen if it just responded with ACK?
2
The client will wait for a SYN packet, after a while it will time-out.
The relevant RFC is http://www.faqs.org/rfcs/rfc793.html
The principle reason for the three-way handshake is to prevent old duplicate connection initiations from causing confusion. To deal with this, a special control message, reset, has been devised. If the receiving TCP is in a non-synchronized state (i.e., SYN-SENT, SYN-RECEIVED), it returns to LISTEN on receiving an acceptable reset. If the TCP is in one of the synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), it aborts the connection and informs its user. We discuss this latter case under "half-open" connections below.
The RFC allows for separate ACK and SYN by the server but notes that these may be combined into a single packet. In practice I believe all common implementations combine the server SYN and ACK.
...
Stevens† has a state-transition diagram. This suggests that the client will timeout to a CLOSED state and presumably will try to establish the connection afresh.
If either end receives data packets before they have reached a connection ESTABLISHED state, they will be in SYN_SENT or SYN_RCVD respectively and they will send a reset (RST) and (I think) move to a CLOSED or LISTEN state.
† ISBN 0-201--63346-9
1
Possible duplicate of http://serverfault.com/questions/248441/the-3-way-handshake
– RedGrittyBrick – 2011-04-07T10:57:44.900