Graphic TCP-IP protocols

Graphic TCP-IP protocols

In this paper, two diagrams are used to sort out the knowledge of TCP-IP protocol. The TCP communication process consists of three steps: establishing a TCP connection channel, transmitting data, and disconnecting a TCP connection channel. 1 shows the TCP communication process.

 

Figure 1 TCP three-way handshake

 

Figure 1 consists of three parts: establishing a connection, transmitting data, and disconnecting.

 

1) it is easy to establish a TCP connection. You can establish a connection through three handshakes.

 

2) After the connection is established, data transmission starts. TCP data transmission involves many concepts: timeout retransmission, fast retransmission, traffic control, and congestion control.

 

3) The process of disconnecting is also very simple. The process of disconnecting is completed through four handshakes.

 

Three-way handshake to establish a connection:

 

First handshake:The client sends the SYN Packet (SEQ = x) to the server and enters the syn_send status. wait for confirmation from the server;

 

The second handshake:When the server receives the SYN packet, it must confirm the customer's Syn (ACK = x + 1) and send a SYN Packet (SEQ = Y), that is, the SYN + ACK packet, the server enters the syn_recv status;

 

The third handshake:The client receives the server's SYN + ACK packet and sends the ACK (ACK = Y + 1) Confirmation packet to the server. After the packet is sent, the client and server enter the established status and complete three handshakes.

 

The package transmitted during the handshake does not contain data. After the three-way handshake is completed, the client and the server formally start to transmit data. Ideally, once a TCP connection is established, the TCP connection will remain until either of the two parties closes the connection.

 

Data transmission process:

 

A. Timeout retransmission

 

The timeout retransmission mechanism is used to ensure the reliability of TCP transmission. Each time a data packet is sent, the sent data packet has a seq number. After receiving the data, the receiving end replies to ack for confirmation, indicating that the data of a certain seq number has been received. After sending a seq packet, the sender waits for a period of time. If the corresponding ack reply is not received, the sender considers the packet to be lost and retransmits the packet.

 

B. Fast retransmission

 

The recipient finds that some data packets are lost. An ACK packet is sent to the sender to send the lost packet. If the sender continuously receives an ACK packet with the same label, the fast retransmission of the client is triggered. Compared with timeout retransmission and fast retransmission, it can be found that the sender times out while the sender triggers retransmission. The fast retransmission means that the receiver actively tells the sender that the data has not been received, then trigger the sender retransmission.

 

C. Traffic Control

 

TCP Sliding Window traffic control. There is a field in the TCP Header called Window, also called advertised-window. This field is used by the receiving end to tell the sending end how many buffers can receive data. Therefore, the sender can send data based on the processing capability of the receiver, without causing the receiver to be unable to process the data. Sliding windows can be a mechanism to improve TCP transmission efficiency.

 

D. Congestion Control

 

The sliding window is used for traffic control. Traffic control only focuses on the status of the sender and receiver, rather than the communication of the entire network. Congestion Control is based on the entire network. Consider this scenario: when the network latency increases suddenly at a certain time point, TCP will only respond to this issue by re-transmitting data. However, re-transmission will cause a heavier network burden, as a result, it will lead to a greater delay and more packet loss. Therefore, this situation will go into a vicious circle and be magnified. Imagine if tens of thousands of TCP connections in a network do this, a "network storm" will be formed immediately, and the TCP protocol will drag the entire network. Therefore, TCP introduces a congestion control policy. Congestion policy algorithms include slow start, congestion avoidance, congestion occurrence, and rapid recovery.

 

Disconnect after four handshakes:

 

The first wave:The active closing party sends a fin to disable the data transmission from the active party to the passive closing party, that is, the active closing party tells the passive closing party that I will not send data to you (of course, if the data sent out before the fin package does not receive the corresponding ack confirmation message, the active closing party will still resend the data), but the active closing party can accept the data at this time.

 

Second wave:After the passive shutdown party receives the FIN packet, it sends an ACK to the other party and confirms that the serial number is the received serial number + 1 (same as SYN, one fin occupies one serial number ).

 

