Background

Having been in a long-distance relationship with my girlfriend for over a year, I suggested that we video chat every night to maintain our feelings.

Since we started dating, we have managed to keep this up for over a year.

Problem

Sometimes during our chats, either my network or hers might be unstable, causing the video to freeze and making it impossible to hear each other. After a while, the connection would resume.

In the meantime, both parties might need to continuously confirm whether the network has recovered, but sometimes it goes like this:

She: “Can you hear me?”

I: “I can hear you, how about you?”

She: “Hello, can you hear me?”

I: “I can hear you, I can hear you, how about you?”

She: “Can you hear me?”

…..

This situation is quite frustrating. So how can we find a simple way for both of us to confirm we can hear each other?

Note: The following scenario is purely fictional.

Solution

Why does TCP establish a connection with three-way handshake instead of two or four?

TCP, or Transmission Control Protocol, is a reliable transport layer protocol with an IP protocol number of 6.

By the way, in principle, no data transmission can ensure absolute reliability; the three-way handshake is merely a basic requirement for ensuring reliability.

For example, during a phone call, our conversation goes like this:

This corresponds to the communication between the client and the server:

Thus, we have the following conversation:

I: “What is 1+1?”

She: “2, what is 2+2?”

I: “4”

First, both parties agree on the protocol:

1. If either party feels the network is not working properly, they can initiate an inquiry.

2. In any case, if no reply is received within 5 seconds after initiating an inquiry, it is assumed that the network is down.

3. If the network is down, wait 1 minute after the router before initiating an inquiry again.

For me, after initiating the inquiry of “What is 1+1?”

1. If no reply is received within 5 seconds, it is assumed that the network is down.

2. If a reply is received, I confirm that ① I can hear her message ② she can hear my message, and then reply with the answer to her question.

For her, when she feels the network is not working properly

1. If she does not receive my inquiry, she initiates an inquiry.

2. If she receives “What is 1+1?”, she confirms ① she can hear my message and then replies with the answer to my question and her question of “2, what is 2+2?”

3. If no reply “4” is received from me within 5 seconds, she confirms ② I cannot hear her message.

4. If she receives my reply “4” within 5 seconds, she confirms ② I can hear her message.

In this way, if the above conversation can be completed, it proves that both parties can confirm they can hear each other!

Can this story explain why TCP requires a three-way handshake …

About Four-Way Wavehand

First, the client sends a FIN to the server, requesting to close the data transmission.

When the server receives the client’s FIN, it sends an ACK back to the client, where the ack value equals FIN+SEQ.

Then the server sends a FIN to the client, telling the client to close the application.

When the client receives the server’s FIN, it replies with an ACK to the server, where the ack value equals FIN+SEQ.

Why Four-Way Wavehand?

To ensure that data can be completely transmitted.

When the passive party receives the active party’s FIN notification, it only indicates that the active party has no more data to send to the passive party.

However, it does not necessarily mean that the passive party has sent all its data to the active party completely, so the passive party will not close the SOCKET immediately; it may still need to send some data to the active party before

sending a FIN to the active party, indicating that it agrees to close the connection. Therefore, in most cases, the ACK and FIN messages are sent separately.

1. TCP Packet Format

TCP packet format diagram:

In the above diagram, several fields need to be highlighted:

(1) Sequence number: Seq number, 32 bits, used to identify the byte stream sent from the TCP source to the destination. The initiator marks this during data transmission.

(2) Acknowledgment number: Ack number, 32 bits, is only valid when the ACK flag is 1, Ack=Seq+1.

(3) Flags: There are 6 in total, namely URG, ACK, PSH, RST, SYN, FIN, etc., with specific meanings as follows:

(A) URG: Urgent pointer is valid.

(B) ACK: Acknowledgment number is valid.

(D) RST: Reset the connection.

(E) SYN: Initiate a new connection.

(F) FIN: Release a connection.

It is important to note:

(A) Do not confuse the acknowledgment number Ack with the ACK flag in the flags.

(B) The acknowledgment number Ack=initiator Req+1, paired on both ends.

2. Three-Way Handshake

TCP (Transmission Control Protocol) is a transport control protocol at the host-to-host layer, providing reliable connection services, and establishes a connection through a three-way handshake.

The TCP flag bits have 6 types:

SYN (synchronous connection establishment)

ACK (acknowledgment)

PSH (push transmission)

FIN (finish)

RST (reset)

URG (urgent)

