Press "Enter" to skip to content

Why do we need a 3-way TCP handshake? Why not just 2-way? [duplicate]

        Why can't we just do:Alice sends sequence number and Bob sends sequence number back? What failure case does the third ACK prevents from happening? A comparison example between how a 2 way would be different from a 3 way would be great.
In fact, why does there need to be a handshake at all? Why can't Bob send 1000 packets, each annotated with a sequence from 1000-2000, and at the end sends a "closing packet" saying "just ended sending you seq 1000-2000, tell me if you missed any and then I'll retransmit"? Like I'm trying to imagine 2 abstract entities (or yourself talking to a friend) that can receive/send information in a specific form. What is the logical error in a 2-way handshake between them communicating without the 3rd handshake? Or is it not a logical error but a question of efficiency/speed? I'm assuming the 2 entities know they're both actually talking to eachother and not an impersonator, and I don't see how seq numbers solve that either. For example:
GABRIEL: HELLO DANIEL
DANIEL: HELLO GABRIEL
GABRIEL (1-10): EGGS
GABRIEL: I JUST SENT YOU 1-10
DANIEL: I REVEIVED EVERYTHING BUT 5
GABRIEL: HERE'S 5
DANIEL: RECEIVED 5
The above exchange also works if you send 2 packets in parallel with different SEQs, the client has just got to make sure they don't run out of SEQ and keep each packet not overlapping in range, and then reuse really old ones or ones that were ACKd. How does Daniel have any problem with this way of talking since they require the ACK in the three way? If Daniel says something and Gabriel doesn't hear, Daniel will retransmit after a timeout. An ACK from Gabriel might make Daniel to say more words than just 'ACK', so Daniel will waste some time/words but that doesn't seem to me that this is the reason for a three way instead of a two way.

Be First to Comment

Leave a Reply