- ... present.1
- There are
few exceptions to this rule such as
responses to requests with AUTHORIZATION headers
and responses with VARY headers that
are not yet supported by Squid and are very rarely used.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
- ... age.2
- Recall that
the age of the copy is calculated as the maximum of the age
and the difference between the current time and the DATE header
value. Hence, if clocks at different hosts are synchronized,
copies obtained from a cache should have positive age.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
- ... ages.3
- Recall that when EXPIRES
or MAX-AGE headers are not present,
a heuristic is used to determine the freshness lifetime.
The freshness lifetime
is determined as a fraction of the difference between DATE
and LAST-MODIFIED. In that case the TTL
gets penalized twice for the copy's age: first,
the freshness lifetime (fraction of the
difference between DATE and LAST-MODIFIED subject to a limit) is smaller
for older copies, and second, the age of the older copy is larger.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
- ... server.4
- We
distinguish a transparent reverse proxy
cache from an origin server by issuing two consecutive
GET requests within more that a few seconds apart to the same IP-address
of the same server. A cache return a
DATE header as obtained from the authoritative server.
An authoritative server returns the current time according to
its clock. Thus, we examined the
DATE header value of the two HTTP responses. The same value indicated
a cache. Two different values, where the difference approximates
the time between our two HTTP GET request-response pairs,
suggest origin server,
very short TTL (few seconds or less), or a non-cachable object
(that is, no age-penalty effect).
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
- ... proxy) 5
- Interestingly, analysis shows
that otherwise the age penalty is
higher [3]
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
- ...
6
- We conducted the following measurements with
several URLs: We compared the latency of 500 GET requests of the URL
from the same CDN server when (i) the same ARL was used each time
(ii) a different ARL was used each time (e.g., by replacing the string
e0a3b4215f9e4b).
The cumulative latency in the latter measurement
was 25%-40% slower than in the first. This suggests that when seeing
a new Akamization, the CDN server obtains a new copy of the URL
from the origin server
prior to sending the response.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
- ... URL.7
- As of 11/2000, Akamai seem to use HTTP
redirect (302 response code)
to the original URL in some cases when a new Akamization
is seen.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
- ...
server8
- This is true in all cases except when the EXPIRES header is
used in a relative way and there is no MAX-AGE directive (see
Section 2), and when
clocks on the origin site and the Akamai server are
not synchronized
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
- ... (DIRECT)9
- no requests were forwarded to a
parent cache
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.