Sequence number

Acknowledgment number

The so-called Three-Way Handshake refers to the process where a total of 3 packets are sent between the client and server to confirm the establishment of a TCP connection. In socket programming, this process is triggered by the client executing connect, and the entire process is illustrated in the following diagram:

(1) First handshake: The client sets the SYN flag to 1, randomly generates a value seq=J, and sends this packet to the server, the client enters SYN_SENT state and waits for server confirmation.

(2) Second handshake: The server, upon receiving the packet, knows the client is requesting to establish a connection because SYN=1. The server sets both SYN and ACK flags to 1, ack(number)=J+1, randomly generates a value seq=K, and sends this packet back to the client to confirm the connection request, the server enters SYN_RCVD state.

(3) Third handshake: The client receives the confirmation, checks if ack is J+1 and if ACK is 1. If correct, it sets the ACK flag to 1, ack=K+1, and sends this packet back to the server. The server checks if ack is K+1 and if ACK is 1, if correct, the connection is successfully established, and both the client and server enter ESTABLISHED state, completing the three-way handshake, after which the client and server can start transmitting data.

SYN Attack:

In the three-way handshake process, when the server sends SYN-ACK and is in the SYN_RCVD state before receiving the client’s ACK, this TCP connection is called half-open connect. When it receives the ACK, the server transitions to the ESTABLISHED state. SYN attacks occur when a client forges a large number of non-existent IP addresses in a short period and continually sends SYN packets to the server, which replies with acknowledgment packets and waits for the client’s confirmation. Since the source addresses do not exist, the server must keep resending until it times out. These forged SYN packets will occupy the unconnected queue for a long time, causing normal SYN requests to be discarded due to a full queue, leading to network congestion or even system paralysis. SYN attacks are a typical type of DDoS attack, and it is very simple to detect SYN attacks: if there are many half-open connections on the server and the source IP addresses are random, it can be concluded that a SYN attack has occurred. The following command can be used to check:

#netstat -nap | grep SYN_RECV

3. Four-Way Wavehand

The three-way handshake is well-known, and the four-way wavehand is probably less familiar. The so-called Four-Way Wavehand refers to terminating a TCP connection, meaning that when disconnecting a TCP connection, a total of 4 packets need to be sent between the client and the server to confirm the disconnection. In socket programming, this process is triggered by either the client or server executing close, and the entire process is illustrated in the following diagram:

Since TCP connections are full-duplex, each direction must be closed separately. This principle states that when one party completes its data transmission task, it sends a FIN to terminate the connection in that direction. Receiving a FIN only means that there will be no data flow in that direction; it does not mean that data cannot still be sent on this TCP connection until that direction also sends a FIN. The party that initiates the closure will execute an active close, while the other party will execute a passive close, as described in the diagram above.

(1) First wave: The client sends a FIN to close the data transmission from the client to the server, entering the FIN_WAIT_1 state.

(2) Second wave: The server receives the FIN and sends an ACK to the client, with the acknowledgment number equal to the received number +1 (similar to SYN, one FIN occupies one sequence number). The server enters CLOSE_WAIT state.

(3) Third wave: The server sends a FIN to close the data transmission from the server to the client, entering LAST_ACK state.

(4) Fourth wave: The client receives the FIN, enters TIME_WAIT state, and then sends an ACK to the server, with the acknowledgment number equal to the received number +1, and the server enters CLOSED state, completing the four-way wavehand.

The above describes a scenario where one party actively closes while the other passively closes. In practice, there may also be cases where both parties initiate an active close simultaneously, as illustrated in the following diagram:

The process and states are clearly shown in the above diagram, and will not be elaborated further; you can refer to the previous analysis steps for the four-way wavehand.

Notes

There are typically interview questions about the three-way handshake and four-way wavehand, which I provide for those interested:

(1) What is the three-way handshake or its process? What about the four-way wavehand? The answers are analyzed above.

(2) Why is establishing a connection a three-way handshake, but closing a connection requires four-way wavehand?

This is because when the server is in the LISTEN state and receives a SYN packet requesting to establish a connection, it sends both ACK and SYN in one packet to the client. However, when closing a connection, upon receiving the FIN packet from the other party, it only indicates that the other party will no longer send data but can still receive data. The current party may not have sent all its data to the other party, so it can either close immediately or send some data to the other party before sending a FIN packet to indicate agreement to close the connection. Therefore, the ACK and FIN messages are generally sent separately.