Understand Slow File Download and Wireshark Protocol Gaps

Introduction

Wireshark is a powerful network analysis tool that can help resolve a variety of network-related problems. However, using Wireshark alone is not enough to guarantee a solution for every issue. The complexities of network troubleshooting go beyond just capturing packets. To effectively identify the root cause of a problem, we must address two key challenges related to Protocol Gaps:

1. Protocol Gaps between Network Layers
2. Discrepancies Between Wireshark’s Prompts and Actual Protocol Behavior

You might be wondering, what exactly are these protocol gaps? Why do they exist, and why aren’t they always apparent? Let’s break down these challenges to better understand their impact on network troubleshooting.

Gap 1, network layer and layer

Before explaining the possible gaps between network protocols, we need to answer a question: Why should the network be layered?

The purpose of a computer network is to provide communication between peers.

For example, if redisclient and redis server, mysqlclient and mysqlserver and other similar things want to communicate over the network, if they are not layered, then redisthey mysqlall need to implement a complete set of communication protocols, including but not limited to communication connection methods, routing selection, transmission reliability and efficiency, etc. What’s more terrible is that when you have a new application, you need to start over.

However, for a new service, only the “application layer” protocol needs to be customized. The underlying layer it relies on remains unchanged, and it is just reinventing the wheel.

Therefore, network layering has many benefits. The current practice is that each application implements its own application layer protocol, and the implementation of transport layer and network layer protocols can be handed over to the operating system.

Having discussed the benefits of network layering, let’s now talk about the problems that network layering brings, that is, the “gap” between the network and the layers.

Why do we say there is a gap?

For example, many times when the transport layer reports an error, it does not pass detailed information to the application layer. If we can only look at the application layer at this time, we will not be able to determine the problem .

Case：connection reset by peer

connection reset by peerThis is a nginxcommon error. But as the name suggests, we only know that the connection is disconnected, we don’t know why it is disconnected? Is the server logic processed? (Yes, sometimes it is connection reset by peer, but it does not affect the service)

Looking closely at the data packets in the figure, we can see:

1. 11022Number package, clientsend POSTrequest

2. Send a response 11446to the number packet server, indicating that the processing is completed

3. 11448The number package clientactually sent aRST

At least this time the request was handled perfectly by the server, but it dropped clientimmediately rst.

We need to continue to check clientthe code to determine whether it affects this request. If there is no packet capture, we may conclude that the server directly rejected the request or did not complete the processing of this request.

Gap 2, Wireshark Tips and Protocols

This section talks about the gap between tooltips and protocol understanding.

For example, wiresharkthere is a knowledge barrier between the displayed prompts and the network protocol itself.

Case: ICMP explicit port field

ICMPIt is a network layer protocol. It does not and should not have portthe fields of the upper layer protocol – the transport layer.

But I really found it!

Isn’t it a bit messy? As a network layer protocol, ICMPthe port number is first 80!

In fact, it is not that magical. This is just wiresharka display strategy. We 2can click on the details of the number package.

It turns out that only icmpthe packet payloadcarries 1the contents of the number packet, and then the port number is displayed in the protocol wiresharkwhen it is parsed icmp.

Case: “Four Waves” with only one wave

Let’s first review the process of four waves.

But sometimes, you will catch a hand-waving process with only one FINmessage. For example, the following picture:

No matter how carefully you observe these packets, you will find that FINthe message mark can only be found in packet 7.

Aren’t there supposed to be two FINmessages in the waving phase? Is the network too complicated for us to understand?

No.

WiresharkWhen displaying message details, there is a rule: Infothe application layer information is displayed first.

Let’s check 6the details of the package

It turns out that this FINmessage got a ride.

The actual recycling process is as follows:

Case: Sending data that exceeds the receiving window of the other party

Look at this example, 47390one end of the port claims that its receive window size is ” 190” bytes, and then the other end immediately sends it 308bytes of data.

ah?

Calm down, calm down. TCPThis is not the case at all. Think about it carefully, what determines the size of the receive window?

TCPProtocol headerWindow

But is that the whole story?

Not really, there are also TCP OptionsChinese ones window scale.

First let’s look at window scalethe purpose:

The TCP window scale option is an option to increase the receive window size allowed in Transmission Control Protocol above its former maximum value of 65,535 bytes. This TCP option, along with several others, is defined in RFC 7323 which deals with long fat networks (LFNs).
—— wikipedia

That is, with the construction of modern networks, in order to cope with the scenario of large bandwidth and high latency, the fields TCPin the protocol header windoware no longer sufficient. Because it is only 2bytes long, the receiving window is at most 65535bytes. So in order to declare a larger receiving window, you can only TCP Optionsdo something, which is window scalethe origin of.

Here is an window scaleexample

The above value indicates that the receive window is the size of TCPthe header windowmultiplied by 4.

Then we go back to the example we started with and find that the three-way handshake packet was not captured.

No three-way handshake packets were captured. Is there any problem?

This is a big problem. window scaleWhether it is enabled and the enabled value are only transmitted in the three-way handshake.

If we do not capture the three-way handshake packet, we have no way of knowing window scalethe value of , wiresharkand we cannot windowmultiply the value of window scaleto get the final receive window size.

If you are not familiar with tcpthe protocols and wiresharkpresentation, you might yell that computer networks are too complicated! Haha.

Summary

• Often, application layer logs alone cannot solve or even locate the problem. It is also necessary to capture data packets at the network layer and transmission control layer and look at them together to successfully solve the problem.
• wiresharkThere is a cost of understanding between the prompts and the protocol itself. You need to use it more often wiresharkto capture packets and practice repeatedly to understand wiresharkits temperament.

The statement about these two gaps comes from a course called “Network Troubleshooting Case Course” in Geek Time (for me, this is the most exciting course in Geek Time), and I strongly agree with it.

I think the reason for this is that even if Wiresharkit is a powerful tool, considering that the network itself is so complicated, if you want to solve network problems like a butcher cutting an ox, you must put in a lot of effort!