Simple HTTP conversation | time breakdown

The ACK in 35 is just an ACK, zero data length, so you might think it would be just as quick as the SYN-ACK. But it could be that the server delays the ack until the response is ready. The first byte of response data is packet 36.

If you are analysing server response time, it is also useful to differentiate the Time to First Byte (TTFB) with Time to Last Byte (TTLB). The server is "done" usually when it has started responding and sent the first byte - the client won't do much with the data until it receives the last byte.

Thanks guys, but still not very clear. Please correct my assertions below, if they are false:

1. 219ms consumed on server-side processing
2. 18.6ms consumed by 1st TCP response packet on the network
3. 1.1ms consumed by 2nd TCP response packet on the network (Why so less compared to 2. when length is exactly the same?)
4. 196ms - Is this time included in the RTT time for HTTP response? If not, where does this go? Does it matter for the client?

Thanks, Kapil

1.) No. It's the sum of

deltaSend + deltaProcess + deltaReceive = deltaTotal

where

• deltaSend = RTT/2 to send the request from client to server
  
• deltaProcess = time to process the frame on the server (whatever it does with that request) and to create the ACK, with or without delay
• deltaReceive = RTT/2 to send the ACK from server to client
• deltaTotal = delta(Frame[35], Frame[30])

Only deltaProcess is the time of server-side processing

Look at is this way:

client ............................................ server
(1) Frame[30] —– GET / (deltaSend = RTT/2) —>
                                       (2) deltaProcess 

(3) Frame[35] <– ACK/ (deltaReceive = RTT/2) —
client ……………………………………. server

So: deltaProcess = deltaTotal - 2 * RTT/2 = deltaTotal - RTT (see my answer)

2.) actually, the 18.6 ms are just the delta of the ACK (frame #35) and the first data fame (frame #36) sent by the server. That’s another aspect of the processing time within the server. You cannot determine from a capture file on the client, why it took a certain amount of time, as most of that time is spent in the TCP stack of the server (not considering varying delay on the line, as that cannot be detected with only one capture point).

3.a.) that’s the time it took the server to send the first data frame after the ACK. The server software writes x bytes (> 1500) to the local TCP socket. The TCP stack splits that into several TCP frames. It took the TCP stack 18.6 ms to create and send that first data frame, following the ACK (not considering varying delay on the line, as that cannot be detected with only one capture point).

3.b.) It’s less time, because the splitting operation took place in the TCP stack of the server. Apparently it took only 1.1 ms to do that. The size of the frame does not matter here, as the RTT is the same for all frames. So, the time difference/delta you see in the capture file on the client is exactly the same delta you would see in a server capture file or within the TCP stack.

4.) That’s probably delayed ACK on the client.