Don’t understand TCP three-way handshake and four-way wave? Interviewer: Go back and wait for notification!

🌟 Opening: You think you know TCP? Actually...

Come, ask a few simple questions:

1️⃣ Why is it a "three-way" handshake? Isn't two enough? Is four times redundant?

2️⃣ Why wave "four times"? Can't it be done twice?

3️⃣ Do you know the whole process of TCP handshake and wave? What is each step doing?

If you are still not sure about these questions, you must continue reading. Today, I will show you how to thoroughly understand TCP handshake and wave in the most straightforward and fun way!

🎭 Scenario: Nightclub pickup vs Internet connection

TCP connection is like chatting up someone at a nightclub (establishing a connection) and saying goodbye politely (disconnecting the connection). If you don't do it right, you will end up in a social deadlock in a matter of minutes! Let's follow Xiao Ming's story and understand the process step by step.

💏 Scene 1: The Three-Way Handshake - "The Art of Pickup"

Xiao Ming sees Xiao Hong in a nightclub, but he won't be stupid enough to just shout "Be my girlfriend!" (unless he wants to be considered a psychopath). He needs a solid three-step plan:

 [小明]（客户端） [小红]（服务器） |----SYN----->| 小明："嗨，可以认识一下吗？" |<--SYN-ACK---| 小红："可以呀，你是谁？" |----ACK----->| 小明："我是小明，程序员，喜欢猫..."

🔍 The complete three-way handshake process is as follows:

picture

Let's take a look at how the TCP three-way handshake works:

Both the client and the server start in the "closed" state. This is like two people starting a chat:

• The client first sends a hello (SYN=1, seq=x), saying "Hey, can we chat?", and then waits there (SYN_SENT state). The server is now ready to listen (LISTEN state).
• After receiving the message, the server responds (SYN=1, ACK=1, seq=y, ack=x+1) "OK, I heard you", and enters the waiting state (SYN_RCVD state).
• The client finally confirms (ACK=1, ack=y+1), which is equivalent to saying "Great, let's start chatting." At this time, both parties have entered a state where they can chat normally (ESTABLISHED state).

From a technical perspective, this process not only confirms that both parties can send and receive data, but also completes the synchronization of the initial sequence numbers and establishes a reliable communication foundation.

🤔 Wait! Why does it have to be three times? Can't it be twice?

🎯 Reason 1: Establish "two-way communication" (can send and receive)

Imagine you are ordering a song in a KTV box:

第一次：你：（按麦克风按钮）"喂喂？" （确认你的麦克风能发声）第二次：前台：（通过音响）"听到了，你要点什么歌？" （确认音响能放声，你能听到）第三次：你：（通过麦克风）"我要点《野狼disco》！" （确认你能听到音响声，整个通信链路都通了）

If there are only two conversations:

• You pressed the microphone
• The front desk responded
• But you may not have heard the response from the front desk
• You're just ordering songs by yourself.
• Front Desk: ??? What do you want to order?

📝 In the TCP protocol, this two-way communication confirmation process is as follows:

第一次: SYN=1, seq=x客户端------------------> 服务器（我能发消息，我的序号是x）第二次: SYN=1, ACK=1, seq=y, ack=x+1客户端<------------------ 服务器（我能收能发，收到你的x号消息）第三次: ACK=1, ack=y+1客户端------------------> 服务器（我也能收能发，收到你的y号消息）

This is the "full-duplex communication" establishment process in TCP:

1. First handshake: the client proves that it can send data
2. Second handshake: the server proves that it can send and receive data
3. The third handshake: the client proves that it can receive data

Just like the equipment test in KTV box:

• "Hello?" (Prove the microphone works)
• "I heard it, can you hear it?" (Prove that the speakers can play and the staff can hear it)
• "I can hear it!" (proves that the whole system is OK)

Only in this way can we ensure:

• Both the client and the server can send data
• Both parties can receive each other's data
• The communication link is completely bidirectional 🤔 Wait! Why do we have to do a three-way handshake? Can't two be enough?

