TCP is a connection oriented protocol and every connection oriented protocol needs to establish connection in order to reserve resources at both the communicating ends.
Connection Establishment –
Sender starts the process with following: Sequence number (Seq=521): contains the random initial sequence number which generated at sender side. Syn flag (Syn=1): request receiver to synchronize its sequence number with the above provided sequence number. Maximum segment size (MSS=1460 B): sender tells its maximum segment size, so that receiver sends datagram which won’t require any fragmentation. MSS field is present inside Option field in TCP header. Window size (window=14600 B): sender tells about his buffer capacity in which he has to store messages from receiver.
TCP is a full duplex protocol so both sender and receiver require a window for receiving messages from one another. Sequence number (Seq=2000): contains the random initial sequence number which generated at receiver side. Syn flag (Syn=1): request sender to synchronize its sequence number with the above provided sequence number. Maximum segment size (MSS=500 B): sender tells its maximum segment size, so that receiver sends datagram which won’t require any fragmentation. MSS field is present inside Option field in TCP header. Since MSSreceiver < MSSsender, both parties agree for minimum MSS i.e., 500 B to avoid fragmentation of packets at both ends. Therefore, receiver can send maximum of 14600/500 = 29 packets. This is the receiver's sending window size. Window size (window=10000 B): receiver tells about his buffer capacity in which he has to store messages from sender. Therefore, sender can send a maximum of 10000/500 = 20 packets. This is the sender's sending window size. Acknoledgement Number (Ack no.=522): Since sequence number 521 is received by receiver so, it makes a request of next sequence number with Ack no.=522 which is the next packet expected by receiver since Syn flag consumes 1 sequence no. ACK flag (ACk=1): tells that acknowledgement number field contains the next sequence expected by receiver.
Sender makes the final reply for connection establishment in following way:
Sequence number (Seq=522): since sequence number = 521 in 1st step and SYN flag consumes one sequence number hence, next sequence number will be 522.
Acknowledgement Number (Ack no.=2001): since sender is acknowledging SYN=1 packet from the receiver with sequence number 2000 so, the next sequence number expected is 2001.
ACK flag (ACK=1): tells that acknowledgement number field contains the next sequence expected by sender.
Since the connection establishment phase of TCP makes use of 3 packets, it is also known as 3-way Handshaking (SYN, SYN + ACK, ACK).
130 down vote accepted Break down the handshake into what it is really doing.
In TCP, the two parties keep track of what they have sent by using a Sequence number. Effectively it ends up being a running byte count of everything that was sent. The receiving party can use the opposite speaker's sequence number to acknowledge what it has received.
But the sequence number doesn't start at 0. It starts at the ISN (Initial Sequence Number), which is a randomly chosen value. And since TCP is a bi-directional communication, both parties can "speak", and therefore both must randomly generate an ISN as their starting Sequence Number. Which in turn means, both parties need to notify the other party of their starting ISN.
So you end up with this sequence of events for a start of a TCP conversation between Alice and Bob:
Alice ---> Bob SYNchronize with my Initial Sequence Number of X Alice <--- Bob I received your syn, I ACKnowledge that I am ready for [X+1] Alice <--- Bob SYNchronize with my Initial Sequence Number of Y Alice ---> Bob I received your syn, I ACKnowledge that I am ready for [Y+1] Notice, four events are occurring:
Alice picks an ISN and SYNchronizes it with Bob. Bob ACKnowledges the ISN. Bob picks an ISN and SYNchronizes it with Alice. Alice ACKnowledges the ISN. In actuality though, the middle two events (#2 and #3) happen in the same packet. What makes a packet a SYN or ACK is simply a binary flag turned on or off inside each TCP header, so there is nothing preventing both of these flags from being enabled on the same packet. So the three-way handshake ends up being:
Bob <--- Alice SYN
Bob ---> Alice SYN ACK
Bob <--- Alice ACK
Notice the two instances of "SYN" and "ACK", one of each, in both directions.
So to come back to your question, why not just use a two-way handshake? The short answer is because a two way handshake would only allow one party to establish an ISN, and the other party to acknowledge it. Which means only one party can send data.
But TCP is a bi-directional communication protocol, which means either end ought to be able to send data reliably. Both parties need to establish an ISN, and both parties need to acknowledge the other's ISN.
So in effect, what you have is exactly your description of the two-way handshake, but in each direction. Hence, four events occurring. And again, the middle two flags happen in the same packet. As such three packets are involved in a full TCP connection initiation process.