This is our old Q&A Site. Please post any new questions and answers at


a. Since Wireshark is installed on client-side, i can fully appreciate RTT calculation for client (start of SYN sent out to receival of corresponding SYN-ACK).

But how does Wshark calculate RTT for server (start of SYN sent out from server to receival of corresponding SYN-ACK at server-end) when no wireshark is installed at server-end to record the sent and receival times of relevant pkts? Does this calculation rely on TCP header timestamps calculated at client side(installed with wireshark) after the pkts are received at server?

b. [Source=Client] [Destination=Server] [RTT_ACK =0.2111]

Does the above refer to (RTT=0.2111) for SYN sent out by server and ACK received by server?

This RTT ACK value increases during my capture. Is it normal? What could lead to increase in RTT ACK? High CPU and/or memory utilization?

c. Btw, i saw someone posted the following response in another thread

RTT for TCP sessions, which can be done by finding the initial SYN, and then (after setting a time reference on it) looking at the relative time of the ACK (third packet in the TCP three way handshake).

=> i thought the RTT should be time between start of SYN sent out to receival of corresponding SYN-ACK?, and no relation to the 3rd packet?

Seek your kind guidance : )

asked 02 Apr '14, 02:21

walnut23's gravatar image

accept rate: 0%

a. The RTT should be the same for client and server, since it is the same distance. There are exceptions of course, e.g. when asynchronous routing is in place, but if both systems use the same path the RTT is basically the same.

b. Wireshark tells you in the SEQ/ACK analysis "this is an ACK to the segment in frame x". If you select that frame and use the popup menu to set a time reference on it, you can use the time display format "seconds since beginning of the capture" to see that the ACK has exactly that time. So if you're looking at the SYN-ACK it is the time it took to receive it as an reaction to the SYN. If you're capturing on the client, this is the "initial RTT" (if, and only if, captured on the client! Otherwise look at the ACK in the third packet).

And yes, RTT changes over time. Sometimes it goes up, sometimes it goes slightly down, but it is usually not faster than the initial RTT. Reason is, that small packets have better chances of passing through routers and other devices quickly, while big packets are sometimes queued in a buffer until there is room for them. Depending on the load on the devices in the path from client to server the RTT can fluctuate.

c. If you only look at SYN to SYN-ACK you need to have captured on the client, otherwise there is parts of the path missing. When looking at SYN, SYN-ACK, ACK all parts of the path are included, so this will tell you the RTT no matter where you capture. If you take a look at your capture you'll notice that the ACK from the client is so fast that it doesn't really have a significantly higher RTT value than when looking at the SYN-ACK. So if your capture device is in the middle between client and server you can still tell RTT from looking at how long the handshake took, from SYN to ACK.

permanent link

answered 02 Apr '14, 02:49

Jasper's gravatar image

Jasper ♦♦
accept rate: 18%

edited 02 Apr '14, 02:50

Thank you for your prompt response.

a. If the following statement is true

both systems use the same path the RTT is basically the same,

Assuming Synchronous Routing,

  • Then why is the capture showing significantly higher values of RTT ACK in the direction from client to server?

  • At some points of my capture, I am seeing >200ms of RTT ACK from client-to-server compared to <50ms from server-to-client?

  • How does wireshark installed in Client detect time of packets rcv at server-end?

b. I apologise for the typo for 2nd question [Source=Client] [Destination=Server] [RTT_ACK =0.2111]

  • May I confirm again that the above refer to (RTT=0.2111) for SYN sent out by CLIENT and ACK received by server?
(02 Apr '14, 18:36) walnut23

You need to keep in mind that Wireshark can only calculate timings based on the location the packets were captured.

E.g. if you capture at the client, the packets have timestamps of them arriving and leaving the client. This means that anything coming from the server will have a very short ACK time because you do not have network distance delay. For packets coming in from the server the timing will be significantly higher because RTT of the path is added as network distance delay.

To investigate this kind of thing you might want to take two captures, one at the client and one at the server. If you compare RTT ACKs in each of the captures you'll see that the timing is always fast for packets that are sent to the other system, and slow for those coming in.

So to answer the 3rd question: Wireshark can't detect time of the packets received at the server end. It can only do that if you capture at the server, too. But then the trace will not have the timings on the client end, of course.

Regarding b., without a capture and specific packet numbers it is not exactly clear what timings you're looking at, but RTT_ACK is just the time that it took to acknowledge a packet. So in case of a SYN going out and a SYN-ACK coming in, the RTT-ACK in the SYN-ACK is the time that it took to acknowledge the SYN, including all delays. Depending on the capture location, this value may be higher or lower - higher at the client, lower at the server.

(03 Apr '14, 00:53) Jasper ♦♦
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 02 Apr '14, 02:21

question was seen: 3,818 times

last updated: 03 Apr '14, 01:04

p​o​w​e​r​e​d by O​S​Q​A