How does triple handshake avoid establishing connection for duplicate packets(coming later down the line)

Question

The idea behind triple handshake seems to be for duplicates to not cause issues. The way I understand it host sends a sequence x to server. Server acknowledges it and sends it's own sequence y. Host again acknowledges y and therefore a connection is established.

How does this prevent issues caused by duplicates?

Let's say host sends sequence 100 to server. Server acks with its own sequence number 200. Host acknowledges 200 and therefore connection is established.

Let's say after that a connection is terminated and after some time again duplicate arrives. Host sends sequence 100 to server. And this time server randomly chooses 300 and why would the host now reject the connection?

Answer 1

It is highly unlikely that a host will send the same sequence number twice in a row to open a connection. Remember that this is a 32-bit random number, and the RFC specifies that the number should only repeat every four and a half hours or so. By using a random sequence number this way, a delayed SYN can be discovered.

What you really have is a four-way handshake, but it is done in three segments. Each side sends its sequence number, and each side acknowledges the sequence number from the other side, which lets the other side verify that the sequence number it sent is correctly received by the other side. See RFC 793, Transmission Control Protocol:

The synchronization requires each side to send it's own initial sequence number and to receive a confirmation of it in acknowledgment from the other side. Each side must also receive the other side's initial sequence number and send a confirming acknowledgment.

1) A --> B  SYN my sequence number is X
2) A <-- B  ACK your sequence number is X
3) A <-- B  SYN my sequence number is Y
4) A --> B  ACK your sequence number is Y

Because steps 2 and 3 can be combined in a single message this is called the three way (or three message) handshake.

A three way handshake is necessary because sequence numbers are not tied to a global clock in the network, and TCPs may have different mechanisms for picking the ISN's. The receiver of the first SYN has no way of knowing whether the segment was an old delayed one or not, unless it remembers the last sequence number used on the connection (which is not always possible), and so it must ask the sender to verify this SYN. The three way handshake and the advantages of a clock-driven scheme are discussed in [3].

For example, if Host A sends a SYN to Host B, but it somehow gets delayed and Host A again sends the SYN to Host B, or the SYN gets somehow duplicated on the network, Host B uses its ACK to verify with Host A that the sequence number is correct. Host A would see that it is not.