877766 - Use speculative connect API to pre-connect to safe browsing server

Status: NEW

(Toolkit :: Safe Browsing, enhancement, P5)

Description

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

+++ This bug was initially created as a clone of Bug #783047 +++

Bug 783047 is about switching the safe browsing service to switch to HTTPS for the HTTP requests to the Google server. We'll need to ensure that we minimize (at least) any performance regression that would come from doing that.

One way to reduce latency caused by safe browsing checks may be to use the to add usage of nsISpeculativeConnect for the safe browsing server (https://safebrowsing.google.com) in some places (e.g. awesomebar, search box, new tab page, browser startup); in fact, that seems like a good idea independently of switching safe browsing to HTTPS.

nsISpeculativeConnect basically does DNS-prefetching, preconnecting the TCP connections, and (AFAICT) completing the SSL handshake.

Comment 1

[Gian-Carlo Pascutto [:gcp]]

>One way to reduce latency caused by safe browsing checks

Note that these are only relevant on positives (false or otherwise), so you aren't going to see much performance difference in real-life.

Does pre-connecting put an actual load on the remote server even if we don't actually do anything with it?

Comment 2

[Brian Ryner]

DNS prefetching is fine, but having all clients keep an open connection to safebrowsing.google.com/safebrowsing/gethash may cause some server-side issues.  Note that we do caching of SSL sessions, so that hopefully mitigates most of the cost of the SSL handshake.

Comment 3

[Patrick McManus [:mcmanus]]

idle connections are easy to manage, its a trivial bit of state they can close if they really want to. Especially for google. Optimize for the latency - that's the whole trick of modern network performance.

Comment 4

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

It is true that we have SSL session caching, but (a) that cache is transient, so we need to do one full handshake per browsing session, at least, (b) even resumed HTTPS (and even HTTP) connections have significant latency overhead, and (c) the Google server might expire the SSL session at any time (though they use session tickets, which means they probably have pretty good session caching).

However, perhaps we don't need to do this, or at least, perhaps we don't need to prioritize it as highly as I thought. I did read more about our implementation and our estimate is that this happens for 1 out of every ~7,000 page loads. Also, my understanding is that we will regularly make requests to http[s]://safebrowsing.google.com in the background anyway, to retrieve data (mcmanus: somewhat like a partial CRLSet). So, we could either just do a speculative connect sometime near startup, or we could try to ensure that one of those background requests happens soon after startup; that would at least get DNS and the SSL session cache primed.

Also note that safebrowsing.google.com may be coalesced with the rest of *.google.com with SPDY connection coalescing, because the certificate used is for the following domains: *.google.com *.android.com *.appengine.google.com *.cloud.google.com *.google-analytics.com *.google.ca *.google.cl *.google.co.in *.google.co.jp *.google.co.uk *.google.com.ar *.google.com.au *.google.com.br *.google.com.co *.google.com.mx *.google.com.tr *.google.com.vn *.google.de *.google.es *.google.fr *.google.hu *.google.it *.google.nl *.google.pl *.google.pt *.googleapis.cn *.googlecommerce.com *.gstatic.com *.urchin.com *.url.google.com *.youtube-nocookie.com *.youtube.com *.youtubeeducation.com *.ytimg.com android.com g.co goo.gl google-analytics.com google.com googlecommerce.com urchin.com youtu.be youtube.com youtubeeducation.com 

So, in many configurations, doing a speculative connect to the default search engine near startup could be sufficient to get the effect that we want (though, we may need to change our SPDY connection coalescing logic to get this win).

Questions:
1. Do we have telemetry that verifies the accuracy of the 1/7,000-ish estimate?
2. Do we already force safe browsing to connect shortly after startup? If so, where?
3. What happens in the interim when the latest background update hasn't happened or when our safe browsing data has gone stale (which happens every 45 min, if I am understanding the safe browsing documentation correctly)? Do we end up blocking the page load while we wait for that update to complete/fail?

Comment 5

[Gian-Carlo Pascutto [:gcp]]

>1. Do we have telemetry that verifies the accuracy of the 1/7,000-ish estimate?

Not directly. We have Telemetry that verifies the amount of 32-bit hashes users have, and the amount of 256-bit hashes that were retrieved by probing Google's remote server, but a recent protocol change made the latter reset every +-45mins, so the Telemetry for that doesn't tell all that much.

There's about 650000 prefixes spread over a 32-bit hash space, so random browsing will hit a prefix every 7000 URL's tried. (IIRC the actual probability math is a bit more complicated and it's closer to 1/5000, but same order of magnitude nevertheless).

This assumes the user doesn't surf to malicious sites, but if he does, loading those a bit slower surely isn't a worry.

>2. Do we already force safe browsing to connect shortly after startup? If so, where?

Yes, there's a guaranteed attempt to connect at a random time 5 mins after startup. Not sure what "where" means. It's in SafeBrowsing.jsm and listmanager.js or so.

>3. What happens in the interim when the latest background update hasn't happened or when our 
>safe browsing data has gone stale (which happens every 45 min, if I am understanding the safe 
>browsing documentation correctly)? Do we end up blocking the page load while we wait for that 
>update to complete/fail?

If there's a *hit* in the old, local DB, we'll do a remote lookup and (IIRC) stall as long as that's pending.

Comment 6

[Gian-Carlo Pascutto [:gcp]]

First update after startup:

http://mxr.mozilla.org/mozilla-central/source/toolkit/components/url-classifier/content/listmanager.js#229

The second check is after 15-45mins:

http://mxr.mozilla.org/mozilla-central/source/toolkit/components/url-classifier/content/listmanager.js#276

Subsequent checks are (IIRC) dependent on the answer of the server.