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?

  • Unfortunately, questions about host/servers are off-topic here. TCP knows nothing about clients or servers, that is an application concept, and applications are off-topic here, while TCP connects peers. You should edit your question to ask about TCP theory, and leave out anything about client/server or applications.
    – Ron Maupin
    Jan 24, 2018 at 5:46
  • There is no "same client application" at the TCP level, there are only connections. The same client application can create multiple connections to the same server (with different client ports). It is thus unclear what you exactly mean with "it received 2 SYN packet from the same client application" - is it a SYN for a new connection, a duplicate SYN for an existing connection or an out of order SYN for an existing connection? Jan 24, 2018 at 6:59
  • @SteffenUllrich It is SYN for an existing connection
    – vikas
    Jan 25, 2018 at 10:41
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer.
    – Ron Maupin
    Apr 1, 2018 at 20:02

2 Answers 2


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.

  • I think int the first sentence it should be "but it will send a RST for the duplicate".
    – JFL
    Jan 24, 2018 at 8:16
  • @JFL, on Line 5, it explains that the TCP that sent the duplicate will send the RST for the ACK of the duplicate. It is in a position to know that it sent the duplicate.
    – Ron Maupin
    Jan 24, 2018 at 15:23

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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