SPDY is built on top of TLS, which means it requires a site to have a valid SSL certificate in order to work. This, unfortunately, limits SPDY only to CloudFlare's paid customers who have enabled Flexible or Full SSL support. Microsoft is working on revised IETF proposal that is SPDY-like, but removes the requirement for SSL/TLS. If the TLS requirement is removed in the future, we'll make SPDY (or whatever it comes to be called) available more broadly.
Can SPDY theoretically be transitioned to not be built on top of TLS, or is the MSFT work a more likely solution?
SPDY does not technically require TLS, but It's the Right Thing To Do [tm]. According to Mike Belshe, there are two reasons that SPDY was designed to use TLS. The first was pragmatic: Middleboxes on the Internet wouldn't be able to pass through non-HTTP traffic, so unless a different port was used, the only way to punch through the various proxy layers was to use end-to-end security. But the other reason is just as important: It's 2012, folks. It seems insane that most Web traffic goes in the clear. Browsers are fully capable of doing the SSL handshake without incurring a major performance cost - even on mobile devices. Finally, we may not get another chance to change the web protocol stack for another 15 years, so it's best to get it right now.
One of the reasons SPDY is on top of TLS is so that equipment between the browser and the server doesn't try to mess with the protocol. If SPDY were run on port 80 then there would be problems with proxies etc. Wrapping it in TLS means that it can't be snooped upon and messed with.
SPDY as specced does not require TLS. However, you can see Google's WebSocket connectivity test results at http://www.ietf.org/mail-archive/web/tls/current/msg05593.ht.... The poor connectivity over ports other than 443 is one of the strongest motivations for real deployments of SPDY over the public internet to require TLS.
"By gathering all scripts, regardless of where they're hosted, into a single HTTP request, Rocket Loader limits the number of HTTP connections that are needed. This also means that even third party scripts that appear on your page are requested under your site's domain. "
CloudFlare's server acts as a proxy. It downloads each resource over HTTP from its original location and caches it, then delivers all the resources to the client over SPDY. The preceding paragraph explains it:
"For SPDY support, CloudFlare acts as a gateway... We handle the multiplexing and begin sending down objects we already have in our cache. The request to the origin server for non-cached objects is sent over standard HTTP/S."
This is similar to the proxy mode in Amazon's Silk browser for Kindle Fire.
Do you rewrite the hosts on all third party sites to be the site domain? I'm still not following this setup.
Silk is an entirely different setup. Silk (a) manually sets their SPDY gateway as a browser proxy, which is a system level setting, and (b) silk does not tunnel HTTPS requests. CloudFlare obviously doesn't have control over my browsers proxy settings, so if the page I'm loading is abc.com/page, and that page has a request to twitter.com/widget.js, then the browser should open a connection directly to twitter.com to fetch that resource.
P.S. SPDY does allow tunneling HTTPS, but once again, that requires a system level proxy setup.
To use cloudflare's "rocket loader", the host domain dns record must point to cloudflare instead of the origin server. If abc.com were using cloudflare, a user's request to abc.com/page would first hit cloudflare's server. Cloudflare would then proxy the request to abc's origin server, rewrite 3rd party urls, and return the modified content to the user.
I'm not sure how well cloudflare handles http vary headers, e.g. 3rd party resources that serve different content depending on cookies or user agent. An example could be google web fonts which serves different css and fonts to different browsers.
Looking through CF's own site, plus a few of their "case study" links, I don't see the domain rewriting happening on these scripts. And as you indicated, with additional complication of user cookies / HTTP vary, I'm not sure that's necessarily a good idea either -- if either of those in place, all of your cache optimizations go out the door. Best gotcha example: ads.
Seems like there is a bit of false advertising going on here.
I haven't seen explicit documentation about the rewriting behavior, but I assumed they were rewriting on based on the before and after waterfall charts in this blog post[1]. I agree it's not a great idea. Cloudflare actually recommends blacklisting problematic scripts [2], which partially defeats the feature's usefulness.
That doesn't seem like a big deal. If you have requirements that every request hit your server then, duh, you can't have a caching proxy in front of your pages.
I think very few ads work that way, though. It's almost always a javascript include (often from a 3rd party ad server).
I'm saying the oppposite. I have no reason to proxy twitter.js or other ads scripts on my site. If CF is taking the step to rewrite those to the same domain, then they also have to guard for respecting all the cache implications of that.
But the part I don't get is Why? Why should I proxy the third parties through Cloudflare to obtain multiplexing? They already are "multiplexed" by virtue of being on a separate domain. I already have great parallelism for those resources.
TCP connections take a lot of time to setup, and go through a ramp phase (slow start), especially on mobile where RTT is 200-1000ms. The theory is that by multiplexing multiple requests over the same connection, you'll get faster overall load time.
You can think of domain sharding as a workaround for the fact that HTTP does not allow true multiplexing. With SPDY, we can avoid that complexity and reuse the same connection.
Right but if I've goth links to third parties already, proxying them through Cloudfare does not reduce complexity, and would not reduce that connection setup time, since the connections already get set up in parallel. It might even add latency. I can see how spdy reduces complexity by permitting me not to have to deploy static links to different domains. I just don't see an advantage in changing links that originate on third parties already, to proxy through cf and multiplex.
Interesting. I wonder if moot will adopt this for 4chan. Recently he's seemed interested in optimizing the site (most notably by cleaning up the HTML/CSS and adding mobile support).
4chan is already using CloudFlare Pro (you can check by visiting their SSL url, they're using CloudFlare cert), so it should be easy for him to enable SPDY support.
Can SPDY theoretically be transitioned to not be built on top of TLS, or is the MSFT work a more likely solution?