Analysis of TCP repeated ACK and disorderly sequence by Wireshark packet capture case

Reprint please keep the original source in the text: EMC Chinese support forum Https://community.emc.com/go/chinese

Introduction

one of the most common problems with TCP is repetitive ACK and fast retransmission. This behavior is also due to performance issues, and this chapter discusses how to discover the problem and what they mean.

Another common problem is the loss of the previous fragment and the sequence fragment. In some cases, this phenomenon is a sign of a failure, possibly due to a network problem or an interruption in the packet capture.

More Information

Repeat ACK and fast retransmission:

Repeated ACK is one of the possible reasons when the network speed slows down. In most cases, repeated ACK occurrences are due to high ductility, delayed changes, or slow endpoints that cannot respond to ACK requests.

1. When the number of duplicate ACK remains within a reasonable range, that is, 1 or 2 percent, it may not be a native problem.
2. When there is a large number of duplicate ACK (assuming there are ten ), it is possible to:

• Delay changes due to busy communication links
• Server or Client not responding

3. Fast retransmission is a response message to a duplicate ACK .

4. Is an example of this problem. In this example, a fast retransmission occurs after a repeated ACK:

5. Here's how to fix the problem:

• If the number of repeated ACK and retransmission is small (less than 1 percent), it is acceptable.
• If the repeated ACK occurs in a wireless network environment, or a connection over the Internet , the delay or delay changes are common for such networks, so there is nothing to do.
• If there is a network within your organization, there may be a problem. If it happens on top of the LAN, check for serious problems such as cache and CPU load, slow servers, and so on. If it occurs over a WAN , view the delay, load, and line instability.

Working principle

When a missing message is found (the expected serial number is not received), or the expected serial number is received. In this case, the receiving side generates an ACK that declares the next sequence number that it wishes to receive. The receiver continuously generates an ACK request for the missing fragment until it is actually received.

On the sender, when it receives three identical ACK (initial ACK and two duplicate Ack ), it assumes that there is a message loss and retransmission of the message, regardless of whether the retransmission timer expires. The message sent again is called fast retransmission.

Repeated ACK also reduces the throughput that is destined for the network. How much throughput is reduced depends on the TCP version. There was a duplicate ACK in the earlier TCP version , and the sender reduced the throughput to half the previous. In the case of multiple dupack, throughput is minimized.

A typical example of repeated ACK and retransmission is shown, and the first repeat ACK in this figure reduces the throughput to approximately 40%, after which retransmission minimizes throughput.

Disorderly sequence message :

At both ends of the bag, there are three kinds of phenomena that need attention in order of chaos:

• Previous fragment lost : When the serial number of the currently received message is higher than the next expected sequence number of the connection, one or more of the previous messages failed to arrive
• Disorderly Sequence Message : The serial number of the current message is lower than the previously received message from the connection
• previous fragment failed to capture : (Wireshark 1.8.x and above): Lost with previous message.

When does it happen?

The user may see the disorderly sequence message in the following situations:

• grab bag at start of connection : When the connection is caught, the packet is not syn/syn-ack/ack , so Wireshark think the connection is problematic.

• There's really a message missing . : The lost message retransmission and/or duplicate ACK will be seen to tell the sender to retransmit the lost message.

is a typical example of message loss. Visible, 10.0.0.6 tries to browse the site 62.90.90.210 . In this process, each 1420 byte of the TCP fragment is sent to the Web server, 334 to 336 between 3 messages lost, 338 to 340 between 2 messages are lost. Both Wireshark have a hint: the TCP ' s previous segment is not captured.

• Delay Change : This may be due to a different route from the source address to the destination site. Check that you can use Tracert to find routing changes between the source and destination addresses. If you can do this on your company's internal network, for example, configure a trap on the router .

• Data Capture Issues : The message may be sent or received normally, but Wireshark is not captured. There are several possible reasons for this:
  • When the data volume is large, the Wireshark may lose the message (higher than 150-180 Mbps) in the case of high bit rate . To avoid this problem, use other tools (most require a fee).
  • The desktop is not powerful enough for the memory or CPU to make the Wireshark work fast enough. This is very well discovered.
  • When the LAN switch's port cache is too small, the message may be discarded. Connect to the switch (with console or Telnet connection) to check the issue using the switch command line.
  • The wireless network catches the packet for some reason not to see all the sending messages.

Summarize

The principle of random sequence messages is simple. TCP sends a message with its number of bytes to the receiving party. When a message arrives in sequence, Wireshark will notice. There are two reasons:

• There is a problem : you will see a retransmission and a duplicate ACK , which is the response of TCP to the incoming sequence message.
• Grab packet problem : At this time only to see the chaotic sequence of messages, but did not see the possible loss and chaos of the response of the message, may actually not be a problem.

Reference

Network Analysis Using Wireshark Cookbook

Analysis of TCP repeated ACK and disorderly sequence by Wireshark packet capture case