Check out the new USENIX Web site. next up previous
Next: Data Analysis Up: Background Previous: Caching in the HTTP Protocol

Analysis of HTTP Latency

  We now present an analysis of the timing dynamics of a typical HTTP transaction. We assume a setting where the Web browser (client) talks to a server proxy on the other side of a low bandwidth and high latency link, which in turn talks to HTTP servers (content-providers) on the Internet. We use this analysis to make a case for the usefulness of optimistic deltas.

Figure 1: Timeline for typical HTTP request.

Consider Figure 1, which depicts the timeline corresponding to an HTTP transaction between a client, a server proxy, and a content provider. Packets 1, 2 and 3 correspond to the SYN, SYN/ACK and ACK packets that are exchanged as part of the TCP 3-way handshake in the connection establishment phase between the client and the server proxy. The client sees this connection as established after a delay of approximately tex2html_wrap_inline1298 where tex2html_wrap_inline1300 is one half of the round-trip latency of the link between the client and the server proxy. At this point the client sends packet 4 which contains the HTTP request. After the server proxy gets this packet (at approximately time tex2html_wrap_inline1302 ), if it needs to go to the end server to satisfy this request or to validate its cached copy, it initiates a connection with the content provider (packets 5, 6 and 7). The latter connection is established after a further delay of tex2html_wrap_inline1304 , where tex2html_wrap_inline1306 is one half of the round-trip latency of the link between the server proxy and the content provider. The server proxy then forwards the client's HTTP request to the content provider (packet 8).

On receipt of this HTTP request the content provider does whatever is necessary to produce the response. This may include several relatively slow activities, such as forking off a child server and/or passing descriptors to it, forking off a script to produce the response document, invoking and waiting for the response from a search engine, etc. For our purposes we will view these activities as a certain latency shown as time tex2html_wrap_inline1308 in the figure. The magnitude of tex2html_wrap_inline1308 is thus a function of the server in question, the particular URL being served and the load on the server. This time can be highly variable. Some simple experiments on the Internet indicate that it varies from a couple of hundred milliseconds to several seconds. After the response (packet 9) is available and sent off it takes another tex2html_wrap_inline1312 time before the client starts seeing it. The amount of time tex2html_wrap_inline1314 that it takes to transfer the response is dependent on the size of the response and speed of the link.

If we put in typical values for the various time parameters in the figure ( tex2html_wrap_inline1300 = 160ms, tex2html_wrap_inline1306 = 60ms, tex2html_wrap_inline1308 varying from 200ms to several seconds, tex2html_wrap_inline1314 for a 2-KByte response at 20 Kbps is 800msgif), we notice that if tex2html_wrap_inline1308 is large, the low bandwidth link is idle for a substantial portion of the time. Also, regardless of the magnitude of tex2html_wrap_inline1308 we want to minimize the amount of data we transfer over the slow link. These two observations lead to the idea of optimistic deltas. We want to effectively utilize the slow link in its idle time, and if possible, reduce the amount of data transferred, in order to reduce the total latency perceived by the client. If the client and server proxy both cache the same older version, only a delta needs to be sent over the slow link decreasing tex2html_wrap_inline1314 . If the client and server proxy do not cache the same version, the server proxy can transfer its cached version while waiting for data from the content-provider and subsequently send a delta. Here again, tex2html_wrap_inline1314 is shorter if tex2html_wrap_inline1308 is long enough.

next up previous
Next: Data Analysis Up: Background Previous: Caching in the HTTP

Gaurav Banga
Tue Nov 12 20:47:38 EST 1996