concept
- TCP provides a connection-oriented, reliable byte stream service
- In a TCP connection, only two parties communicate with each other. TCP cannot be used for broadcast and multicast
- TCP uses checksum, confirmation and retransmission mechanisms to ensure reliable transmission
- TCP sorts the data sections, and uses cumulative confirmation to ensure that the order of the data is unchanged and non-repetitive
- TCP uses a sliding window mechanism to achieve flow control and congestion control by dynamically changing the size of the window
Three handshake
- The client wants to establish a connection and sends a packet to establish a connection to the server (SYN = 1, seq = x). Enter the SYN_SEND state by yourself
- After receiving the message, the server knows that the client wants to establish a connection, so it sends an acknowledgment (ACK = 1, ack = x + 1, SYN = 1, seq = y) to the client. Then enter the SYN_RCVD state.
- After the client receives the message and knows that the server can establish a connection, it sends an acknowledgment packet (ACK = 1, ack = y+1) here, and enters the link state. The server also enters the connection state after receiving it, so that the connection is established.
Why is it three times instead of two or four times
Let me first talk about why not twice?
For example, the client initiates a Syn packet, but this packet is stuck in the network and does not arrive late. In this way, due to the TCP retransmission mechanism, he will send another Syn packet in the past. At this time, due to the two handshake, this The connection is established. This seems to be okay, but if we disconnect, the Syn packet that we are stuck in the network suddenly arrives at the server. At this time, due to two handshake, the server and the client establish a connection, but the client The terminal has been disconnected. . . . .
So this is an error, so a three-way handshake is required.
Then why not four times?
To be honest, this question is a little bit so. . . I can handle things steadily three times, so why should I do it four times.
Can data be carried in the three-way handshake
Yes, the third time, but not the first two.
According to the requirements of the protocol document, packets with the SYN flag are not allowed to carry data.
Because the connection has not been established in the first two times, if someone wants to attack the server, then he can put a large amount of data in the SYN message of the first handshake. As a result, the server must spend a lot of time and resources to process the data. Increase the risk of server being attacked.
Wave four times
-
First, the client sends a FIN packet (FIN = 1, seq = x) to the server, telling the server that my message is finished and I can disconnect, but I can still receive data. The client enters FIN_WAIT1.
-
After the server receives it, it will send an acknowledgment message (ACK = 1, ack = x + 1) to tell the client that it has received the message just now, but is not ready to close the connection. The server enters CLOSE_WAIT, the client enters FIN_WAIT2 after receiving it
-
Then when the server is ready to close the connection, it sends a close message (FIN = 1, seq = y) to the client, and then enters the LAST_ACK state by itself.
-
After the client receives it, it knows that it can disconnect, and then sends an acknowledgement packet (ACK = 1, ack = y + 1), and then enters the TIME_WAIT state. After the server receives the acknowledgement packet, it disconnects and enters CLOSE state.
After the client enters the TIME_WAIT state, it will wait for two MSLs (maximum lifetime of messages). If it does not receive any message from the server, it is considered that the server has been shut down normally, and it will shut itself down.
Why wait for two MSL
If you don’t wait and the client closes the connection directly, then when the server has a lot of data to send to the client and is still on the way, and at this time the client’s interface happens to be occupied by a new application, then useless data is received package.
So why two instead of one, because
- 1 MSL ensures that the final ACK message of the active closing party with four waves can reach the opposite end
- Another MSL ensures that the FIN message that the opposite end does not receive ACK retransmission can reach
Accumulative confirmation timeout retransmission error retransmission
First of all, both TCP and UDP split the data into segments during transmission.
For TCP, it will give each packet an ID, determine the starting ID when establishing a connection, and then send them one by one according to the ID. In order to ensure that no packet is lost, every message sent must be responded to. When a certain ID is received, this is called cumulative confirmation or cumulative response.
If the confirmation message is not received within a period of time, it will be considered that the receiver has not received the packet sent in the past, and then it will be resent. This is the timeout retransmission mechanism.
For each packet, an end-to-end checksum is required. If the checksum at the receiving end is wrong, TCP will discard the packet and not confirm the receipt of the packet, and wait for the sender to resend it.
After just received, each packet will have an ID. If the packet with this ID is not received, it will be resent, so that the order is guaranteed by the ID.
flow control
Ensure order
If the sender sends the data too fast and the receiver is too late to receive it, then there will be packet loss. In order to avoid packet loss, control the sender's sending speed so that the receiver has time to receive, this is flow control. The fundamental purpose of flow control is to prevent packet loss, which constitutes one aspect of TCP reliability.
It is implemented by the sliding window protocol (continuous ARQ protocol). The sliding window protocol not only ensures the error-free and orderly reception of packets, but also realizes flow control. The main way is to include the size of its own receiving window in the ACK returned by the receiver, and use the size to control the sender's data transmission.
Sliding window protocol (continuous ARQ protocol)
First, the two parties shake hands three times and initialize their respective window sizes, both of which are 200 bytes.
If the current sender sends 100 bytes to the receiver, then for the sender, SND.NXT must of course be shifted by 100 bytes to the right, which means that the current one is 可用窗口reduced by 100 bytes, which is easy to understand. .
Now these 100 have arrived at the receiving end and are placed in the buffer queue of the receiving end. However, this time due to the large load, the receiving side can not handle so many bytes, only 40 bytes processed, and the remaining 60bytes are left in the buffer queue.
Note that the situation at the receiving end at this time is that the processing capacity is not enough, you send me less, so the receiving window of the receiving end should be reduced at this time, specifically, it is reduced by 60 bytes, and changed from 200 bytes. It becomes 140 bytes because there are still 60 bytes in the buffer queue that have not been taken away by the application.
Therefore, the receiving end will bring a reduced sliding window of 140 bytes in the header of the ACK message, and the sending end will adjust the size of the sending window to 140 bytes accordingly.
At this time, for the sender, the already sent and confirmed part is increased by 40 bytes, that is, SND.UNA is shifted to the right by 40 bytes, and the sending window is reduced to 140 bytes.
Because the channel utilization of the stop waiting ARQ protocol is too low, it is necessary to use the continuous ARQ protocol to improve. This protocol will continuously send a group of data packets, and then wait for the ACK of these data packets.
The sender uses pipeline transmission. Pipeline transmission means that the sender can send multiple packets continuously, without having to stop and wait for the other party's confirmation after sending a packet. The continuous ARQ protocol is usually used in combination with the sliding window protocol. The sender needs to maintain a sending window, as shown in the following figure:
[External link image transfer failed. The source site may have an anti-leech link mechanism. It is recommended to save the image and upload it directly (img-bZJ0KSBk-1615709507345)(https://s3-us-west-2.amazonaws.com/secure.notion -static.com/639af480-4677-49fc-9c59-51e97627a7f3/Untitled.png)]
Figure (a) is the sending window maintained by the sender. Its meaning is that all 5 packets in the sending window can be sent out continuously without waiting for the other party's confirmation, which improves the channel utilization.
The continuous ARQ protocol stipulates that each time the sender receives an acknowledgment, it slides the sending window forward by one packet position. For example, in Figure (b) above, when the sender receives the confirmation of the first packet, it moves the sending window forward by one packet. If the first 5 packets have been sent, the 6th packet in the window can now be sent.
rule:
- All data that has been sent must be temporarily reserved until the confirmation is received, so that it can be used when retransmission is timed out.
- Only when the sender A receives the receiver's confirmation message segment, the sender window can slide forward several sequence numbers.
- When the data sent by the sender A does not receive a confirmation after a period of time (controlled by the timeout timer), it is necessary to use the back N-step protocol to return to the place where the confirmation number was finally received and resend this part of the data.
Congestion control
It is to prevent too much data from being injected into the network and avoid excessive network load; the commonly used methods are: (1) slow start, congestion avoidance (2) fast retransmission and fast recovery.
Slow start
The sender maintains a congestion window (cwnd). The size of the congestion window depends on the degree of network congestion and changes dynamically.
The idea of slow start is to not send a large amount of data at first, but send cwnd from 1 to test the degree of network congestion, and then increase the size of the congestion window from small to large.
For example: cwnd is 1, and then after the sender receives the confirmation message returned by the receiver, cwnd becomes 2 to send, and then after receiving the confirmation message, cwnd becomes 4. . . The core is to expand twice every time.
But in order to prevent congestion caused by excessive growth of cwnd, a slow start threshold ssthresh state variable needs to be set:
- When cwnd <ssthresh use slow start
- When cwnd = ssthresh, slow start and congestion avoidance are both possible
- Use congestion avoidance when cwnd> ssthresh
Congestion avoidance
When cwnd> ssthresh, start slowly and double cwnd every time, which is a bit inappropriate. At this time, you can use congestion avoidance, each time cwnd+1, so that it grows slowly according to the linear law.
However, regardless of whether it is in the slow start phase or the congestion avoidance phase, as long as there is network congestion, the value of ssthresh will be set to half of the sending window when congestion occurs. Then set cwnd to 1, and start from slow again.
AIMD algorithm
Multiplicative Decrease and Additive Increase
"Multiplicative reduction" refers to whether it is in the slow start phase or in the congestion avoidance phase, as long as the sender judges that the network is congested, the slow start threshold ssthresh is set to half the size of the sending window when congestion occurs, and the slow start is executed. Algorithm, so when the network is frequently congested, ssthresh drops quickly to greatly reduce the number of packets injected into the network. "Additional increase" refers to the slow increase of the congestion window after the implementation of the congestion avoidance algorithm to prevent premature congestion. Often combined to become the AIMD algorithm.
Fast retransmission
Fast retransmission requires the receiver to send a repeat confirmation immediately after receiving an out-of-sequence segment, instead of waiting for the confirmation to be piggybacked when sending the data. The fast retransmission algorithm stipulates that as long as the sender receives three repeated acknowledgments in a row, it should immediately retransmit the message segment that the other party has not received, without having to wait for the set retransmission timer to expire.
For example, if the 5th packet is lost, even if the 6th and 7th packets arrive at the receiving end, the receiving end will always return the ACK of the 4th packet. When the sender receives 3 duplicate ACKs, it realizes that the packet is lost, so it retransmits immediately, without waiting for an RTO time to retransmit.
Quick recovery
When the sender receives three repeated confirmations in a row, it executes the "multiplication reduction" algorithm to halve the ssthresh threshold (in order to prevent network congestion). But then the slow start algorithm is not executed, but the congestion avoidance algorithm is started.
What are congestion control and flow control, and the difference between the two?
- Congestion control: Speed limitation of routing and link transmission in the network to avoid network overload; includes four processes: slow start, congestion avoidance, fast retransmission and fast recovery
- Flow control: speed matching between point and point/sender and receiver, because the receiver's application read speed is not necessarily very fast, and the buffer is limited, so it is necessary to avoid sending too fast; related technology: TCP Sliding window, back to N-pin protocol