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:
- Protocol Gaps between Network Layers
- 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 redis
client and redis
server, mysql
client and mysql
server and other similar things want to communicate over the network, if they are not layered, then redis
they mysql
all 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 peer
This is a nginx
common 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. 11022
Number package, client
send POST
request
2. Send a response 11446
to the number packet server
, indicating that the processing is completed
3. 11448
The number package client
actually sent aRST
At least this time the request was handled perfectly by the server, but it dropped client
immediately rst
.
We need to continue to check client
the 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, wireshark
there is a knowledge barrier between the displayed prompts and the network protocol itself.
Case: ICMP explicit port field
ICMP
It is a network layer protocol. It does not and should not have port
the 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, ICMP
the port number is first 80
!
In fact, it is not that magical. This is just wireshark
a display strategy. We 2
can click on the details of the number package.
It turns out that only icmp
the packet payload
carries 1
the contents of the number packet, and then the port number is displayed in the protocol wireshark
when 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 FIN
message. For example, the following picture:
No matter how carefully you observe these packets, you will find that FIN
the message mark can only be found in packet 7.
Aren’t there supposed to be two FIN
messages in the waving phase? Is the network too complicated for us to understand?
No.
Wireshark
When displaying message details, there is a rule: Info
the application layer information is displayed first.
Let’s check 6
the details of the package
It turns out that this FIN
message 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, 47390
one end of the port claims that its receive window size is ” 190
” bytes, and then the other end immediately sends it 308
bytes of data.
ah?
Calm down, calm down. TCP
This is not the case at all. Think about it carefully, what determines the size of the receive window?
TCP
Protocol headerWindow
But is that the whole story?
Not really, there are also TCP Options
Chinese ones window scale
.
First let’s look at window scale
the 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 TCP
in the protocol header window
are no longer sufficient. Because it is only 2
bytes long, the receiving window is at most 65535
bytes. So in order to declare a larger receiving window, you can only TCP Options
do something, which is window scale
the origin of.
Here is an window scale
example
The above value indicates that the receive window is the size of TCP
the header window
multiplied 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 scale
Whether 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 scale
the value of , wireshark
and we cannot window
multiply the value of window scale
to get the final receive window size.
If you are not familiar with tcp
the protocols and wireshark
presentation, 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.
wireshark
There is a cost of understanding between the prompts and the protocol itself. You need to use it more oftenwireshark
to capture packets and practice repeatedly to understandwireshark
its 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 Wireshark
it 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!