The Art of Wireshark Analysis

1. Wireshark practical operation

Operational analysis of the interface

One of the three tricks: View statistics and attribute information

One of the three key points of performance analysis:

[Statistics -> Capture File Properties] Statistics -> Summary, view file attribute information, such as average speed, packet size, number of packets, etc.

Determine traffic peaks and whether it is overloaded

[Image upload failed…(image-7200fa-1541746330755)]

The second of the three tricks: View the information of the analysis expert

Performance analysis three axes two:

[Analyze -> Expert Information] Wireshark ->Analyze -> Expert Infos -> Notes, view the statistics of the captured packets

Check whether there are any notes, warnings, errors, etc., to see if there are any related warnings and errors, to judge the network quality, retransmission disorder, etc.

[Image upload failed…(image-1e2d8b-1541746330755)]

Tip 3: Check service response time

Performance analysis three axes three:

[Statistics -> Service Response Time] statistics -> Service Response Time -> xxxxx (e.g. ONC-RPC -> Program:NFS)

Check the service response time of each operation to determine whether it is overloaded

Use relative values ​​to replace the actual values ​​in seq

Edit->Preferences->Protocols-> TCP , check Relative Sequence Numbers

Before it is enabled, it is a relative value.

View TCP StreamGraph

Statistics -> TCP StreamGraph -> TCP Sequence Graph (Stevens)

Check the data transmission status, such as whether the transmission is uniform and whether there are TCP Zero Windows .

Field meaning & prompt information

The meaning of the field is some prompt information of Wireshark, that is, some info information of the packet captured by Wireshark. These prompt information are reflected in the Info column.

1.[Packer size limited during caputre]

If a packet is marked [Packer size limited during caputre], it means that the packet is not fully captured. You can further check the frame information below. Generally, this is because the packet capture method is incorrect. In some operating systems, tcpdump only captures the first 96 bytes of each frame by default. Therefore, when tcpdump captures packets, you can specify the number of bytes to capture through the -s parameter.

2. [TCP ACKed unseen segment]

If Wireshark finds that the packet that was Acked was not captured, it will prompt [TCP ACKed unseen segment], but this prompt can be ignored in most cases. Because in most cases, when you first capture packets, you only capture the Ack at the end but not the ACK at the beginning.

3.[TCP Previous segment not captured]

In TCP data transmission, except for the three-way handshake and the four-way handshake, the data segments sent by the same machine should be continuous, that is, the Seq of the next packet is equal to the Seq+Len of the previous packet, which should be the case correctly; if it is found that the Seq of the next packet is greater than the Seq+Len of the previous packet, it means that a piece of data is lost in the middle. If the lost data cannot be found in the entire network packet, Wireshark will prompt [TCP Previous segment not captured],

There are two possibilities for this situation:

• The data packet is really lost.
• The data packets were not lost, but the packet capture tool missed them.
  • If you confirm that the Ack packet contains the packet that was not captured, then the packet capture tool missed it. Otherwise, it is really lost.

4. [TCP Out-of-Order]

In TCP data transmission, except for the three-way handshake and four-way handshake, the data segments sent by the same machine should be continuous, that is, the Seq of the next packet is equal to the Seq+Len of the previous packet, which should be the case correctly; or the Seq of the next packet should be greater than or equal to the Seq+Len of the previous packet. If Wireshark finds that the Seq of the next packet is less than the Seq+Len of the previous packet, it is considered to be out of order and a prompt will be given [TCP Out-of-Order].

Generally speaking, a small-span disorder has little impact, but a large-span disorder will lead to fast retransmission. For example, if the order of a packet is 1, 2, 3, 4, 5 and it is disrupted to 2, 1, 3, 4, 5, it is a small-span disorder and has little impact; if it is disrupted to 2, 3, 4, 5, 1, it will trigger enough Dup ACKs, resulting in the retransmission of packet 1.

5, [TCP Dup ACK]

