

Add SPDY support to your Apache server with mod_spdy - joedevon
http://googledevelopers.blogspot.com/2012/04/add-spdy-support-to-your-apache-server.html

======
nfm
Can't wait for SPDY to be implemented for nginx. There's been discussion about
it several months ago, but I haven't heard anything since.

Does anyone who's involved with nginx have more info?

~~~
chc
According to the nginx Twitter, they're targeting a May release:
<http://twitter.com/#!/nginxorg/status/192301063934705665>

~~~
piotrSikora
They're targeting _May_ release.

~~~
chc
OK, I removed the joke about software schedules for the sake of not confusing
anyone (especially since I realized this thread will probably rank for [nginx
spdy] in like two minutes).

------
vgnet
A bit OT, but has anyone noticed that Twitter seems to have stopped using
SPDY? Any information on that?

------
SeoxyS
I wonder how SPDY would work in a load-balanced environment.

\- Should the load balancer use implement SPDY externally and use HTTP
internally? \- Should internal request be 100% SPDY-only and the load balancer
implement both?

~~~
whalesalad
I think currently the most convenient thing is to use HTTP internally and have
something on the front end that does SPDY between end-user and server.

Seems like SPDY would be beneficial as a replacement for HTTP everywhere
though, because the payload for each request is smaller. However, SPDY seems
to be optimized for the longer, higher latency, and slower connection between
user and server rather than the faster internal connection between load
balancers and servers. Finally, all SPDY communication is encrypted via TLS,
so that process might add to a slowdown between internal systems.

Guess we'll need to benchmark it and see! Looks like Apache and Jetty are the
only supporters of this so far. And I'd never us Apache as a direct front-end.

~~~
WALoeIII
It doesn't really matter.

For simplicity put SPDY on the edge and reverse proxy HTTP to whatever you
used to use, this gets you 90% of the way there.

In the future, I expect we'll see tools like Mongrel2 take over. SPDY on one
end, and some type of messaging on the other side. This will become more
desirable with technologies like web-sockets that will stream data back. HTTP
is simple, but hardly optimized for speed, even on a LAN. Thrift, Protobuffs,
MessagePack, even Erlang's Binary Protocol (i.e. BERT) are all better fits for
the internal RPC protocol

------
grecy
From the comments on that article, it looks like Google will only implement
SPDY for HTTPS, because Google believe that's the future of all HTTP requests.

I'm not cool with that. I feel like a ton of HTTP requests are for very simple
html pages that don't require any kind of login/security and the overhead of
HTTPS is of no benefit.

~~~
brandon
I'm completely cool with it. Modern equipment can handle plenty of SSL
traffic, and SSL-by-default will protect me (and you) from lazy developers.

The real question is whether or not this will proliferate and to what extent.

~~~
zobzu
Yeah but you've to pay for SSL certs that works in everyones browser without a
fat "DONT GO TO THIS EVIL WEBSITE OMGOMG SELFSIGNED TERRORIST"

Meaning you'd have to pay a tax to put your site on the net when everyone only
uses SPDY.

~~~
wmf
There's been some discussion that you could run SPDY with a self-signed cert
and it just wouldn't show the lock. People need to make their opinions on this
topic known to Google and Mozilla before the security model is finalized.

~~~
ComputerGuru
Do you have any info on that? Links, references, mailing list messages,
anything? That's super interesting and honestly, the way it should be. HTTPS
w/out certificate verification is STILL more secure than HTTP and it should be
treated as such - not as the black sheep that it currently is.

~~~
wmf
<https://groups.google.com/forum/#!topic/spdy-dev/R3Pt4NE2bjc>
<http://thread.gmane.org/gmane.ietf.http-wg/9960/focus=10001>

Like I said, they're just discussions and currently the tide is against us.

------
maratd
What? Why not Apache 2.4? That's the current stable version.

~~~
quonn
I'm glad they made 2.2 packages which is the version deployed on virtually all
production servers in the last couple of years.

------
wmf
That architecture sounds like a DoS nightmare. Now you can run out of Apache
processes much faster! I wonder if mod_spdy has any built-in mitigation for
this.

~~~
saurik
Please stop using mpm_prefork... it is 2012: mpm_event just officially went
stable (although it has worked fine for years) and mpm_worker has been the
correct option for most of Apache 2.x.

(edit: I make this point because I handle thousands of concurrent requests
with a small handful of processes; I run out of memory way before I run of
processes.)

~~~
jdub
It _is_ 2012, and anyone using PHP with Apache 2.2 will be using mpm_prefork.

Much as the popularity of nginx deployments with PHP/fastcgi has grown, I
suspect we'll see more mod_php-less Apache deployments as Apache 2.4 grows in
popularity.

~~~
saurik
AFAIK, mod_php has been compatible with mpm_worker for many years now... it is
only that there are a few PHP extensions that are incompatible, and people
don't want to spend the time documenting which ones those are, so their
default recommendation has always been "use mpm_prefork": if you actually care
about your deployment you can just figure out whether your extensions are
compatible.

------
cagenut
Its not clear from the post, are they implementing their own mpm? as in
mod_spdy takes the place of mod_prefork/worker/event?

------
zobzu
" make BUILDTYPE=Release"

cool but there's no makefile in their source.

