Monday, June 13, 2011

SPDY on the Client Side

‹prev | My Chain | next›

Tonight, I am going to play around in the client under SPDY. A recent question on the spdy-dev mailing list asked how to detect SPDY on the client-side. The answer was window.chrome.loadTimes().wasFetchedViaSpdy

Indeed, that seems to work. I load the sample SPDY server in node-spdy, to find:



I root about the various other objects in an attempt to find traces of SPDY in the client, but without much luck. The remainder of the loadTimes() object:
window.chrome.loadTimes()
Object =>
{
commitLoadTime: 1308016338.425257,
finishDocumentLoadTime: 1308016338.52675,
finishLoadTime: 1308016338.559778,
firstPaintAfterLoadTime: 1308016338.560204,
firstPaintTime: 1308016338.560204,
navigationType: "BackForward",
requestTime: 1308016338.297097,
startLoadTime: 1308016338.393768,
wasAlternateProtocolAvailable: false,
wasFetchedViaSpdy: true,
wasNpnNegotiated: true,

__proto__: Object
}
The wasFetchedViaSpdy and wasNpnNegotiated values seem fairly self-explanatory. I would guess that wasAlternateProtocolAvailable value would be true if the node-spdy server offered more than just SPDY. So I update the test server to return HTTP/1.1 as well:
var options = {
//...
NPNProtocols: ['spdy/2', 'http/1.1']
};

var server = spdy.createServer(options, function(req, res) {
// ...
});
But when I reload the test page, I find that window.chrome.loadTimes().wasAlternateProtocolAvailable is still false. Just to make sure I am not doing something silly, I check the SSL negotiation in Wireshark. I find that yes, there are two protocols offered:



Hrm... I am unsure about that. I will follow up on the spdy-dev mailing list to see if my expectation is in error.

I am hard pressed to worry too much about this. Aside from reporting, I cannot think of many use cases for the client knowing that the page was served via SPDY. As far as the page is concerned, any secondary interactions would be the same over HTTP as over SPDY. Be it server-sent events, web sockets, or plain-old AJAX, as far as the client is concerned, it is all going over HTTP.

If a use-case does arise, the SPDY / NPN information will likely need to be stored elsewhere besides window.chrome.loadTimes()—especially if SPDY is adopted by browsers other than Chrome. For now, that will complete my exploration of SPDY inside the client. I will switch back to the server side tomorrow.


Day #50

2 comments:

  1. Apologies for commenting so long after the original post.

    1) Did you ever hear what .wasAlternateProtocolAvailable is for? I've been wondering too.

    2) One way to see whether a response was sent over SPDY is to check the response headers, although this isn't available through JavaScript, as far as I'm aware. SPDY must send some special headers, such as :version, which aren't allowed in HTTP.

    Thanks

    ReplyDelete
    Replies
    1. Nope, I think I completely forgot about wasAlternateProtocolAvailable until your comment :D

      You cannot check for SPDY headers like that. As far as web pages in the browser are concerned, they were loaded up over HTTP. SPDY encapsulates HTTP, making it invisible from the web page (and often server) that SPDY was used. All that is left are the HTTP headers.

      Delete