Have you ever thought about why TCP needs to handshake before sending data?

When I look at computer networks, there is always a question that I can't understand, that is, why TCP needs to have three handshakes first, then send data, and finally disconnect. Note that the question here is why it needs to be done first, and I emphasize again that it is the question of three handshakes before sending data, rather than the question of "why TCP does not have 2 or 4 handshakes" that appears after Baidu puts "why TCP needs to have three handshakes first" on Baidu. Sometimes I really have to complain that Baidu's algorithm is really not as good as Google's, as shown in the following figure:

Um... As for Google search, I won’t post the picture because it will have a bad impact as it requires software to bypass the firewall... Let’s continue with our topic and answer this question. Of course, this is my feeling. As I said before, “If you have any questions, please write your own opinions in the comment section to avoid misleading others.”

To answer this question, you must first know the structure of the TCP segment, as shown below:

What we want to talk about is the 16-bit window field in the TCP segment. The role of the window here is to achieve flow control. Why is flow control introduced? It comes from this: if the sender sends data faster than the receiver's application gets data (assuming that the data transmission process is not congested), then the receiver will lose chastity, that is, the data is overwritten, so the data transmission must be controlled, and the 16-bit window is introduced. How is it introduced?

It's like this: the sender and the receiver both have a buffer area (used to receive data from the network and submit it to the application). For the receiver, it has to maintain two variable values, one is the data read out by the application from the cache (represented by out); the other is the data received from the network (represented by in), then the remaining space in the receiver's cache is Buffer-(in - out) = window (assuming that Buffer represents the number of caches, in - out represents the number that the application has not read, that is, the number of caches occupied, the total minus the occupied space is the number of available spaces represented by window), then this window is the value to be written to the window, and the receiver will pass this value to the sender to indicate how much space I still have available.

The sender will also have a cache, and also need to maintain two variable values: one is the number of data that has been sent (send); the other is the number of data that has been confirmed (acked). Then send-acked means the number of data that has been sent but not yet confirmed, in other words, the data being transmitted (this is a better understanding, but it is a bit wrong). In order to prevent the receiver's cached data from being overwritten, the data being sent must be smaller than the receiver's window (send-acked < window).

The above is written to deeply understand the concept of window! ! ! This is just to prepare for understanding why TCP needs handshake! ! !

Let's briefly talk about the three-way handshake process:

• The first time, the client sends a short TCP message.
• The second time, the server sends a response and sets up the cache and variables.
• The third time, the client sends a reply and sets up the cache and variables.

Note that the cache is established during the three-way handshake. In other words, if A and B want to communicate, they must first agree on some parameters, such as the cache here. According to the above theory, the purpose of establishing a cache is to avoid unreliable data transmission (that is, to avoid data being overwritten). Therefore, before transmitting data, the two parties should make some agreements. In other words, when making a transaction, the place and time should be agreed upon before the transaction.

Well, in general, the so-called link is to allocate memory and other resources, and then avoid unreliable transmission, so as not to taint the name of TCP reliable transmission!!!