The third wave:The passive closing party sends a fin to disable the data transmission from the passive closing party to the active closing party, that is, to inform the active closing party that my data has been sent, no more data will be sent to you.

 

The fourth wave:After the active closing party receives the fin, it sends an ACK to the passive closing party and confirms that the serial number is received by the serial number + 1. At this point, the last four waves are completed.

 

Figure 2 shows the state transition diagram in the TCP communication process. Understanding this diagram is the key to understanding the TCP-IP protocol.

Figure 2 transition of TCP status

 

Detailed explanation of the status chart:

 

1. Closed: Start point. It enters this status when the connection times out or is closed.

 

2. Listen:The status of the server waiting for the connection. The server can enter this status by calling the socket, bind, and listen functions. This is called passive opening of an application (waiting for the client to connect ).

 

3. syn_sent:The client initiates a connection and sends SYN to the server. If the server cannot be connected, it directly enters the closed state.

 

4. syn_rcvd:Corresponding to 3, the server accepts the SYN request from the client, and the server enters the syn_rcvd state from the listen state. At the same time, the server must respond to an ACK and send a SYN to the client. In another case, the client receives the SYN request from the server while initiating the syn, the client will be changed from syn_sent to syn_rcvd.

 

5. Established:After three handshakes are performed between the server and the client, data transmission can be started.

 

The above describes the status transfer between the server and the client when the connection is established. It is relatively simple and clear. If you are familiar with the three-way handshake, it is easy to understand the status transfer during connection establishment.

 

Next, let's take a look at the status transfer description when the connection is closed. to close the connection, we need to perform interaction between the two parties four times. We also need to handle some aftermath (time_wait Status). Note, here, either the active or passive closing side does not refer to the server or client, but is relative to who initiates the closing request first:

 

6. fin_wait_1:The active closing party enters the status 5. The specific action is to send fin to the other party.

 

7. fin_wait_2:The party that proactively closes, receives the FIN-ACK of the other party (that is, the response packet of the fin package), enters this state.

 

8. close_wait: After receiving fin, the passively closed party enters this status. The specific action is to receive fin and send ACK at the same time. (Close_wait can be understood as a passive closing party waiting for the upper-layer application to issue a closing connection command)

 

9. last_ack:The party that closes the service passively initiates a request to close the service. The request enters the status 8. The specific action is to send the fin to the other party and the closed status is entered when the Ack is received.

 

10. Closing:When both sides initiate a close request, fin_wait_1 enters this status. The specific action is to receive a fin request and respond to an ACK at the same time.

 

11. time_wait:The most tangled state is coming. From the status chart, we can see that three States can be converted into one. Let's analyze them one by one:

 

A. fin_wait_2 enters this status:When both Parties initiate fin at the same time, the party that voluntarily closes the request enters the state after receiving the fin from the passive closing party.

 

B. switch from the closing status:Both Parties initiate both the shutdown and send fin requests. when both parties receive the fin and ACK, the closing status changes.

 

C. The fin_wait_1 status changes:At the same time, we accept fin (initiated by the other party) and ACK (the fin response initiated by itself). The difference with B is that the ACK in the fin response initiated by itself arrives before the fin request of the other party, B is fin first. In this case, the probability is the least.

 

The most difficult to understand the four closed connections is time_wait. There are two reasons for time_wait:

 

1. Reliable termination of TCP full-duplex connections.

 

2. Allow the old duplicate segments to disappear in the network.

 

Appendix:

 

Slow Hot Start algorithm-slow start

 

First, let's take a look at TCP's slow hot start. The slow start means that the connection just added to the network is accelerated at. Don't overhead the road just like the privileged cars. It is still time for new students to go to High Speed. do not disrupt the order at high speed.

 

The slow start algorithm is as follows (cwnd stands for congestion window ):

 

1) initialize cwnd = 1 at the beginning of the connection, which indicates that an MSS data can be uploaded.

 

2) When an ACK is received, the cwnd ++; is linearly increased.

 

3) every time an RTT is passed, cwnd = cwnd * 2; exponentially increasing

 

