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.