[dns-operations] Google Chrome Pre-Caching

[David Dagon]

On Wed, Sep 03, 2008 at 05:22:49PM -0700, Michael Sinatra wrote:
<snip>

After some use, chrome learns common domains and estimates which ones
benefited from the session's prefetching.  It then marks these domains
for prefetching on restart.  (See dns_global.cc's 
DnsPrefetchHostNamesAtStartup function).  To avoid the obvious
DoS behavior, the maximum number of domains chrome will prefetch on
restart is 10.  The PrefechObserver.kStartupResolutionCount variable
is a static const, so this appears beyond even abuse by power users.

After automating top-level interaction with the top 1000 domains, I
was only able to induce chrome to learn and prefetch-on-startup mostly
ad sites, trackers, and a few common search pages.  (It turns out,
there are dozens of tracker domains, and over time I suspect they
will occupy a large fraction of the '10' slots in most users
caches.)

Less than 10% of the domains were considered by chrome to have
benefited from dns prefetching; the median speed up was ~300ms, mostly
because of a few outlier (slow) domains.  To chrome's credit, slow
resolving ad sites do delay rendering ... but I suspect this is most
typically found in single-threaded browsers, of which chrome is /not/.

The DNS community has previously considered, and usually dismissed,
the idea of pre-fetching "common" DNS names on server startup.  This
approach will now be tested on the stub level--but only up to 10.
This seems to be an opportunity to test ideas.

Chrome users can browse to "about:dns" for stats on their session's
DNS prefetching.  The "Applicable Prefetch Time" column evidently
shows chrome's calculation of the time savings realized from
prefetching.  It is not clear how chrome handles cache misses in the
recursive; this might bias local statistics, and the decision to pick
a domain for prefetching.  I need to further review the logic of
chromium/src/chrome/browser/net/.  For example, if the prefetching is
due to a slow/burdened authority server, the nomination of a domain
for additional resolution on startup may be unwise or harmful.  (The
key is how chrome measures the Applicable Prefetch Time, and its http
observer logic.)

Overall, I think this is fascinating; readers of this list might want
to learn more about chrome's behavior, particularly since it gained
~2% of the browser share in one day.  Moreover, the stub collects
stats on itself--a wonderful opportunity for honeypot operators and
researchers.

We will learn, in aggregate, how these local decisions affect
recursive service, and perhaps even related infrastructure.


-- 
David Dagon              /"\                          "When cryptography
dagon at cc.gatech.edu      \ /  ASCII RIBBON CAMPAIGN    is outlawed, bayl
Ph.D. Student             X     AGAINST HTML MAIL      bhgynjf jvyy unir
Georgia Inst. of Tech.   / \                           cevinpl."