🔄 Reason 2: Synchronize the sequence numbers of both parties (confirm each other's initial sequence numbers)

If there are only two handshakes:

客户端服务器| | |--------SYN seq=100-------->| 给你我的序号100 | | |<--SYN+ACK seq=200,ack=101--| 好的，我用200 | |

Problem: The server does not know whether the client actually received its 200

• The two-way handshake can only ensure that the server has received the client's initial sequence number 100
• But there is no guarantee that the client has received the server's initial sequence number 200
• The initial sequence numbers of both parties must be confirmed by the other party, and the two-way handshake cannot do this.

So a third handshake is necessary:

客户端服务器| | |--SYN seq=100-------------->| 给你我的序号100 |<--SYN+ACK seq=200,ack=101--| 好的，我用200 |--ACK ack=201-------------->| 我知道你用200了

Just like two people agreeing on a secret code:

• Xiao Ming: I use the code 100
• Xiaohong: I received your 100, I used the code 200
• Xiao Ming: OK, I also received your 200

Through three-way handshake:

• The server confirms receipt of the client's sequence number
• The client also confirms that it has received the server's serial number
• Both parties know each other's initial sequence number and can start reliable communication

This is why a three-way handshake is necessary, because only in this way can we ensure that the initial sequence numbers of both parties are successfully confirmed by the other party!

😱 Reason 3: Prevent expired messages (solve time travel)

 [星期五晚上]小明用手机打开交友APP： > 9:00 - 发送好友申请，但信号不好没发出去> 9:05 - 重新发送申请，这次成功了！开始愉快聊天> 9:30 - 突然！之前卡住的申请终于发出去了...

What happens if there is no third confirmation?

1. The server received a late request at 9:00
2. Responded: "Okay, let's start chatting"
3. But at this time the users have been chatting for half an hour!
4. The server is still foolishly preparing resources for this old request
5. Result: Waste of server resources and possible interruption of ongoing chats.

With the third handshake, this will not happen:

 [9:30] 迟到的申请终于到达服务器服务器："收到你的申请啦！"客户端：（发现是半小时前的旧消息）不回应服务器：（没收到回应，知道是旧消息，直接忽略）

📝 In the TCP protocol, this process actually looks like this:

 [过期的SYN请求]客户端----迟到的SYN(seq=x)---------> 服务器客户端<---SYN+ACK(seq=y,ack=x+1)--- 服务器客户端（发现是旧请求，不回应ACK）服务器（等待超时，关闭半连接）

This involves several important mechanisms of TCP:

1. Semi-connection queue (SYN Queue)

• After the server receives SYN, it will create a half-connection
• If the third ACK is not received, the connection will be dropped.
• Prevents server resources from being occupied by old requests

2. Connection timeout mechanism

• The server will set a timeout (usually tens of seconds)
• If no ACK is received within this time, the half-connection is cleared
• Preventing the semi-connection queue from being full

3. Serial number verification

• When the client receives SYN+ACK, it verifies the sequence number
• If it is an expired request, no ACK will be sent
• The server can thus identify expired connections

This is why TCP requires three handshakes instead of two:

• Prevent accidental establishment of legacy connections
• Protect server resources from being wasted
• Ensure that only valid connections are established

Consider the example above again:

• SYN is like Xiao Ming's friend request
• SYN+ACK is the server's response
• Without the third ACK, it is equivalent to Xiao Ming not confirming
• The server knows that this is an old request and can safely ignore it.

This design cleverly solves the "delayed message" problem in the network and is one of the most essential parts of the TCP protocol!

🤔 Also, why does it have to be three times? Can't four times be enough?

Let's continue with the KTV song ordering example:

 [三次握手]你：喂喂？（能发声）前台：听到了！（能收能发）你：好的！（整个链路通了） [如果是四次]你：喂喂？（能发声）前台：听到了！（能收到）前台：你要点歌吗？（能发声）你：好的！（确认）这样看出问题了吗？第二次和第三次握手其实可以合并前台说"听到了"的同时就能问"要点歌吗"没必要分开说，那样反而浪费时间

From a technical perspective:

服务器收到SYN 后： - 已经知道客户端能发送数据- 自己能收到数据- 可以直接在ACK 中带上自己的SYN - 不需要分两次发送

Simply put:

• Three times is just right: confirm that both parties can send and receive
• Two times are not enough: Unable to confirm that the client can receive
• Four times redundant: separate what can be combined

Remember: The principle of TCP design is to ensure reliability and pursue efficiency!

💡 Summary

The three-way handshake is not intended to be complicated, but to:

1. Establish "two-way communication" (both parties can send and receive)
2. Synchronize the sequence numbers of both parties (to ensure the order of communication)
3. Prevent accidental establishment of legacy connections (avoid "delayed messages")
4. Make sure both parties are ready before starting the communication

Remember: every handshake has its reason for existence. It is not designed by technicians who have nothing to do, but to solve practical network communication problems!

🎭 Act 2: Four Waves - "The Art of Goodbye"

🌟 Let’s continue our nightclub story

Remember Xiao Ming and Xiao Hong? After shaking hands three times, they had a very happy chat. But the nightclub always ends, and it's time to say goodbye. However, a respectable person's farewell is not to just leave!

🎭 What's up with the four waves?

When it is time to say goodbye, Xiao Ming cannot disappear suddenly, but must say goodbye gracefully. Let's take a look at this process:

 [小明] [小红] | | |--"我该走了"(FIN)-----> | 第一次：表达想走的意思|<--"等等，我说完"(ACK)-- | 第二次：先别急，还有话说|<--"好了说完了"(FIN)--- | 第三次：我也说完了，再见|--"好，拜拜"(ACK)-----> | 第四次：最后的告别

📝 This is what it actually looks like in TCP:

客户端服务器| 1. FIN=1, seq=x | | ------------------------------>| 第一次：客户端表示要关闭连接| 2. ACK=1,seq=y,ack=x+1 | | <-----------------------------| 第二次：服务器确认，但自己还有数据要发| | | (服务器发送剩余数据) | | 3. FIN=1,ACK=1,seq=z,ack=x+1 | | <-----------------------------| 第三次：服务器发完数据，也准备关闭了| 4. ACK=1,seq=x+1,ack=z+1 | | -----------------------------> | 第四次：客户端最后确认| TIME_WAIT (2MSL等待...) |

🤔 Why four times? Can't two times be enough?

Imagine this embarrassing scene:

 [如果只有两次挥手]小明：时间不早了，我要走了！小红：好的再见！ （双方立马分别）问题是：小红正要给小明微信号，结果小明已经离开了... // 一个本该成功的搭讪，因为太急着说再见而失败

Why doesn't this work?

1. Xiao Ming said "I'm leaving" just to say that he will not send messages anymore
2. But Xiaohong may have something else to say (such as sending a WeChat ID)
3. If we part immediately, Xiaohong won't have time to say what she wants to say.

From a technical perspective:

 [两次挥手的问题]客户端服务器|---我不发消息了---------------->| |<--好的再见，连接关闭-----------| | | 服务器的数据发不出去了！

So it has to be four times:

 [优雅的告别]小明：我要走了，不说话了小红：等等，我还有话要说（把微信号给小明）小红：好了，我说完了小明：收到，拜拜！

That's why four waves are needed:

• Let both parties finish what they need to say
• Avoid important information from being sent out
• Ensure a complete and graceful disconnect

📝 Deep understanding of four waves

Let's first look at the detailed diagram of TCP's four waves:

picture

1️⃣ The first wave: Say goodbye proactively

小明："时间不早了，我该走了"

Technical perspective:

第一次挥手：FIN=1, seq=x客户端-----------------> 服务器（客户端的数据发完了，准备关闭）

• The client sends a FIN packet with sequence number x
• Entering FIN_WAIT_1 state
• Indicates that the client has no data to send

2️⃣ The second wave: Don’t be in a hurry

小红："等等，我还有话说..."

Technical perspective:

第二次挥手：ACK=1,seq=y,ack=x+1客户端<----------------------- 服务器（服务器确认，好的，我知道了，但我还有数据要发）

• The server sends an ACK with sequence number y and confirmation number x+1
• Entering the CLOSE_WAIT state means that the server may have data to send
• When the client receives the ACK packet, the client enters the FIN_WAIT_2 state

3️⃣ The third wave: It’s done

小红："好了，联系方式给你了，我也该说再见了"

Technical perspective:

第三次挥手：FIN=1, seq=z, ack=x+1客户端<------------------------- 服务器（我的数据也发完了，准备关闭）

• The server sends a FIN packet with sequence number z and confirmation number x+1
• Entering the LAST_ACK state
• Indicates that the server data has also been sent

4️⃣ The fourth wave: the final farewell

小明："好的，拜拜！"（但还会在门口等一会儿）

Technical perspective:

第四次挥手：ACK=1,seq=x+1,ack=z+1客户端--------------------------> 服务器（好的，我知道了，可以关闭了）

• The client sends an ACK with sequence number x+1 and confirmation number z+1
• Entering TIME_WAIT state
• Wait for 2MSL before actually shutting down

Finally, both parties enter the CLOSED state.

🤓 Why wait for 2MSL?

Imagine this scenario:

小明说完"拜拜"后，没有立即离开而是在夜店门口等了一会儿，因为： 1. 万一小红没听清他说的"拜拜"

Technical explanation:

客户端服务器... | 4. ACK=1,seq=x+1,ack=z+1 ---------------> | 第四次：客户端最后确认| TIME_WAIT (2MSL等待...) |

1. MSL is the maximum survival time of a data packet (usually tens of seconds)
2. Waiting for 2MSL is for:

• Make sure the final ACK reaches the server
• Waiting for possible FIN retransmission
• Prevent packets from old connections from affecting new connections

What does it mean that packets from an old connection affect a new connection?

Let me explain "prevent packets from old connections from affecting new connections" with a concrete example.

假设没有2MSL等待时间：客户端A 服务器| 1. 断开连接| | 2. 马上重新建立新连接| | 迷路的数据包------> | | （来自刚才的旧连接） | | 结果：服务器会把旧数据包当成新连接的数据！ | # 假设客户端A和服务器的ip 地址和端口保持不变，即：四元组保持不变

A scenario like this:

 [夜店场景] 21:00 - 小明和小红说再见，立刻离开21:01 - 小明又和小红相约夜店，可能有重要的事... 21:02 - 突然！服务员送来小明之前给小红点的酒...小红：？？？（搞不清这是之前的单，还是新的单）

With 2MSL wait:

客户端A 服务器| 1. 断开连接| | 2. 等待2MSL... | | (足够让之前连接的所有数据包都消失) | | 3. 这时候建立新连接| | (不会有旧数据包来捣乱) |

Simply put:

• The 2MSL wait is to allow all previous interactions (data packets) to be completely completed, and old data packets will not affect new connections.

💡 The essence of four waves

In life:

• Both parties must finish their words.
• Make sure the other person hears the farewell
• Give the other party enough time to process
• Can't disappear suddenly

In TCP:

• Ensure data integrity
• Both sides can close normally
• Preventing Data Loss
• Resources can be released correctly

Remember: each of the four waves is necessary to make network communication more reliable!

Summarize:

Through this article, the ins and outs of TCP's three-way handshake and four-way handshake should be clear. TCP is designed in this way to achieve reliable network communication: the three-way handshake ensures reliable two-way communication, sequence number synchronization, and avoids historical connections; the four-way handshake ensures complete data transmission, graceful connection closure, and prevents old connections from affecting new connections. Each seemingly cumbersome handshake and handshake is actually to solve specific network communication problems, reflecting the reliability and rigor of the TCP protocol. Once you understand the reasons behind these designs, you will understand the essence of the TCP protocol.