[Computer Network] Transport Layer Protocol-TCP (Part 2)

1. Three-way handshake

SYN: It is a connection request message (three-way handshake), and the TCP header is sent

The essence of the three-way handshake is to establish a link. What is a link?

There will be multiple established links in the operating system. The operating system needs to manage these established links. The
essence of management is to first describe
the data structure maintained in the organization. In order to manage the connection maintenance in the operating system,
the struct tcp_link structure is first used. body, which contains various linked fields,
and then uses linked lists to organize them


There is a cost to creating and maintaining a link
1. Consumption of memory space (if you want to create a link, you need to create a link object, so you need a new/nalloc link object)
2. Consumption of CPU resources (maintenance timer to ensure timeout restart Transmission, etc.)

overall process

As long as the client sends SYN, the client's status changes to SYN_SENT, which is called synchronous transmission.
As long as the server receives SYN, the server's status changes to SYN_RCVD
. The server then responds with SYN+ACK. After the response,
the client receives ACK. And when ACK is sent, the client's three-way handshake is completed.

The three-way handshake on the server side is not completed until the server side receives the ACK.

Message loss problem during three-way handshake

If the first message is lost, that is, the SYN is lost,
the server will not be affected in any way because it has never received a message.


If the second message is lost, that is, SYN+ACK is lost,
the three-way handshake process between the two parties will not succeed because the connection between the two parties has not been established.


If the third message is lost, that is, the ACK is lost.
For the client, it only needs to send the ACK, and the three-way handshake is considered complete.
For the server, the three-way handshake is considered complete only when the ACK message is received.


Therefore, when the ACK message is lost, the client thinks it is completed, but the server thinks it is not completed
. At this time, the client thinks it is established, so it will send a message directly to the server
. If the server is not established, the server immediately reconnects . Set, in response to RST,
the client will close the connection and then re-establish the connection.

Why is 2-way handshake not allowed?

The 2-way handshake is not possible because it is very easy to be attacked.
It is very easy for a machine to continuously send you a massive amount of SYN. ​​After the server receives the SYN, it will directly send an ACK, regardless of whether the client has received it or not. The server has already considered that the establishment is complete
. There
is a cost to maintain the connection. If the machine sends a large number of SYNs
to the server for immediate maintenance, memory will be consumed immediately. A lot of memory will be consumed, and the server may not be able to provide services to normal users.

Why three handshakes?

1. There are no obvious design loopholes. Once an exception occurs when establishing a connection, the cost is grafted onto the client, while the server-side cost is lower.

2. Verify the smoothness of the communication channel between both parties.
The three-way handshake is the minimum cost to verify the smoothness of the full-duplex communication channel.


During the first handshake, it can be proven that the client can send messages.
During the second handshake, it can be proven that the client can receive messages.

During the first handshake, it proves that the server can receive the message.
During the third handshake, it proves that the server can send the message
(only when the client receives the message and responds, can it prove that the server sent the message)

2. Wave four times

When disconnecting, the client may want to disconnect, but the server may not want to disconnect. The
server may want to disconnect, but the client may not want to disconnect.

To disconnect, it is necessary to obtain the consent of both parties, not just one party, because the status of both parties is equal.
Wave four times to disconnect both parties at the minimum cost.

overall process

FIN: It is a request message for disconnection

The first wave:
after sending the FIN message, the client status is FIN_WAIT 1.
The server receives the FIN message, and the server status is CLOSE_WAIT

The second wave:
When the client receives the ACK message in response from the server, the client status is FIN_WAIT 2

The third wave:
If the server also wants to disconnect, it sends a FIN message to the client, and then the server enters the LAST_ACK state .

The fourth wave:
After receiving the FIN message from the server, the client will send an ACK response to the server.
Since the client actively shuts down, the client then enters the TIME_WAIT state, and after the server receives the ACK response from the client , the server enters the CLOSE state

The client enters the TIME_WAIT state and needs to wait for 2MSL before the client enters the CLOSE state.


After sending the last ACK message, the client considers that four waves have been completed. When
the server receives the ACK message, the server considers that four waves have been completed.

The party that actively disconnects will definitely send the last ACK message.


Why wait for 2MSL

The TCP protocol stipulates that the party that actively closes the connection must enter the final TIME_WAIT state and wait for 2MSL.
MSL indicates the maximum time a message exists in the network.
TCP stipulates that it generally has to wait for 2 MSL times.
The maximum survival time of a message sent is 1 MSL, the other party needs to respond in the future, and the response time is also an MSL


Wait for 2MSL
to ensure that all unreceived or late message segments in both transmission directions have disappeared.

If you do not wait for 2MSL
, the connection may have just been disconnected, and there will be residual messages in the network before the connection was disconnected. After the connection is disconnected, the server will be reconnected immediately. When the
connection is established, there will be historical residual messages. file exists, it will affect the normal receiving data corresponding to the receiver.

Therefore, try to ensure that historical messages dissipate and do not affect the next normal communication.

3. Flow control

When the client and server communicate, they have their own sending and receiving buffers.
When the client sends data, it sends the data in the client's sending buffer to the server's receiving buffer.
When the server sends data, it sends the data in the server's sending buffer. The data in the area is sent to the client’s receive buffer.

In the confirmation response, the 16-bit window size can be carried to indicate the size of the remaining space in the receiving buffer, that is, the carrying capacity. As the
receiver, knowing the carrying capacity of data reception can allow the sender to send data slower when sending data. , resulting in the ability to receive
this operation is called flow control


If the receiving end finds that its buffer is almost full, it will set the window size to a smaller value and notify the sending end. If the
sending end receives this window, it will slow down its sending speed.

If the buffer at the receiving end is full, the window will be set to 0. At this time, the sender will no longer send data, but it needs to send a window detection data segment regularly so that the receiving end can tell the sender the window size.

4. Sliding window

consensus

For each data segment sent, an ACK confirmation response must be given. After receiving the ACK, the next data segment is sent.
However, the efficiency of sending and receiving is very low.


Concurrent access is highly efficient, but it also has an upper limit on receiving capabilities
. The sender must send concurrently under the premise that the other party can accept it.

The maximum amount of data the sender can send to the other party at one time is determined by the other party's window size .

General case of sliding windows

Because the receiving capacity of the receiver is limited,
the sending speed of the sender is affected by the remaining space in the receiving buffer of the other party.

The sliding window is part of the sending buffer.
This part of the data in the sliding window: you do not need to receive a response for the time being, you can send it directly.


Because of the existence of the sliding window, the sending buffer is cut into three parts.
The left side is called already sent and confirmed
and can be overwritten, that is, invalid data.

The right side is called the sliding window of the unsent data area
: it can be sent directly, but no response has been received.
The size of the sliding window is related to the receiving ability of the other party.

Understanding sliding windows

Think of the send buffer as an array of char type.
Because the char type only occupies one byte and reflects the byte stream,
the array is called sendbuffer.


The essence of the sliding window is an interval window maintained by two array subscripts (start end).
Sliding means that the start and end subscripts are moved ++

Special case of sliding windows

Case 1 - Can the sliding window only slide to the right? Can I swipe left?

You cannot slide to the left because the area on the left contains data that has been sent and received confirmation, which is meaningless,
so you can only slide to the right.


Case 2 - Can the sliding window become larger or smaller? Can it become 0? What does it mean after changing to 0?

It can become larger/smaller. The larger or smaller sliding window depends on the receiving ability of the other party. The sliding window
becomes larger, that is, the end subscript increases.
The sliding window becomes smaller, that is, the end subscript does not move, and the start subscript moves to the right.

So the size of the sliding window is floating, not fixed.

The upper application layer of the receiver never fetches data, which will cause the remaining space of the receiving buffer to become smaller and smaller until it reaches 0. This will cause the
sender to send less and less data until it reaches 0. That is, the sliding window of 0 means that the other party Unable to receive
start and end pointing to the same


Case 3 - There are multiple messages in the sliding window that can be sent directly. What if the first one is lost?

If there are messages 1000 2000 3000 4000
and if the first message 1000 is lost, there are two situations

Case 1: The message is received, but the acknowledgment response (ACK) is lost.
According to the acknowledgment sequence number, when the acknowledgment response 2001 corresponding to message 2000 is received, the corresponding message 1000 is known, and the receiver must have received it.


Scenario 2: The data of the first message 1000 is lost

At this time, because the first message is lost, that is, the data in the range 1001-2000 is lost, the confirmation sequence number cannot return 2001 and 3001 because 2001 means that
all the sequence numbers before 2000 have been received, and 1000 has not been received,
so Only the confirmation sequence number 1001 can be returned, which means that the sequence numbers before 1000 have been received,
so many duplicate ACK sequence numbers will be received, and TCP will recognize that the packet has been lost and retransmit after a timeout.

To support retransmission, the data must be temporarily saved and saved in a sliding window.

Guess you like

Origin blog.csdn.net/qq_62939852/article/details/132911028