4) there is also an ssthresh (slow start threshold), which is an upper limit. When cwnd> = ssthresh, it will enter the "congestion avoidance algorithm" (This algorithm will be described later)

Therefore, we can see that if the network speed is fast, Ack will return fast and RTT will also be short, so the slow start will not be slow at all.

 

Congestion Avoidance

 

As mentioned above, there is also an ssthresh (slow start threshold), which is an upper limit. When cwnd> = ssthresh, it will enter the "congestion avoidance algorithm ". Generally, the value of ssthresh is 65535 in bytes. When cwnd reaches this value, the algorithm is as follows:

 

1) When an ACK is received, cwnd = cwnd + 1/cwnd

 

2) For every RTT passed, cwnd = cwnd + 1

 

In this way, you can avoid network congestion caused by rapid growth, and gradually increase and adjust to the optimal value of the network. Obviously, it is a linear ascending algorithm.

 

Algorithm for congested state

 

As we mentioned earlier, when packet loss occurs, there are two situations:

 

1) When RTO times out, data packets are retransmitted. TCP thinks this situation is too bad and the response is very strong.

 

● Sshthresh = cwnd/2

● Reset cwnd to 1

● Enter the slow start Process

 

2) The Fast retransmit algorithm enables retransmission when three duplicate ACK packets are received, instead of waiting until RTO times out.

 

● TCP Tahoe implementation is the same as RTO timeout.

● TCP Reno implementation:

● Cwnd = cwnd/2

● Sshthresh = cwnd

● Enter the quick recovery algorithm-fast recovery

 

As we can see above, after RTO times out, sshthresh will become half of cwnd, which means that if the packet loss occurs during cwnd <= sshthresh, the TCP sshthresh will be halved, then when cwnd quickly climbs to this place with an exponential increase, it will gradually increase linearly. We can see how TCP quickly and carefully finds the balance between website traffic through this strong shock.

 

Fast recovery algorithm-fast recovery

 

TCP Reno

 

This algorithm is defined in rfc5681. Fast retransmission and fast recovery algorithms are generally used at the same time. The quick recovery algorithm assumes that three duplicated acks indicate that the network is not so bad, so there is no need to be as strong as RTO timeout. Note: As mentioned earlier, cwnd and sshthresh have been updated before fast recovery:

 

● Cwnd = cwnd/2

● Sshthresh = cwnd

 

Then, the real fast recovery algorithm is as follows:

 

● Cwnd = sshthresh + 3 * MSS (3 indicates that three packets have been received)

● Re-transmit the data packet specified by duplicated acks

 

● If duplicated acks is received, cwnd = cwnd + 1

● If you receive a new ACK, cwnd = sshthresh and then enter the congestion avoidance algorithm.

 

If you think carefully about the above algorithm, you will know that the above algorithm also has a problem, that is, it depends on three repeated ACKs. Note that three duplicate acks do not mean that only one packet is lost, but many packets are probably lost. However, this algorithm only retransmits one packet, and the rest of the packets can only wait until RTO times out, so it enters the nightmare mode-a timeout window is halved, if multiple timeouts occur, the transmission speed over TCP decreases, and the fast recovery algorithm is not triggered.

 

TCP New Reno

 

Therefore, in 1995, the TCP New Reno (see RFC 6582) algorithm was proposed to improve the fast recovery algorithm without the support of sack --

 

● When the sender receives three duplicated acks, it enters the fast retransimit mode and develops the package with repeated ACKs. If only one packet is lost, the ACK returned after the packet is re-transmitted will return the whole data that has been transmitted by the sender. If not, multiple packages are lost. We call this ack partial ack.

● Once the sender finds a partial ACK, the sender can infer that multiple packages are lost, so that the first package without ACK in the sliding window is retransmitted. The process of fast recovery was not completed until the partial ack was no longer received.

 

We can see that this "Fast remit "is a very radical gameplay, and it extends the fast retransmit and fast recovery processes at the same time.

 

From: kuai.com

Link: http://www.cricode.com/3568.html

Graphic TCP-IP protocols