I need to measure how long it takes to send a web response to a client - from the server-side only. I know there are ajaxian and client-side ways of doing this but I am limited to a server-side only way of measuring the time to the client.
Is it possible to roughly approximate this using the ACK sent back from the client browser after the server sends the response?
As described by ... http://www.usenix.org/event/usenix02/fu/fu_html/node10.html.
Is this figure reliable?
The ACKs would arrive roughly once per two segments you send (if all is OK). They tell you that the client has accepted the data. So, assuming that the trip time from client to server is the same, deltaAckNum/deltaT should give a reasonable estimate of how big was the average speed. Obviously the more packets these two ACK segments span, the better.
You can get the estimation of the RTT at various point in time if you look at the Timestamp option - when one side sends a timestamp in TSVal, the other echoes it in the TSEcr field of the return packets. Though not just a delay from client to server, it helps to get a feeling.
Though, there are a couple of "but" to mention:
1) unless you specifically trying to increase the performance of transfers of the huge files because someone complained, it might very well be that the bottleneck is elsewhere up the stack. (e.g. the dependence of the elements on each other that require them all to be downloaded to be always visible, etc). For debugging that YSlow would be of good use.
2) the client in question might be behind a proxy-like middlebox that will ACK the data on the TCP level for them, but by itself do some "clever" things (shaping/content filtering/etc etc).