

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

======
stanleydrew
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.

------
jvehent
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...

~~~
stanleydrew
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.

~~~
xyzzyz
_SPDY benefits everyone who uses it, not just Google._

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

~~~
jrockway
What's wrong with mandatory encryption? Do you still use rsh to log in to your
servers?

~~~
xyzzyz
_What's wrong with mandatory encryption?_

Some people say that it uses too much computational resources, for instance.
Others complain that mandatory TLS increases latency by one additional RTT.
Mandatory TLS is a biggest point of conflict at the IETF discussion about SPDY
being _the_ HTTP successor (at least from what I heard), though many sides
disagree for evil reasons.

 _Do you still use rsh to log in to your servers?_

Does this question add anything of value to the discussion?

~~~
jrockway
_Does this question add anything of value to the discussion?_

Yes. If you are the "I hate encryption because it messes with my tinfoil hat"
type, you'll get all angry and not reply. For anyone else, the question is
just a minor annoyance to wade through ;)

~~~
xyzzyz
If you wonder whether your disputant may be tinfoil hat type, the exploratory
questions to verify this conjecture may make your disputant not want to
discuss with you any longer, because it's kind of distasteful.

~~~
jrockway
That's why I added a smiley face at the end.

------
AhtiK
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.

