Wireshark - TCP Tips & Tricks

There are times when I need to look at the TCP packets to help design a load test script or understand what is happening under the hood. Having a basic knowledge to analyze TCP packets can be a useful skill to have as a performance engineer.

In this post, I will focus on the TCP three-way handshake and share some tips & tricks I use to understand what is happening at the TCP/IP layer using Wireshark. There is a lot of interesting and useful information you can learn from just analyzing TCP three-way handshake.

Let's get started.

Time-To-Live

Time-to-live (TTL) refers to the amount of time or “hops” that a packet is set to exist inside a network before it is discarded by a router.

TTL value gets decrement as the packet moves through every intermediary device on its way to its destination. The TTL can have a maximum value of 255 (8 bit header). Usually, you will see a TTL of 128 or 64/60. So far I have not come across a TTL of 255. This link details some of the default TTL values across devises/Operating systems. So...

• Where was the TCP trace captured from?

TTL value in the SYN packet can give you a big hint. If the value is 255/128/64 (/60 in some cases), 99.9% chance it was captured at the client-side.

• What is the TTL value on the Server?

If you have a TCP trace captured on the server then follow the same process as above but look at the SYN/ACK packet. It will give you the TTL value of the server.

However, If you only have a trace from the client then look at the TTL value in the SYN/ACK packet. It will point you to a potential TTL value of the server.

In the screenshot, the TTL value for the SYN/ACK packet is 50. Based on the known default values of different OS, it is safe to assume that the TTL on the server is either 60 or 64. If you want to be 100% certain then look at the Server TCP trace too.

• How many hops are there between the Client & Server?

Again if you have trace from both the client and the server, analyze them to give you the correct # of hops.

If you only have the client trace than look at the SYN/ACK packet. From the above SYN/ACK screenshot we can guestimate that the # of hops between the client and server is either 10 or 14. This is based on the assumption that the server has either TTL of 60 or 64. It is most likely that the server has TTL of 64 but we don't have that confirmation from the client trace file.

To validate what I saw in through Wireshark, I also ran a "tracert" to the server. As the screenshot shows, it reported 14 hops to the server. Starting with the first hop which is my home router.

Also it is unlikely the server to have a TTL of 255 or 128. If it was 128 then it means there were 78 (128 - 50) hops between server & client. That is a lot of hops. This is why it is important to capture on the server too.

• What OS is Client & Server running?

Most of the time if you see a SYN packet with TTL of 128 in the trace file, it is safe to assume the device is running Windows OS. If you see 60/64 as the TTL value it is safe to assume it is Linux/Unix OS. Nowadays you can also get Linux OS with TTL of 128. Thread with caution when making a call. This is just a guideline.

Round Trip Time

Round trip time is the amount of time it takes a request to go from a source to a destination and back again to the source.

• How do I find what is the Round Trip Time?

You can get the round trip time by taking the time difference between the SYN and the SYN/ACK packets. Wireshark has an option called TCP Delta that can help you calculate the difference. In the screenshot the RTT between the client and destination is 290ms.

If you look at the tracert screenshot earlier, the RTT reported by it is approximately same as what Wireshark TCP Delta column is showing.

Maximum Segment Size

The maximum segment size is the maximum TCP datagram size. It represents the maximum payload size an endpoint is willing to accept within a single packet. THE maximum MSS value is 1460 bytes.

• Does the MSS field get sent in all the packets?

MSS is only announced during the TCP handshake in the SYN segment. If you don't capture the TCP handshake than you won't know this value.

However, there is another way to find out and that is by looking at the TCP Segment Len. It will give you a hint as to what MSS value might be and agreed upon during the handshake.

• Where do I find the Client and Server TCP MSS size?

The client and the server maximum segment size is advertised in the TCP options field.

In the screenshot below the client advertised MSS of 1460 bytes and the server advertised MSS of 1412 bytes. One thing to take into account is that it is not necessary that the server has advertised MSS of 1412 bytes. It could be that server advertised MSS of 1460 bytes but an intermediary device changed it to 1412 bytes to accommodate it's own header data.

• What if the MSS size is missing in the header?

If the TCP MSS value is missing then a default size will be used and that is 536 bytes. Smaller MSS value impacts network throughput.

• What happens if the MSS size of the Client & Server is not the same?

During a three-way handshake, if both sides have the same MSS value than that is what it will be used throughout the TCP session. If either one has a smaller value then the smaller MSS size will be used in the rest of the TCP session.

Selective Acknowledgment (SACK)

The default TCP behavior is to send all the packets again after the original packet was lost. This is prone to cause unnecessary retransmission of data, which can exacerbate a congestion condition. SACK is the method of resending only the necessary packets that never reached the receiver and hence help eliminate the redundant traffic.

• How do I know SACK is permitted?

Under the TCP Option, look for the SACK. If it has value SACK permitted then that device allows selective acknowledgment. Having SACK permitted can help improve the performance as the server doesn't have the retransmit all the packets again, from the point when a packet went missing.

• What if the Client/Server doesn't have the SACK Permitted option?

If one side does not allow SACK then the TCP session can not take advantage of it. In case a packet is dropped and even if the client received subsequent packets, the server will have to retransmit the dropped packet and subsequent packets that were already received by the client. This can lead to network congestion and waste of time.

• How to Identify SACK in action?

In the screenshot, the client is sending the server a DUP ACK (Wireshark TCP DUP ACK) message. If you look at the SACK option, what it is telling the server is that I am good until packet #125217 (Acknowledgment number) and by the way, I also acknowledge that I have received packets #125395 to #126807 (left and right edge). However, I am missing packets between 125217 and 125395. Please send those through.

• Why do I see every single packet being acknowledged?

Under a normal situation, the client will acknowledge any two packets or any two full-size packets. Just like in the screenshot. As you can see, the server sends two full size (TCP Segment Len = 1412) packets and then the client sends an acknowledgment.

However, when a packet goes missing, the client will start sending acknowledgement for every packet it receives instead of any two packets or two full-size packets. This will continue until it receives the missing packet.

As shown in the screenshot. Every time client receives a full-size packet, it immediately acknowledges it rather than waiting for one more packet before sending an acknowledgment.

In a subsequent post, I will talk about Window Scaling, Ghost Byte, Sequence numbers & IP Fragmentation.

What else do you think we can learn from the three-way handshake?

-----------------------------------------------------------------------------------------------------------

Thanks for reading!

If you enjoyed this article feel free to share on social media 🙂

Say Hello on: Linkedin | Twitter