Why does TCP require three-way handshake to establish a connection?

The TCP protocol is a network protocol that we come into contact with almost every day. The establishment of most network connections is based on the TCP protocol. Anyone who has studied computer networking or has a little understanding of the TCP protocol knows that using the TCP protocol to establish a connection requires After three-way handshake.

If let us briefly talk about the process of TCP connection establishment, I believe that many people who have prepared for the interview will know very well, but once you want to delve into "Why does TCP establish a connection need three-way handshake? ”, the author believes that most people have no way to answer this question or will give the wrong answer, this article will discuss why we need three-way handshake to establish a TCP connection?

It should be noted that we will focus on why a "three-way handshake" is required to establish a connection with TCP, and *not only* why a "three-way" handshake is required.

Overview

Before analyzing today's problems in detail, we can first understand the most common error analogy. This error analogy to the TCP connection process misleads many people. The author also believes that it can describe the establishment of TCP well for a long period of time. Why does the connection require a three-way handshake:

  1. Can you hear it?
  2. I can hear it, can you hear it?
  3. I can also hear;

This kind of use of analogy to explain problems often leads to the embarrassing situation of "nine mistakes out of ten analogies". If someone uses analogy to answer your why, you need to think carefully about where there are loopholes in their analogy; analogy brings There are often only one-sided similarities in the explanations of the Why the analogy here is problematic, readers can also read the rest of the content with questions.

When many people try to answer or think about this question, they actually focus on the three of the three handshakes. This is indeed very important, but if we re-examine this question, do we really know "what is a connection"? Only by knowing the definition of connection can we try to answer why TCP needs three handshakes to establish a connection.

The reliability and flow control mechanisms described above require that TCPs initialize and maintain certain status information for each data stream. The combination of this information, including sockets, sequence numbers, and window sizes, is called a connection.

The RFC 793 - Transmission Control Protocol document defines very clearly what a connection in TCP is, let's briefly summarize it: the information used to ensure reliability and flow control mechanisms, including Socket, sequence number, and window size is called a connection.

Therefore, establishing a TCP connection means that both parties of the communication need to reach a consensus on the above three kinds of information. A pair of sockets in the connection is composed of Internet address identifiers and ports. The window size is mainly used for flow control, and the final serial number is It is used to track the serial number of the data packet sent by the communication initiator. The receiver can confirm the successful reception of a data packet to the sender through the serial number.

At this point, we have transformed the original question into "Why does it take three-way handshake to initialize Sockets, window size and initial sequence number? ’, then we start to analyze this refined problem and find an explanation.

Private message me to receive the latest and most complete C++ audio and video learning and improvement materials, including ( C/C++ , Linux , FFmpeg , webRTC , rtmp , hls , rtsp , ffplay , srs )

design

This article will mainly introduce why we need to initialize Sockets, window size, initial sequence number and establish TCP connection through three-way handshake from the following aspects:

  • A three-way handshake can prevent the initialization of repeated historical connections;
  • The initial serial number of the communication parties can be initialized only through the three-way handshake;
  • Discuss the possibility of establishing a connection with other handshakes;

The first of these arguments is the main reason why TCP chooses to use the three-way handshake, the other reasons are relatively minor, and we discuss them here only to enrich the whole perspective , by understanding this interesting design decision in many ways.

historical connection

RFC 793 - Transmission Control Protocol actually points out the primary reason why TCP connections use three-way handshakes - in order to prevent the confusion caused by the repeated connection initialization in history, and prevent the two parties communicating using the TCP protocol from establishing a wrong connection.

The principle reason for the three-way handshake is to prevent old duplicate connection initiations from causing confusion.

 

Imagine this scenario. If the number of communications between the two parties is only twice, once the sender sends a request to establish a connection, it has no way to withdraw this request. If the network is in complex or poor network conditions, the sender continuously sends For multiple requests to establish a connection, if the TCP connection can only be communicated twice, the receiver can only choose to accept or reject the request initiated by the sender. It is not clear whether this request is a connection that expired early due to network congestion.

Therefore, TCP chooses to use a three-way handshake to establish a connection and introduces  RST this control message into the connection. When the receiver receives the request, it will send the message from the  SEQ+1 sender to the other party. At this time, the sender determines whether the current connection is historical or not. connect:

  • If the current connection is a historical connection, that is,  SEQ expired or timed out, the sender will directly send a  RST control message to abort this connection;
  • If the current connection is not a historical connection, the sender will send a  ACK control message, and both parties will successfully establish a connection;

The three-way handshake and  RST control message are used to give the sender the final control of whether to establish a connection, because only the sender has enough context to judge whether the current connection is wrong or expired. main reason.

initial serial number

Another important reason for using the three-way handshake is that both parties need to obtain an initialization sequence number for sending information. As a reliable transport layer protocol, TCP needs to build a reliable transport layer in an unstable network environment. The uncertainty of the data can lead to problems such as missing packets and out-of-order packets. Common problems may include:

  • Data packets are sent multiple times by the sender, causing data duplication;
  • Data packets are routed or lost by other nodes during transmission;
  • Data packets may not arrive at the receiver in the order in which they were sent;

In order to solve the above-mentioned possible problems, the TCP protocol requires the sender to add the "serial number" field to the data packet. With the serial number corresponding to the data packet, we can:

  • The receiver can deduplicate the duplicate data packets through the sequence number;
  • The sender will repeat the transmission when the corresponding data packet is not ACKed;
  • The receiver can reorder packets based on their sequence numbers;

The serial number plays a very important role in the TCP connection. As part of the TCP connection, the initial serial number also needs to be initialized during the three-way handshake. Since both parties of the TCP connection communication need to obtain the initial serial number, they actually need to send  SYN control to each other. The message carries the desired initialization sequence number  , and the other party  will confirm it through the   control message and  after SEQreceiving the  message  .SYNACKSEQ+1

As shown in the figure above, the two communicating parties  TCP A/B send  SYN and  ACK control messages to each other respectively. After both communicating parties have obtained their desired initialization sequence numbers, they can start the communication. Due to the design of the TCP message header, we can use the middle two. Combining these communications into one, TCP B we can  TCP A send  ACK and  SYN control messages simultaneously, which helps us reduce four communications to three.

A three way handshake is necessary because sequence numbers are not tied to a global clock in the network, and TCPs may have different mechanisms for picking the ISN’s. The receiver of the first SYN has no way of knowing whether the segment was an old delayed one or not, unless it remembers the last sequence number used on the connection (which is not always possible), and so it must ask the sender to verify this SYN. The three way handshake and the advantages of a clock-driven scheme are discussed in [3].

In addition, as a distributed system, the network does not have a global clock for counting, and TCP can initialize the serial number through different mechanisms. As the receiver of the TCP connection, we cannot judge the incoming Whether the initialization serial number has expired, so we need to leave it to the other party to judge. The initiator of the TCP connection can judge whether the connection has expired by saving the sent serial number. It is unrealistic for the receiver to save and judge the serial number. Once again reinforces the point we made in the previous section - initialization to avoid misconnection of history.

number of communications

When we discuss the number of communications required by TCP to establish a connection, we often focus on why a connection can be established after three communications, rather than two or four; it is often meaningless to discuss using more communications to establish a connection, because We can always use more communications to exchange the same information , so it is technically possible to establish a connection using four, five, or more.

 This problem of increasing the number of TCP connection communications is often not necessary to discuss. What we are pursuing is to complete the exchange of information with fewer communications times (theoretical boundaries), which is why we have repeatedly emphasized in the previous two sections. There is no way to establish a TCP connection using "two-way handshake", and using three-way handshake is the minimum number of times required to establish a connection.

Summarize

In this article, we discussed why the TCP connection needs to go through three handshakes. Before analyzing this problem in detail, we first rethought what a TCP connection is. RFC 793 - Transmission Control Protocol - IETF Tools is very clear about TCP connections. Definition of - Data used to ensure reliability and flow control mechanisms, including sockets, sequence numbers, and window sizes.

When TCP establishes a connection, the three-way handshake can effectively avoid the establishment of historical wrong connections and reduce unnecessary resource consumption by both parties. It can guarantee their transmission order and will not be confused due to network transmission problems. The reasons for not using "two-way handshake" and "four-way handshake" here are very clear:

  • "Two-way handshake": The initialization of the historical error connection cannot be avoided, and the resources of the receiver are wasted;
  • "Four-way handshake": The design of the TCP protocol allows us to transmit  ACK and  SYN two control information at the same time, reducing the number of communications, so there is no need to use more communications to transmit the same information;

Let's go back to the question asked at the beginning of the article, why is it wrong to use an analogy to explain that TCP uses a three-way handshake? This is mainly because the analogy does not explain the core problem - avoiding repeated connections in history. In the end, we still look at some open-ended related issues. Interested readers can think about the following questions carefully:

  • Is there any other way to ensure that the message is not duplicated or lost besides using the serial number?
  • Does the UDP protocol have the concept of connection, and can it guarantee the reliability of data transmission?

If you have any questions about the content of the article or want to know more about the reasons behind some design decisions in software engineering, you can leave a message below the blog. The author will promptly reply to the questions related to this article and select the appropriate topic as the follow-up content.

Guess you like

Origin blog.csdn.net/m0_60259116/article/details/124366105