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 where 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 ), 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 , where 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 in the figure. The magnitude of 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 time before the client starts seeing it. The amount of time 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 ( = 160ms, = 60ms, varying from 200ms to several seconds, for a 2-KByte response at 20 Kbps is 800ms), we notice that if is large, the low bandwidth link is idle for a substantial portion of the time. Also, regardless of the magnitude of 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 . 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, is shorter if is long enough.