To those people who took the time to send their feedback, thank you.
In this video, I briefly discuss TCP sequence numbers and acknowledgements, recognizing that this topic can often be very overwhelming. I keep the explanation quick and simple, focusing on a stream of traffic flowing from a server on port 443 to a client. Make sure you have Wireshark installed and follow along.I explain how sequence numbers increment based on segment length—by adding the length of each packet to the current sequence number, you get the next expected sequence number. When I saw a message indicating that a previous TCP segment was not captured, I analyzed the difference between sequence numbers and the typical segment length, concluding that two packets had been lost.
In this video, I briefly discuss TCP sequence numbers and acknowledgements, recognizing that this topic can often be very overwhelming. I keep the explanation quick and simple, focusing on a stream of traffic flowing from a server on port 443 to a client. Make sure you have Wireshark installed and follow along.I explain how sequence numbers increment based on segment length—by adding the length of each packet to the current sequence number, you get the next expected sequence number. When I saw a message indicating that a previous TCP segment was not captured, I analyzed the difference between sequence numbers and the typical segment length, concluding that two packets had been lost.
I also emphasize the importance of understanding the difference between relative and real (or raw) sequence numbers. Relative sequence numbers make the trace easier for humans to read, but they are not the actual sequence numbers found within the TCP header. By changing the display settings in a packet analyzer, you can view the real sequence numbers, which become crucial if you want to correlate the trace data with server or firewall logs. For quick troubleshooting, however, using relative numbers is usually sufficient to estimate how many segments are missing.
To search for lost packets, I advise adding the segment length incrementally to locate the next expected sequence numbers in the trace. Since relative numbers can repeat later, it’s important to filter packets by TCP port pairs and IP addresses to focus on the correct conversation. In my example, even though the server and client are located in the same building and connected through wired switches, packet loss was still occurring. This kind of loss is surprising given the simple network layout, but it confirms that even in straightforward environments, these problems can arise.
Finally, I mention an alternative method for detecting packet loss using command-line tools like `netstat -s -p tcp` to view TCP retransmissions. However, I point out that this approach mostly helps when data is being sent and is not very useful when only receiving data. I intentionally keep my explanation concise and straightforward to avoid unnecessary complications, encouraging viewers to keep things short, simple, and fun while analyzing TCP sequence numbers and packet loss.
The point of the video is to provide a simple introduction so the whole process of TCP analysis becomes a bit more straightforward.
The point of the video is to provide a simple introduction so the whole process of TCP analysis becomes a bit more straightforward.
2026 WiFi Monitoring from the Client Perspective
