Why TCP needs a third message
A TCP connection is not just a path for sending packets; it is a shared agreement about how to track an ordered stream of bytes. Before useful data can flow, each computer needs to know that the other is reachable and which sequence numbers to use to label incoming bytes.
The opening exchange uses three control messages, commonly called SYN, SYN-ACK, and ACK. The first computer proposes an initial sequence number. The reply acknowledges that number and proposes one of its own. The final message acknowledges the reply’s number. Each side has now shown that it received the other’s message and knows where the byte-counting begins.
Why not stop after two?
After only two messages, the responder cannot know whether its reply reached the first computer. The third message closes that gap: it confirms receipt of the responder’s sequence number. Without that confirmation, the responder might treat a connection as established even though the other side never received its reply.
These numbers also help TCP distinguish current traffic from delayed packets left over from an earlier connection. They are not counts of individual packets; they mark positions in the byte stream, so TCP can put data back in order and detect what needs retransmitting.
The handshake sets up TCP’s bookkeeping, not the readiness of every program on either machine. An application still has to accept and handle the connection. But before that conversation can reliably proceed, both computers must agree on the same starting point—and the third message is what lets each side know the agreement reached the other.