When out-of-order or packet loss occurs, the receiver will receive some packets with Seq numbers larger than the expected value. The TCP protocol will ACK the expected Seq value every time it receives such a packet, and inform the sender in this way, so some duplicate Acks are generated. Wireshark will prompt when it captures these duplicate Acks [TCP Dup ACK].

6. [TCP Fast Retransmission]

When the sender receives 3 or more packets in a row [TCP Dup ACK], it realizes that the previously sent packets may be lost, so it will start fast retransmission according to the RFC regulations. [TCP Dup ACK]It is the receiver’s response to the sender, so the sender can sense it and start fast retransmission when it receives more than 3 packets in a row.

The fast retransmission algorithm stipulates that as long as the sender receives three duplicate confirmations in a row, it should immediately retransmit the message segment that the other party has not received, without having to continue waiting for the set retransmission counter to expire.

7. [TCP Retransmission]

If a packet is really lost and there is no subsequent packet to trigger [Dup Ack] on the receiving end, then fast retransmission will not be enabled. In this case, the sender can only wait until the timeout and then retransmit. The timed-out retransmission packet will be marked by Wireshark and prompted[TCP Retransmission]

TCP timeout and retransmission should be one of the most complicated parts of TCP. Timeout retransmission is the basis for TCP to ensure reliable transmission. When TCP sends data, both data and ack may be lost. Therefore, TCP solves this problem by setting a timer when sending. If the timer overflows and no confirmation is received, it retransmits the data. The key lies in the timeout and retransmission strategy, which needs to consider two aspects:

• Timeout setting
• Retransmission frequency (number of times)

In higher Linux kernel versions, such as 3.15, there are at least 9 timers: timeout retransmission timer, persistence timer, ER delay timer, PTO timer, ACK delay timer, SYNACK timer, keep-alive timer, FIN_WAIT2 timer, TIME_WAIT timer.

8, [TCP zerowindow]

The “win=xxx” in the TCP packet represents the size of the receive window, which indicates how much buffer the sender of this packet currently has available to receive data. When Wireshark issues a packet with “win=0”, it will mark the prompt [TCP zerowindow], indicating that the buffer is full and can no longer receive data.

Generally, the window size should be gradually reduced before the buffer is full.

9, [TCP window Full]

If the sender of a packet has exhausted the receiving window size declared by the other party, it will be marked by Wireshark [TCP window Full]. For example, when one end declares that its receiving window is only 65535 during the handshake, it means that the other end can only send it 65535 bytes of data at most without confirmation, that is, the “number of bytes in transit” can only be 65535 at most. When Wireshark calculates that the other end has 65535 bytes that have not been confirmed, this prompt will appear.

[TCP window full] is easily confused with [TCP zerowindow] above. The former means that the sender of this packet cannot send data anymore; the latter means that the sender of this packet cannot receive data anymore. Both of them mean that data transmission needs to be suspended.

10. [TCP segment of reassembled PDU]

Allow sub dissector to reassemble TCP streamsThis prompt is only available if Edit->Preferences->Protocols->TCP is enabled . This means that TCP packets belonging to the same application layer PDU can be virtually grouped together.

11, [Continuation to #]

You will only receive this prompt after turning it off in the Edit->Preferences->Protocols->TCP menu Allow sub dissector to reassemble TCP streams.

12. [Time-to-live-exceeded(Fragment reassembly time execeeded)]

(Fragment reasembly time execeeded) means that the sender of this packet has received some fragments before, but for some reason it has been unable to reassemble them.

For example, if some fragments are lost during transmission, the receiver cannot reassemble them and then informs the sender through ICMP .

ICMP is the Internet Control Message Protocol. It is a sub-protocol of the TCP/IP protocol family, used to transmit control messages between IP hosts and routers . Control messages refer to network messages such as whether the network is connected, whether the host is reachable, and whether the route is available. Although these control messages do not transmit user data, they play an important role in the transmission of user data.

2. Wireshark analyzes TCP protocol

TCP packet capture protocol basics

TCP Control Field

At the TCP layer, there is a FLAGS field, which has the following flags: SYN, FIN, ACK, PSH, RST, URG.

The control field displayed in the captured packet is as follows:

[SYN]: Establish connection, initiate packet [FIN]: Close connection, end packet [PSH]: DATA data transmission [ACK]: ACK response [RST]: RESET, connection reset

Two other commonly used fields:

[Len]: Packet length [Seq]: Packet sequence number

ACK can be used together with SYN, FIN, etc. For example, SYN and ACK may be 1 at the same time, which indicates the response after the connection is established. If it is only a single SYN, it only indicates the establishment of a connection.

When a FIN packet or RST packet appears, we believe that the client and the server are disconnected. When a SYN and SYN+ACK packet appears, we believe that the client and the server have established a connection.

Packet capture direction (client or server)

• When capturing packets, whether through wireshark or tcpdump, you need to check whether you are capturing packets from the client or the server. The packet capture situations are completely different in different directions because there are many abnormal situations on the network (public network, actual environment).

TCP Ack

For HTTP, it is usually request->response, one question and one answer. But for TCP, not every packet will be ACKed. TCP’s ACK is a cumulative ACK, which means that all other ACKs before my ACK have been confirmed to have been received.

For example, if the ACK of packet 97 is 65701 and the Seq+Len of packet 96 is 64273+1428=65701, then the ACK of packet 97 is a response to packet 96. That is, the other packets before packet 96 that have not been ACKed have actually been ACKed by packet 97. In this way, the sender knows that all the packets sent before packet 96 have been received and ACKed by the other party.

MSL, TTL, RTT

• MSL (Maximum Segment Lifetime) stands for “maximum segment lifetime”, which is the longest time that all messages exist on the network. If the time exceeds this, the message will be discarded.
  • RFC 793 stipulates that the MSL is 2 minutes, but in actual applications, 30 seconds, 1 minute, and 2 minutes are commonly used.
  • 2MSL means twice the MSL. The TCP TIME_WAIT state is also called the 2MSL waiting state.
• TTL (Time to live) stands for survival time. It is a field in the IP header. The survival time is set by the source host to an initial value, but TTL is not a specific storage time, but indicates the maximum number of routes that can pass through.
  • According to RFC 1812, every time the TTL of a network packet is reduced by 1, it means that it has passed through a route. Generally, the initial value of TTL is 64. If the TTL of an ACK packet is 62, it means that it was sent from a device two hops away from this device.
  • The form of TTL in the wireshark packet capture is as followsTime to live: 62
  • If TTL=0, the datagram will be discarded and an ICMP message will be sent to notify the source host.
  • TTL is generally also used in cache and connection heartbeat. It is different from TTL in TCP protocol. TTL in cache and connection heartbeat indicates the remaining time of data cache or connection.
• RTT (round-trip time) refers to the time it takes for a client to go back and forth to the server. TCP contains an algorithm for dynamically estimating RTT.
  • TCP continuously estimates the RTT for a given connection because the RTT varies with changes in network congestion.

MAC address resolution

Protocol = ARP Source and Destination are both MAC address formats such as 00:60:48:ff:12:31

During packet capture analysis, if the network is not connected, ACK is not received after sending, etc., you need to further check whether the MAC address of each packet is correct. Otherwise, there are some problems caused by multiple MAC addresses.

TCP handshake and wave protocol

TCP three-way handshake & packet return judgment

• Three-way handshake protocol
  • client->server: [SYN] Seq=X win=xxx Len=0 MSS=xxx
  • server->client: [SYN, ACK] Seq=Y，ACK=X+1 win=xxx Len=0 MSS=xxx
  • client->server: [ACK] Seq=X+1，Ack=Y+1 win=xxx Len=0
• When capturing packet data, how do you determine whether a packet is a reply packet of the previous packet? According to the TCP protocol, if the value of the Ack of the next packet is equal to the Seq + Len of the previous packet, it means that it is a reply packet.
  • In many cases, the previous and next packets are not continuous. It is also possible that the next packet is many packets away from the previous packet because of retransmission and delay.
• During the three-way handshake, each party will declare their respective MSS

TCP four-wave handshake & three-wave handshake

• TCP Four-Wave Protocol
  • client->server: FIN Seq=X, ACK=Y
  • server->client: Seq=Y，ACK=X+1
  • server->client: FIN Seq=Y，ACK=X+1
  • client->server: Seq=X+1，Ack=Y+1
• Normally, there will be four waves like this, but if there is a delayed confirmation, then the four waves will become three waves, saving the second packet in the four waves.
  • client->server: FIN Seq=X, ACK=Y
  • server->client: FIN Seq=Y，ACK=X+1
  • client->server: Seq=X+1，Ack=Y+1

TCP Congestion Control Algorithm

Bytes in Transit

• The number of bytes in flight refers to the number of bytes that have been sent but not yet confirmed. This confirmation refers to the ACK confirmation sent by the other end, which is the so-called network carrying capacity. If the number of bytes in flight exceeds the network carrying capacity, packet loss and retransmission will occur.
  • This “current” can be seen only from the network packet sequence number on the captured packet. There is no need for the two packets to have any relationship. It is precisely because the two packets have no relationship that the number of bytes in transit is calculated.
  • Generally speaking, this Len should not exceed the MSS ( Maximum Data Size) of TCP, which is 1388. Note that it is comparable to MTU (1500).
  • Number of bytes in transit = [Seq + Len] of the current sender – [ACK] of the current receiver

Network congestion

• Network congestion point: Network congestion caused by exceeding the network capacity. The number of bytes in transit when congestion occurs is the network congestion point at that moment. To estimate the network congestion point, you only need to find the number of bytes in transit when congestion occurs.
  • From the sender’s perspective, it is equivalent to standing at the CPU’s perspective, so the packet capture should see the package before segmentation. From the receiver’s perspective, it is equivalent to standing at the network card’s perspective, so what you see should be multiple small packets after segmentation.
  • The significance of LSO is that the current network cards are often 1000M or 1000M, which puts a heavy burden on the CPU. For example, 625MB/s of network traffic requires about 5GHz of CPU. Therefore, in order to relieve the burden on the CPU, some segmented work is directly handed over to the network card for execution.
  • The minimum value is taken because it is the most conservative, so as to truly ensure that the network will not be congested; after taking it, you need to set the Linux send window
  • If Seq+Len-Ack = 103122, the unit is bytes, which is 100KB. This 100KB is the maximum send window, so you need to set the send window value in the Linux system.
  • The characteristic of congestion is a series of packet losses followed by retransmissions. Packet capture tools such as wireshark and tcpdump can identify retransmissions.
  • According to the packet capture tool, find the first packet in a series of retransmitted packets, then find the corresponding original packet according to the Seq value of the retransmitted packet, and finally calculate the number of bytes in transit when the original packet is sent, which identifies the current congestion point.
  • Wireshark ->Analyze -> Expert Info -> Notes menu can see the traditional count
  • The number of bytes in transit is only an estimate of the network congestion point, which is not necessarily very accurate. You can sample it multiple times and then find a suitable value. After multiple samplings, the minimum value should be taken instead of the average value if it is conservative.
  • As mentioned above, the maximum Len of a data packet should not exceed 1388. However, during the actual packet capture and analysis, it is found that the actual Len may be twice or N times of 1338. What is the reason for this? This is because of a so-called LSO.
  • The general network working mode is: the application layer sends the generated data to the TCP layer, TCP then segments it according to the MSS size, the CPU is responsible for segmentation, and finally sends it to the network card.
  • If LSO is enabled: the TCP layer directly hands over data blocks larger than the MSS to the network card, which is responsible for segmentation.

Some practical experience tells us that Wireshark ->Analyze -> Expert Info -> Notesif the statistical retransmission rate exceeds 0.1%, some measures need to be taken. However, in the real network environment, it is basically impossible to have a retransmission rate lower than 0.01%.

Send Window

• The client’s send window is determined by two factors: the congestion window (cwnd) on the network and the receive window on the server.
  • If it is the “slow start” phase, the cwnd of the next RTT packet should be much larger than the cwnd of the previous packet.
  • If it is the “congestion avoidance” phase, the cwnd of the next RTT packet should increase by one MSS (the MSS in Ethernet is about 1460 bytes).
  • If the above two conditions are not met, for example, cwnd grows very slowly, then it is necessary to analyze it according to the calculation method of cwnd.
  • The growth pattern of cwnd is: first “slow start” and then enter “congestion avoidance”. The former has a low starting point but can grow rapidly, while the latter has a high starting point but can only increase one MSS per RTT (RTT refers to the round-trip time , that is, the time until the next packet transmitted in the same direction)
  • According to the captured data, click on the details and check its “Bytes in flight” value, which can be simply equated with cwnd

TCP Nagle Algorithm and Delayed ACK

1. Nagle’s algorithm:
   • It is to reduce the number of small packets in the WAN, thereby reducing the occurrence of network congestion;
   • The algorithm requires that there can be at most one unconfirmed, incomplete small packet on a TCP connection. No other small packets can be sent before the ACK of this packet arrives. TCP needs to collect these small packets and send them out as one packet when the ACK arrives. The definition of a small packet is any packet smaller than the MSS.
   • The advantage of this algorithm is that it is adaptive. The faster the confirmation arrives, the faster the data is sent. On a low-speed wide area network where the number of tiny packets is expected to be reduced, fewer packets will be sent.

Code language: javascript

copy

       if there is new data to send
      if the window size >= MSS and available data is >= MSS
        send complete MSS segment now
      else
        if there is unconfirmed data still in the pipe
          enqueue data in the buffer until an acknowledge is received
        else
          send data immediately
        end if
      end if
    end if

1. Delayed ACK:

If TCP sends an ACK confirmation for each data packet, it is expensive to send an ACK for a single data packet, so TCP will delay for a period of time. If there is data sent to the other end during this period, the ACK will be sent along with it. If the ACK is not sent when the delayed ACK timer is triggered, it will be sent separately immediately.

Delayed ACK benefits:

(1) Avoid the silly window syndrome; (2) Send the ACK along with the data, instead of sending it separately; (3) If multiple data segments arrive within the delay time, then allow the protocol stack to send one ACK to confirm multiple segments;

1. When Nagle encounters delayed ACK:

Consider the following typical operation: write-write-read, which is an operation of sending a single logic to the peer end through multiple small pieces of write data. The length of the two write data is less than the MSS. When the first write data reaches the peer end, the peer end delays ack and does not send ack. Since the length of the data to be sent by the local end is less than the MSS, the Nagle algorithm takes effect. The data is not sent immediately, but waits for the confirmation ack of the first data sent by the peer end. In this case, it is necessary to wait for the peer end to time out and send ack before the local end can send the second write data, which causes delay.

1. Turn off Nagle’s algorithm:

Use the TCP socket option TCP_NODELAY to turn off the socket option;

Consider disabling the Nagle algorithm in the following scenarios:

(1) The peer does not send data to this end, and the operation is sensitive to latency. This operation cannot carry an ack. (2) Write-write-read operation as above. For this case, other methods are preferred instead of disabling the Nagle algorithm:

Differences and comparisons between TCP and UDP

Main Differences

The difference between TCP and UDP is that TCP is reliable and UDP is unreliable, but in practice, what is reliable? What is unreliable? What are the differences in ACKs of specific protocols?

Both TCP and UDP may be fragmented, which is determined by the MSS of Ethernet. The difference lies in the processing of fragmented transmission:

• For UDP, if the fragment transmission causes some fragments to be lost, the receiver cannot complete the reassembly, so the sender will retransmit all fragments. If retransmission occurs, the efficiency will be relatively low.
  • This is why UDP is unreliable. There is no mechanism to ensure that data is delivered safely, and the application layer needs to be responsible for retransmission.
• As for TCP, the segmentation mechanism of TCP can break the data packet into smaller pieces and encapsulate them in multiple packets, thus avoiding fragmentation at the network layer. As for retransmission, TCP only needs to retransmit the lost packet instead of the entire packet.
  • TCP is reliable because it has a mechanism to ensure that data is delivered safely without requiring the application layer to handle retransmissions.
  • Because TCP only retransmits a lost packet instead of the entire packet, its retransmission efficiency is much higher than UDP.

UDP is better for voice than TCP

In the scenario of voice calls, delays are unacceptable, but slightly lower sound quality is acceptable. In this case, when UDP is transmitted, if some packets are lost, the application layer can choose to ignore them and continue to transmit other packets. Losing some packets will only affect the sound quality, but the smoothness is guaranteed. For TCP, each packet will be retransmitted as long as a packet is lost, which will cause a certain delay. If there is a delay in voice, it is not desirable.

Therefore, TCP and UDP each have their own suitable scenarios. UDP is more suitable for voice and video. Agora and Linphone all use UDP to process audio and video. TCP must be used in basic and core protocol interactions.

Efficiency issues between TCP and UDP

TCP needs round-trip time to confirm, that is, ACK, during the transmission process, while UDP does not need confirmation. So is UDP more efficient than TCP? This is not necessarily the case. Although UDP can send packets continuously without waiting for ACK, TCP has a send window. If the send window is small and does not occupy the full bandwidth, it will definitely be constrained by the round-trip time, making the efficiency slightly lower. However, as long as the window is large enough and appropriate, and the bandwidth is fully utilized, TCP can also transmit data continuously without being constrained by the round-trip time.

For example, if there is only one car on the road, it will run back and forth to pick up goods, and the return trip is equivalent to an empty trip (the return trip is equivalent to TCP ACK), so the TCP efficiency is of course low. However, if there is no congestion, the number of vehicles can be increased as much as possible, so that the road is just full of cars, the overall transmission efficiency is improved, and the return ACK is not affected.

Packet fragmentation, MTU, MSS

Packet fragmentation and reassembly

Packet switching divides large data into small packets, so that link sharing can be achieved without blocking all of them because of one party. Since it is to be divided into small packets, a maximum packet size must be determined, which is the MTU (Maximum Transmission Unit), and the value is 1500 bytes. If the 20-byte header structure is removed, the maximum packet size of an IP packet is 1500-20=1480 bytes. If the data block to be transmitted exceeds 1480 bytes, the network layer will fragment it and encapsulate it into multiple network packets for transmission. For TCP, the TCP protocol layer will actively divide the data into small segments and then hand it over to the network layer. The maximum segment size of TCP is called MSS (Maximum Segment Size). This MSS is set to the size of MTU minus the IP header and TCP header, which just meets one MTU. Because UDP does not have the concept of MSS, it can only be handed over to the network layer to handle fragmentation.

However, it should be noted that some networks currently use Jumbo Frame or PPPOE devices, so their MTU is not 1500 bytes. Currently, the sender does not have a good mechanism to determine the optimal fragment size, and should try to keep the MTU of devices in the network consistent. If the MTU of devices in the network is inconsistent, how does the TCP protocol adapt to the MTU? We know that when TCP establishes a connection, a three-way handshake must be performed first. TCP will declare its MSS to each other in the first two handshake packets. If the client declares its MSS=8960 (jumbo frame) and the server declares its MSS=1460, then the client will know the MSS of the server after the three-way handshake. Therefore, when the client wants to send a packet larger than the server’s MSS, it will actively reduce its MSS to the size of the server’s MSS, thereby adapting to the receiver’s MTU. It can be seen that the TCP protocol layer has done a lot of optimization and processing.

Since there are fragments, the receiver must reassemble the fragments. Through the packet capture tool, we can know that each packet of the fragment contains off=xxx，ID=xxxsuch information. The receiver will reassemble the fragments with the same ID according to the off offset. So how does the receiver know which packet is the last fragment? And when does the reassembly begin? The last fragment packet has a special Flag called, More fragment = 0which is expressed in the packet capture as ..0. ... = More fragment: Not set, which means that it is the last fragment, and then the packet can be reassembled. If it is other fragment packets, the form is as follows, which ..1. ... = More fragment: setmeans that the receiver needs to cache and wait for the transmission of other fragments to be completed.

MTU in action

If the MTU of the client is 9000 and the MTU of the server is 1500, then when the client requests the server, the client’s packet will be either lost or fragmented when passing through the router. If the jumbo frame carries the DF (Don’t fragment) flag at the network layer, it will be discarded (if it is set, fragmentation is not allowed). If it is not set, it will be transmitted in fragments. It should be noted that in this case, if the packet is lost, it will still be discarded after retransmission, and it will become a black hole.

During testing, you can use the ping command to simulate this situation:

Code language: javascript

copy

成功：
ping xxx.xxx.xxx.xxx -l 1472 -f -n 1

失败：
ping xxx.xxx.xxx.xxx -l 1473 -f -n 1

The -f parameter indicates setting the DF flag. The -l parameter indicates requesting bytes.

When the request byte is set to 1472, because the ICMP header is 8 bytes and the IP header is 20 bytes, 1472+8+20=1500, which is exactly one MTU, so the ping can succeed. However, the second 1473+8+20=1501 bytes exceeds the MTU, and because the DF flag is set to indicate that fragmentation is not allowed, the transmission fails. Generally, in this case, the router will reply Packet needs to be fragmented but DF set.

When capturing packets, if you find that they are always retransmitted and only certain relatively large packets (check the Len value) are retransmitted, you can ping xxx.xxx.xxx.xxx -l [Len] -ftest and verify it through the value. By finding the pattern through the size change of [Len] specified by ping, you may find that the MTU of a certain device on the network is not 1500, which leads to the phenomenon of retransmission when it exceeds this value.

Special flow control and bandwidth

There must be switches, routers and other devices between the client and server. If the server is a 10G network card and the client is a 1G network card, it is possible that the server sends data too fast, causing data to be blocked on the switch, and then packet loss occurs after the switch is full. However, generally speaking, the bandwidth of the server should be greater than that of the client. In order to avoid congestion, a flow control mechanism is needed to allow the switch to tell the server to slow down or suspend transmission when it is overloaded.

There is a “pause frame” that can meet such a requirement: when the switch buffer is about to be filled, it sends a pause frame to the server. The server waits for a while before sending again, which can avoid overflow and packet loss, and also avoid retransmission after packet loss. How long the server waits is specified by the pause_time in the pause frame, so that the server will continue to send after waiting for the pause_time. Of course, the switch can also send a pause frame with pause_time=0 to the server, telling the server that it has been digested and can be sent immediately.

Note that this flow control is different from TCP flow control.

3. Wireshark Analysis Methodology

1. To troubleshoot problems with Wireshark, you need to analyze network packets, look for clues in them, and then make inferences based on the network protocol. Then you need to negate them one by one, and finally find the problem.
2. You need to be able to understand the underlying TCP protocol and understand the meaning of each field.
3. Make good use of Wireshark’s statistics and analysis tools; filters, etc.
4. There is a huge difference between sending and receiving packet capture
5. Make good use of the “three-axe” operating procedures and steps to analyze problems