Upcoming SPDY support details | Hacker News Reader

Upcoming SPDY support details

forum.nginx.org

For the podcast-learning types, I enjoyed the Security Now episode where they went over SPDY, episode 343.

It was a nice gentle introduction to the subject while I was walking my dog.

So with Nginx, Apache, Tomcat all supporting SPDY that will be quite a lot of the widely used servers. I wonder how popular and widely implemented SPDY has to get before Microsoft would cave and put it in IIS and IE? I am sure they will hold out for a bit, but at some point if 50% of web traffic can go faster and IIS doesn't support that, it's going to be a pretty big disadvantage for IIS.

Why would Microsoft hold out? Is SPDY technologically inferior in some way? Does it give Google some competetive advantage? Does not supporting it give Microsoft some competetive advantage? Is there a fourth reason that I'm missing?

SPDY is one frackin' cool protocol. I could easily see it being used as the default protocol for everything in the future, including inter-app comms in an OS.

SCTP is much cooler. It's not HTTP-foucsed, doesn't violate layering and no-one uses it!

AFAIU, the upcoming browser-to-browser networking in RTCWeb will be SCTP over DTLS over UDP.

pwpwp, there is no point in encrypting traffic between 2 processes on the same machine, as the data is already in memory unencrypted. In fact, there's not a lot of point in encrypting traffic between 2 machines on the same internal network. Only when you hit the internet, does traffic need encrypting.

Microsoft's Speed+Mobility proposal is actually much better than Spdy:

http://tools.ietf.org/html/draft-montenegro-httpbis-speed-mo...

They took Spdy and dropped priorities, settings and other ill-conceived parts from it and made compression and encryption optional. There's still some Spdy warts in the HTTP parts of it though...

One of the reasons SPDY uses encryption is to ensure intermediate proxies do not mishandle the new protocol. A couple of SDPY devs gave a tech talk[1] where they mentioned the problems with tunneling a new protocol (in their example websockets) through HTTP (19:11 into video). Sending websockets over HTTP on port 80 only has a 67% success rate. HTTPS over 443 had a 95% success rate. The benefit of HTTPS is that intermediates cannot see or interfere with data transfer. The disadvantage is that caching and CDNs are more difficult to use.

As an interesting side note, tunneling HTTP over a random port (in the slides port 61985) had a higher success rate than port 80 (86% vs 67%). If I remember correctly, the speakers attribute this to intermediate proxies hardcoded to handle port 80, leaving other ports free of processing.

[1] http://www.youtube.com/watch?v=TNBkxA313kk

I don't have much opinion either way. However, always-on encryption and compression is one of the best bits about SPDY.

One of the creator of SPDY's responses to that proposal.

http://www.belshe.com/2012/03/29/comments-on-microsofts-spdy...

They took Spdy and dropped priorities, settings and other ill-conceived parts from it and made compression and encryption optional.

So they prioritized different things. That doesn't make it much better.

As an aside, where is the Microsoft reference implementation of Speed+Mobility? Where is their browser support for it? This, like so many Microsoft initiatives, seems primarily intended to delay and divert an initiative to make the web better.

"just roll it out and make everyone do what we did" is precisely the mechanism that has saddled us with innumerable busted protocols and bizarre implementation artifacts.

Yep! Any day now the beautifully designed X.25 protocol[1] will replace TCP, just like OSI[2] predicted.

Rough Consensus and Working Code[3] built the internet, and it seems to work well enough to be useful.

[1] http://en.wikipedia.org/wiki/X.25

[2] http://en.wikipedia.org/wiki/Open_Systems_Interconnection

[3] http://en.wikipedia.org/wiki/Rough_consensus

You appear to have reached a very different conclusion than I.

Then again, hard to argue that strategy is all bad. We have the internet as it is today, which while perhaps not ideal, is quite a thing.

It is also a way to essentially put your money where your mouth is, aligning interests and ensuring that you really believe what you're saying. Pushing out specs is a little too easy to simply delay others from doing anything.

Further implementations can be credibly compared and considered. Many "HTML 5" features came via Google Gears, and would have taken a decade the traditional paper route.

Because we need encryption for that, or...?

For a variety of reasons I recently needed a reverse proxy(#1) and went with Apache 2.2 w/Google's mod_spdy. What are the advantages, if any (above and beyond that nginx has a lot of cred right now), of using nginx? In a prior build-out nginx didn't even support HTTP/1.1 on the inside side of the reverse proxy, while Apache 2.2 does.

#1 - We use it as a "least effort" geodistributed CDN. GeoDNS directs worldwide users (a small number of very high value users) to their local reverse proxy that has local caching of cacheable resources. Those proxies speak to the normal HTTP back-end servers through an SSH tunnel).

Nginx is widely regarded to be much more efficient than Apache, as it using non-blocking IO. I believe Nginx does support HTTP/1.1 now.

Apache can use event-driven non-blocking IO too, as well as the more traditional thread-per-connection mode.

Apache's event MPM is not really an event MPM. It's a slightly modified worker MPM. It puts all idle connections (keepalive state) and listeners in a single thread. Each active connection gets its own thread.

The event MPM also behaves the same as the worker MPM for SSL connections.

http://httpd.apache.org/docs/2.4/mod/event.html

This is incorrect for Apache 2.4: In 2.4 there is async write completion.

SSL behavior is still like the worker MPM, due to design issues in mod_ssl and filter stack. This is unlikely to change until 3.0.

In what sense is Apache 2.4.2's event mpm event-based when this is the result of siege -c 1000 http://hostname:port/sample.txt

  server-info selections
  MPM Name: event
  MPM Information: Max Daemons: 1 Threaded: yes Forked: yes

  server-status selections
  1550 requests/sec - 1.6 GB/second - 1.1 MB/request
  9 requests currently being processed, 41 idle workers

  W__W_____W_W_______R______W______W_______W__W_____..............
  ................................................................
  ......................

If those are asynchronous response writing handlers in the sense that they could be handled by an event loop, why do they have their own threads?

Personally I find nginx to be a lot nicer to work with than Apache when it comes to the configuration.

Agreed.

Not having to deal with Apache style rewrite rules alone is worth it. Had a scenario recently where I had to try to unwind about 50 of those rules (client site). Made my head hurt.

Reply on news.ycombinator.com