What will happen if a server receives a duplicate SYN for an existing connection?

Question

If a server receives a fresh SYN packet for a connection that is already established, what should it do?

I have already seen What will happen at server side if it received 2 SYN packet from the same client application?. The example there covers a different case: a server receiving a duplicate previous session SYN before the 'correct' SYN. In that case, the server SYNACK's the wrong session back to the client, which then RSTs the bad session.

The answer does briefly mention this alternative case, but doesn't cover the details:

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.

What exactly happens in that more complex case? Does the server reply with a RST immediately, or re-ack the existing session, or something else?

More specifically, what happens here:

    TCP A                                                TCP B

1.  CLOSED                                               LISTEN

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

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

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

5.              ... <SEQ=200><CTL=SYN>               --> ???

                              ???

Answer 1

I did some more reading, and I found an equivalent case that's covered in more detail elsewhere in the RFC, under "Half-Open Connections and Other Anomalies".

After TCP A crashes, the user attempts to re-open the connection. TCP B, in the meantime, thinks the connection is open:

      TCP A                                           TCP B

  1.  (CRASH)                               (send 300,receive 100)

  2.  CLOSED                                           ESTABLISHED

  3.  SYN-SENT --> <SEQ=400><CTL=SYN>              --> (??)

  4.  (!!)     <-- <SEQ=300><ACK=100><CTL=ACK>     <-- ESTABLISHED

  5.  SYN-SENT --> <SEQ=100><CTL=RST>              --> (Abort!!)

  6.  SYN-SENT                                         CLOSED

  7.  SYN-SENT --> <SEQ=400><CTL=SYN>              -->

                     Half-Open Connection Discovery

                               Figure 10.

When the SYN arrives at line 3, TCP B, being in a synchronized state, and the incoming segment outside the window, responds with an acknowledgment indicating what sequence it next expects to hear (ACK 100). TCP A sees that this segment does not acknowledge anything it sent and, being unsynchronized, sends a reset (RST) because it has detected a half-open connection. TCP B aborts at line 5.

The rules that cause this are described in more detail later on:

If the connection is in a synchronized state (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), any unacceptable segment (out of window sequence number or unacceptible acknowledgment number) must elicit only an empty acknowledgment segment containing the current send-sequence number and an acknowledgment indicating the next sequence number expected to be received, and the connection remains in the same state.

So, to explicitly answer my original question: when an unexpected SYN arrives, its sequence number will be outside the connection window and it will lack the appropriate ack number for the existing connection, so the server should (re)send an ACK confirming the existing connection state, and not ack or handle the unexpected packet at all.

Answer 2

That happens all the time in order for a host to establish multiple connections to another host (remember that TCP does not have clients or servers; client/server is an application layer concept that is off-topic here). As RFC 793, Transmission Control Protocol explains:

The combination of this information, including sockets, sequence numbers, and window sizes, is called a connection.

Because you have a new SYN with a different sequence number, you are creating a new connection. Things like web browsers regularly do that in order to get different parts of a web page to load at the same time.

All your example is doing is trying to create a second connection.

---

Edit based on your comments and answer:

The sequence of events in your question cannot be in the same connection because you have a different initial sequence number. As it explains in the RFC quote above in my answer, the sequence number is a critical part of the connection, and you are changing the initial sequence number, so it cannot be part of the same connection. The only possible explanations are that this is a new connection, which is common, or the host has a bad TCP implementation or there is some programming on the host that is purposely trying to mess up TCP, neither of those are on topic or part of the TCP protocol theory.

If the next SYN was part of the same connection, it must have the same initial sequence number, meaning your question would be the same question as the question you linked. A different initial sequence number means it is a different connection, and that happens just about every time you load a web page.

Your answer actually deals with a different question, which is about a half-open connection. Your question, based on its sequence of events, is actually about a fully open connection, and the host starting a new connection.

The TCP protocol theory is on-topic here, but a question asking an extra-theoretical question is off-topic. What a buggy host-specific implementation (a proper TCP implementation would not have a different initial sequence number for the same connection), or a purposeful attempt to disrupt TCP, does is something for a different SE site (either a host OS-specific site or Information Security).