SPDY on Rails

http://blog.bugsnag.com/2012/08/05/spdy-on-rails/

by beastmcbeast • 14 years ago

41 16 14 years ago

blog.bugsnag.com

jvehent3• 14 years ago

They forget to explain what problem they are trying to solve. SPDY will benefit google in the race for 100ms response time. For the rest of us, HTTP does the job. But without the hype effect, I suppose...

stanleydrew2• 14 years ago

This is a strange comment. SPDY benefits everyone who uses it, not just Google. And actually, for any site with authentication plain HTTP does not do the job, since all requests that pass authentication information should be encrypted. So HTTPS is a requirement and if SPDY can help make HTTPS faster then everyone wins.

xyzzyz4• 14 years ago

SPDY benefits everyone who uses it, not just Google.

You seem to not notice the elephant in the room, being the mandatory TLS encryption.

jvehent3• 14 years ago

Just because some poorly trained engineers don't understand the concept of security should not force the rest of us to use strong, and slow, encryption. Encrypting the wire should only be used to solve very specific problem. Often, encrypting the data in the application, and transmitting over cleartext http, is better.

I understand those concepts, and that why I don't want SPDY to force me to use TLS everywhere. It's just overkill and cumbersome.

MikeCapone• 14 years ago

As a user, I mostly like SPDY because it makes HTTPS better (not perfect, but better than what was there before), and I wish more sites used an encrypted connection by default. Anything that brings us closer to that is desirable, IMO.

That's mostly out of principle -- I just wish there was less plaintext info swirling around the net. For some people it could be a life or death benefit (ie. civil right activists in repressive countries), but for me personally, it's mostly an aesthetic pleasure (I enjoy the idea of more secure communications).

xyzzyz4• 14 years ago

You may find interesting the fact that most of the IETF basically agree to base HTTP 2.0 on SPDY, with those disagreeing being mostly Microsoft delegates voting for Microsoft's S+M proposal.

jvehent3• 14 years ago

Partly true. I found the discussions on solving the cookie problem, with better session mechanism, and using binary header that are not encrypted, to be extremely interesting. Using encryption everywhere just because we should is dumb. What will happen is that we'll enforce a TLS handshake and use a NULL algorithm. Mandatory encryption will just make load balancing so much slower, and only 5/10% of the HTTP traffic inside a datacenter really deserves to be encrypted.

stanleydrew2• 14 years ago

This isn't really about Rails at all. But it's still useful as another anecdote about how SPDY is used in production.

Basically if you are set up with the now-fashionable architecture of a caching reverse proxy serving static content (nginx or Apache) sitting in front of a set of application servers then this applies to you too.

Just compile nginx with the SPDY patch or use mod_spdy with Apache and your back-end application servers won't even need to know what the transport protocol between client and reverse proxy is. It will be handled transparently.

AhtiK• 14 years ago

My problem with SPDY is that it is compressing only headers.

I still haven't figured out how to combine SPDY and gzip compression for POST requests without manually decompressing it in the browser javascript.

Other than that SPDY is extremely useful for web apps as the latency with HTTP round-trip is noticeable and most of the cases web app already runs behind TLS.

For a regular website (not a web app) SPDY adds much less value: 1) TLS encoding and negotiation adds load time 2) 3rd party javascript loading from HTTPS sources do the same 3) Main server data that was previously sent gzipped is now sent deflated [1].

[1] Maybe it's just my incompetence and it's easy to compress the SPDY content. Would be happy to hear about it.

SPDY on Rails

Related Stories