Background: I have been in a long-distance relationship with my girlfriend for over a year. To maintain our relationship, I suggested that we video chat every night.
Since we started dating, we have managed to stick to this for over a year.
Author: Champin, Original:
https://my.oschina.net/u/3708120/blog/1581023
Issue
Sometimes during our chats, either my network or hers might be poor, causing the video to freeze and the audio to drop, which only resumes after a while.
During this time, both sides may need to constantly check if the network has recovered, but sometimes it goes like this:
She: “Can you hear me?”
I: “I can hear you now, how about you?”
She: “Hello, can you hear me?”
I: “I can hear you, can you hear me?”
She: “Can you hear me?”
…..
This situation is quite frustrating. So how can we find a simple way for both of us to confirm that we can hear each other?
Note: The following scenario is purely fictional.
Solution
Why does TCP establish a connection with a three-way handshake instead of two or four?
TCP, known as the 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 communication between the client and server:
Thus, we have the following dialogue:
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 that the network situation is not right, either can initiate an inquiry.
2. Under any circumstances, if no response is received within 5 seconds after initiating an inquiry, it is assumed that the network is down.
3. In case of network disconnection, 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 response is received within 5 seconds, I assume the network is down.
2. If I receive a response, 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 that the network situation is not right:
1. If she has not received my inquiry, she initiates an inquiry.
2. If she receives “What is 1+1?”, she confirms ① she can hear my message, then replies with the answer to my question and her question, “2, what is 2+2?”
3. If no response “4” is received within 5 seconds, she confirms ② I cannot hear her message.
4. If she receives my response “4” within 5 seconds, she confirms ② I can hear her message.
In this way, if the above conversation is 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 Wave
First, the client sends a FIN to the server to request to close data transmission.
When the server receives the client’s FIN, it sends an ACK back to the client, with the ack value equal to 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, with the ack value equal to FIN+SEQ.
Why Four-Way Wave?
To ensure that data can be completely transmitted.
When the passive party receives the active party’s FIN message, it only indicates that the active party has no more data to send to the passive party.
However, it does not mean that all data from the passive party has been completely sent to the active party, so the passive party will not immediately close the SOCKET. It may still need to send some data to the active party before sending the FIN message to inform the active party that it agrees to close the connection, so in most cases, the ACK and FIN messages are sent separately.
1. TCP Packet Format
TCP packet format diagram:
In the above image, 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, marked by the initiating party when sending data.
(2) Acknowledgment Number: Ack number, 32 bits, is only valid when the ACK flag is set to 1, Ack=Seq+1.
(3) Flag Bits: There are 6 in total, namely URG, ACK, PSH, RST, SYN, FIN, etc., with the following meanings:
(A) URG: Urgent pointer is valid.
(B) ACK: Acknowledgment number is valid.
(C) PSH: The receiving party should pass this packet to the application layer as soon as possible.
(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 in the flag bits.
(B) Acknowledgment number Ack=Initiating party Req+1, paired on both ends.
2. Three-Way Handshake
TCP (Transmission Control Protocol) is the transport control protocol for host-to-host, providing reliable connection services, using three-way handshakes to confirm the establishment of a connection.
The bit code is the TCP flag, which has 6 types:
SYN (synchronous connection establishment)
ACK (acknowledgment)
PSH (push transmission)
FIN (finish)
RST (reset)
URG (urgent)
Sequence number
Acknowledge number
Establish
The so-called three-way handshake (Three-Way Handshake) refers to the establishment of a TCP connection, which requires a total of 3 packets sent by the client and server to confirm the establishment of the connection.
In socket programming, this process is triggered by the client executing connect, and the entire process is shown in the diagram below:
(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 the SYN_SENT state, waiting for the Server to confirm.
(2) Second handshake: The Server receives the packet, knows the Client is requesting to establish a connection by the SYN=1 flag. 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 the 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 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 Client and Server enter the ESTABLISHED state, completing the three-way handshake, after which Client and Server can start transmitting data.
SYN Attack:
During the three-way handshake process, the TCP connection between the Server sending SYN-ACK and receiving the Client’s ACK is called a half connection (half-open connection). At this point, the Server is in the SYN_RCVD state. When it receives the ACK, the Server transitions to the ESTABLISHED state. SYN attack refers to the Client forging a large number of non-existent IP addresses within a short time and continuously sending SYN packets to the Server. The Server replies with acknowledgment packets and waits for the Client’s confirmation. Since the source address is non-existent, the Server needs to 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 dropped due to a full queue, leading to network congestion or even system failure. SYN attacks are a typical DDOS attack, and detecting a SYN attack is very simple: if there are a large number of half connections on the Server with randomly generated source IP addresses, it can be concluded that a SYN attack has occurred. The following command can be used to check for this:
#netstat -nap | grep SYN_RECV
3. Four-Way Wave
The three-way handshake is well-known, while the four-way wave is probably less familiar… The so-called four-way wave (Four-Way Wave) refers to terminating a TCP connection, meaning that a total of 4 packets need to be sent by the client and server to confirm the disconnection of the connection. In socket programming, this process is triggered by either the client or the server executing close, and the entire process is illustrated in the diagram below:
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 more data flow in that direction, i.e., no more data will be received, but data can still be sent on this TCP connection until FIN is also sent in that direction. The party that initiates the closure will execute an active close, while the other party will perform a passive close, as depicted in the diagram above.
(1) First wave: The Client sends a FIN to close the data transmission from Client to Server, and the Client enters the FIN_WAIT_1 state.
(2) Second wave: The Server receives the FIN and sends an ACK back 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 the CLOSE_WAIT state.
(3) Third wave: The Server sends a FIN to close the data transmission from Server to Client, and the Server enters the LAST_ACK state.
(4) Fourth wave: The Client receives the FIN, enters the TIME_WAIT state, and then sends an ACK back to the Server, with the acknowledgment number equal to the received number +1. The Server enters the CLOSED state, completing the four-way wave.
The above describes the situation where one party actively closes while the other passively closes. In practice, there may also be cases where both parties initiate active closure simultaneously, as shown in the diagram below:
The process and states are clearly illustrated in the above diagram, so there is no need to elaborate further. You can refer to the previous analysis of the four-way wave.
4. Notes
Typical interview questions often arise regarding the three-way handshake and four-way wave. Here are some questions for those interested:
(1) What is the three-way handshake or its process? What about the four-way wave? The answers are analyzed above.
(2) Why is the connection establishment a three-way handshake while the connection closure is a four-way wave?
This is because when the server in LISTEN state receives the SYN packet requesting to establish a connection, it sends the ACK and SYN in one packet back to the client. However, when closing the connection, receiving the FIN packet from the other party only indicates that the other party will no longer send data, but can still receive data. The party may not have sent all data to the other party, so it may either close immediately or send some data to the other party before sending the FIN packet to indicate agreement to close the connection. Therefore, the ACK and FIN are generally sent separately.
K8S Training Recommendation
Kubernetes offline practical training, employing a new training model of 3+1+1 (3 days of offline practical training, free re-attendance within a year, and the first 10 registrants for each session can participate in a free online live class worth 3600 yuan). Experienced frontline instructors, practical environment practice, on-site Q&A interaction, covering training content: Docker aspects: Docker architecture, images, data storage, networking, and best practices. Practical Kubernetes content, Kubernetes design, Pods, common object operations, Kubernetes scheduling system, QoS, Helm, networking, storage, CI/CD, log monitoring, etc.
Beijing: May 10-12
Registration: https://www.bagevent.com/event/2376547
Shanghai: May 17-19
Registration: https://www.bagevent.com/event/2409655
Shenzhen: May 24-26
Registration: https://www.bagevent.com/event/2409699
Recommended Reading
-
Comparison of Kubernetes Flannel, Calico, Canal, and Weave
-
Deploying API Gateway Kong using Kubernetes
-
Discussing Kubernetes architecture in production environments
-
Nginx ranks first in usage, directly challenging Apache’s position
-
Docker Hub hacked, 190,000 accounts leaked
-
From microservices to Service Mesh, exploring enterprise architecture evolution
-
JD Technology | Kubernetes practice with contiv supporting non-docker container runtimes
-
Understanding the differences and relationships between web servers, application servers, web containers, and reverse proxy servers in one article