Shulou(Shulou.com)06/01 Report--

This article summarizes the process of solving the TCP retransmission problems encountered in my work, focusing on the general ideas and specific practice of solving the problem. There is little theoretical knowledge. If you are interested, you can consult more relevant articles in order to deeply understand the working mechanism of tcp. About TCP retransmission

It is a normal mechanism for TCP to have retransmission in order to ensure the reliability of data transmission. Only in the local area network environment, the network quality is guaranteed, because the retransmission of network problems should be very low; in the Internet or metropolitan area network environment, the lines are complex (you can imagine the urban underground pipe network, intricate telephone poles, etc.), the network quality is not guaranteed, and the probability of retransmission is high.

The retransmission of TCP is not necessarily a problem at the network level. It may also be that the receiver does not exist, the receive buffer of the receiver is full, the application has abnormal links that do not close properly, and so on.

TCP/IP correlation

Troubleshooting network problems, to master the principle of TCP/IP, the truth is in a packet. Here are a few key parameters compared with TCP retransmission.

Parameters when establishing a TCP link

TCP retransmission type

Timeout retransmission

When the request packet is sent, a timer is started. When the timer expires and no ACK is received, the request will be resent until the upper limit number of retransmissions is reached or the ACK is received.

Fast retransmission

When the packet received by the receiver is an abnormal sequence number, the receiver will repeatedly send the ACK that should be received. At this time, if the sender receives three consecutive ACK of the same sequence number, then the fast retransmission mechanism will be initiated to send the corresponding ACK packet again. For details, please refer to:

Common problems and measures tcp retransmission on a single machine or a single application machine

It may be that the linked server or port is inaccessible

Simultaneous tcp retransmission of multiple machines or applications

It could be network jitter.

Check the network area burial point, check the network equipment alarm, see if there is a local area network jitter 2 local area network is not a problem. You can narrow the scope of troubleshooting by FAQ:

The bandwidth is full

1. View the monitoring of the host

Uncommon question

1 abnormal network device port or optical module leads to packet checksum failure 2 network route convergence jitter 3 host network drivers have bug, network devices have bug, etc.

How to monitor

Use tsar-tcp-C to monitor the retran attribute of tcp, that is, the number of retransmissions.

Tsar-- tcp-C | sed's xargs-n 2

Interested friends can directly execute the following monitoring script to obtain tcp-related status monitoring data, which is suitable for open-falcon.

Case practice

(1) grab the packet on the machine that encounters lost packet retransmission and use wireshark to analyze the packet. Note that since retransmission is not always available, the packet capture command should be executed continuously in order to capture the retransmitted packet. Use wireshark to open the results of tcpdump, and start tcp.analysis.retransmission in the search box to get the following results:

Figure 1 shows that three retransmissions have occurred on the server side.

(2) due to the large number of packets, we can use the tracking stream feature of wireshark to obtain the tcp stream related to retransmission.

Figure 2 tracking flow-- > TCP flow can get packets related to retransmission

Figure 3 shows the requests and responses of the client and the server.

(3) Analytical retransmission

In particular, it is important to note that:

NO 67 client 68 does not receive the correct packet data for some reason. Send dup ack to server, referring to the fast retransmission mentioned in the basic knowledge.

The time difference between NO.68 and NO.69 200ms (pay attention to the time column, the other differences are less than 1ms), server waits for a timeout, so it is retransmitted.

NO 73-74 is the client that sends a fin packet and actively closes the connection.

This case occurred only once, did not reappear, through the analysis of the package analysis did not get a clear conclusion.

Summary

This paper summarizes the process of solving the problem of TCP retransmission encountered in my work, focusing on the general ideas and specific practice of solving the problem. There is little theoretical knowledge. If you are interested, you can consult more relevant articles in order to deeply understand the working mechanism of tcp.

The original text is from: https://www.linuxprobe.com/tcp-retransmission.html

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.