What will happen at server side if it received 2 SYN packet from the same client application?

Question

A server moves to SYN_RECV state once it gets a SYN packet from a client application.

What will happen at server side if it received 2 SYN packet from the same client application?

Answer 1

Basically, a TCP receiving duplicate SYNs will SYN,ACK them, but it will receive a RST for the duplicate.

RFC 793, Transmission Control Protocol, Section 3.4. Establishing a connection explains exactly this scenario:

3.4. Establishing a connection

The "three-way handshake" is the procedure used to establish a connection. This procedure normally is initiated by one TCP and responded to by another TCP. The procedure also works if two TCP simultaneously initiate the procedure. When simultaneous attempt occurs, each TCP receives a "SYN" segment which carries no acknowledgment after it has sent a "SYN". Of course, the arrival of an old duplicate "SYN" segment can potentially make it appear, to the recipient, that a simultaneous connection initiation is in progress. Proper use of "reset" segments can disambiguate these cases.

Further down in the section, it goes into more detail:

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.

    TCP A                                                TCP B

1.  CLOSED                                               LISTEN

2.  SYN-SENT    --> <SEQ=100><CTL=SYN>               ...

3.  (duplicate) ... <SEQ=90><CTL=SYN>               --> SYN-RECEIVED

4.  SYN-SENT    <-- <SEQ=300><ACK=91><CTL=SYN,ACK>  <-- SYN-RECEIVED

5.  SYN-SENT    --> <SEQ=91><CTL=RST>               --> LISTEN

6.              ... <SEQ=100><CTL=SYN>               --> SYN-RECEIVED

7.  SYN-SENT    <-- <SEQ=400><ACK=101><CTL=SYN,ACK>  <-- SYN-RECEIVED

8.  ESTABLISHED --> <SEQ=101><ACK=401><CTL=ACK>      --> ESTABLISHED

                  Recovery from Old Duplicate SYN

                             Figure 9.

As a simple example of recovery from old duplicates, consider figure 9. At line 3, an old duplicate SYN arrives at TCP B. TCP B cannot tell that this is an old duplicate, so it responds normally (line 4). TCP A detects that the ACK field is incorrect and returns a RST (reset) with its SEQ field selected to make the segment believable. TCP B, on receiving the RST, returns to the LISTEN state. When the original SYN (pun intended) finally arrives at line 6, the synchronization proceeds normally. If the SYN at line 6 had arrived before the RST, a more complex exchange might have occurred with RST's sent in both directions.

The RFC is the definition of TCP, and you should refer to it. There are also later RFCs that update (RFCs 1122, 3168, 6093, 6528) it.

Answer 2

The server will simple reset the syn packet which is re-send by client and consider as duplicate packet .

Basically as TCP is reliable protocol post TCP handshake is successfully only actually application data is transferred .

  Client --------------- Server 

1. .. Client send syn packet
2. Server response back with SYN-ACK 3)Again post receving SYN -ACK from client . Client send ACk message to server .

During this time any packet is droped host will retransmit the packets . But reset the connection if it is considered as duplicate packet.