In the TCP handshake, you may see an option called timestamps, shortly followed by scary-looking “TSval” and "TSecr" numbers. What are those values and how can you interpret them? Let’s dig.
What is a TCP Timestamp?
The timestamps option in TCP enables the endpoints to keep a current measurement of the roundtrip time (RTT) of the network between them. This value helps each TCP stack to set and adjust its retransmission timer. There are other benefits, but RTT measurement is the major one.
How it works.
Each end of the connection derives a 4-byte increasing value. This value is unique to each side and has no real numerical significance. The opposite end does not care what the value is, it will simply echo it back to the original sender. The original sender can then measure the timing between the packet(s) that were sent and received with this unique value.
The value used by each end will be increased as the connection goes along. Many TCP implementations will add the measured network RTT value (in milliseconds) to the 4-byte timestamp and use this new number for the next segment to be sent.
For example, in the screenshot below, we can see both ends of the TCP connection using timestamps. Both values, the one used by the sender and receiver, have been added as columns in Wireshark to make them a little easier to see.
The first packet has a timestamp value of 1125169296. Told you it was long and scary! But let's analyze...
At the start of the connection, the sender has not yet seen a timestamp value from the opposite end of the connection, so it has no number to echo back yet. That is why we see a zero in the Timestamp Echo Reply column.
The second packet shows the receiver echoing back the timestamp value, while sending a unique value of its own. Notice that these two numbers are completely different and are not related to each other at all. However, in the SYN/ACK, the timestamp echo value must be exactly the same as the value sent in the SYN, or the connection will fail. The connection initiator will likely send a reset to clear the connection.
Next, in the third packet, we can see that the original sender increases its timestamp by 212, sending a new value to the other end. From the delta time column, we can see that the roundtrip time between the two stations is 212 milliseconds (we captured on the 192.168.10.108 end). This value is added to the original timestamp and sent out on the next segment.
As the connection goes along, these values will increase. While they look long and scary, remember that they are only echoed back from the opposite side allowing the sender to mark and measure the roundtrip time. The value itself doesn’t have a specific meaning.
Keep in mind that the TCP Timestamps Option and the Wireshark-derived TCP Conversation Timestamps (which you need to enable in Wireshark) are very different things. For some info on the conversation timestamps, check out this video: