# SPDY versus WebSockets?

| by Mark Little 2 Followers on Jun 24, 2012. Estimated reading time: 4 minutes |

We've seen a lot of interest in HTML5's WebSockets protocol over the past couple of years. Whether it's basic questions about how it works with the Web infrastructure, or if it can support RESTful services, it certainly seems as though it is a protocol that is here to stay. But of course with most new things it has its share of problems, such as potential security vulnerabilities. However, because one of the driving forces behind WebSockets was the need to improve performance of interactions on the Web, it is not the only game in town: there is at least Google's SPDY protocol, which as we reported earlier this year is being considered by the HTTPbis Working Group as a potential contender for HTTP/2.0.

So far there has been little attention paid to the question of whether or not WebSockets and SPDY compete for the same use cases and if so which is the better option. Co-existing and cooperating seems to be the message though. For instance as Brit Gardner says:

The two protocols are actually complimentary. WebSockets makes its initial handshake with servers over HTTP to discover if the ws:// protocol is supported, and one of SPDY’s primary methods of optimization is compressing and caching HTTP request headers. [...] So, in an ideal future the RESTful request-based web is driven by SPDY, and all of the real-time communication and “app-ifying” is handled via WebSockets. Two peas in a pod!

And Google in March 2012 released a document called 'WebSocket Layering over SPDY/3', so it is obviously something they themselves have been wondering.

However, back in 2009 Mark Nottingham the HTTPbis chair, made a passing comment that might signal where WebSockets and SPDY could see their futures separately:

[...] there was a pretty strong sense in the IETF earlier this week in Hiroshima that a Working Group to standardise [Web Sockets] should be started. if SPDY really does eventually follow the path of WAKA, it could be that some HTTP-like use cases that people have planned for WebSockets may have another outlet instead.

And earlier this month Lori MacVittie, who originally asked about the possible security vulnerabilities in WebSockets to which we referred earlier, followed up a tweet from someone asking about SPDY versus WebSockets with a more in depth discussion. As with Mark, in her view the answer lies in the different ways in which these two protocols use HTTP:

The answer to the question, “Why not consider WebSockets here?” could be easily answered with two words: HTTP headers. It could also be answered with two other words: infrastructure impact. [...] Due to a simple (and yet profound) difference between the two implementations, WebSockets is less likely to make an impact on the web (and yet more likely to make an impact inside data centers, but more on that another time).

Lori believes that despite the fact the two protocols are very similar in some ways (asynchronous, since TCP connection, can use compression), a protocol like SPDY is more likely to dominate the next generation of the Web than WebSockets:

Both protocols operate “outside” HTTP and use an upgrade mechanism to initiate. While WebSockets uses the HTTP connection header to request an upgrade, SPDY uses the Next Protocol Negotiation (proposed enhancement to the TLS specification). This mechanism engenders better backwards-compatibility across the web, allowing sites to support both next-generation web applications as well as traditional HTTP. [...] WebSockets does not use HTTP headers, SPDY does. This seemingly simple difference has an inversely proportional impact on supporting infrastructure.

In fact Lori believes that WebSockets looser ties to HTTP may make WebSockets "more trouble than its (sic) worth", at least for interactions in front of the fire-wall.

While both specifications will require gateway translation services until (if) they are fully adopted, WebSockets has a much harsher impact on the intervening infrastructure than does SPDY. WebSockets effectively blinds infrastructure. IDS, IPS, ADC, firewalls, anti-virus scanners – any service which relies upon HTTP headers to determine specific content type or location (URI) of the object being requested – is unable to inspect or validate requests due to its lack of HTTP headers. Now, SPDY doesn’t make it easy – HTTP request headers are compressed – but it doesn’t make it nearly as hard, because gzip is pretty well understood and even intermediate infrastructure can deflate and recompress with relative ease (and without needing special data, such as is the case with SSL/TLS and certificates).

Furthermore, because SPDY doesn't eliminate HTTP headers Lori posits that it can be more secure (assuming you agree with here original concerns with WebSockets security). And again SPDY should be easier to adopt with existing infrastructure:

SPDY can be enabled for an entire data center via the use of a single component: a SPDY gateway. WebSockets ostensibly requires the upgrade or replacement of many more infrastructure services and introduces risks that may be unacceptable to many organizations.

In conclusion, Lori believes that the different ways in which WebSockets and SPDY use HTTP headers means that for performance improvements within the Web SPDY is going to see much wider adoption. For her, the place for WebSockets is within the enterprise. However, given that much enterprise infrastructure is based on HTTP it may not be so clear cut there either.

Style

## Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

## Get the most out of the InfoQ experience.

### Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Netty: Using SPDY and HTTP transparently

Nice overview of the two protocols. Also check out an article on how to use SPDY and HTTP transparently with Netty.

Silly arguments

The difference is that every server and every client will support WebSockets.

Hasn't anybody paid attention to the power of ubiquity on the web?

Peace,

Cameron Purdy | Oracle
(Opinions expressed are my own.)

Do I have to choose one over another?

So far my understanding of WebSockets was as a tecnhnology complimentary to HTTP, for use cases that HTTP cannot handle very well like two-way syncronous communication. I can't see WebSockets as a replacement for regular HTTP use cases. And my understanding about SPDY was as simply an "enhanced HTTP" for those regular use cases. So I was wondering whether apps written for WebSockets could use either HTTP or SPDY, and if WebSockets had the same appeal for both protocols. But this article places SPDY and WebSockets as contenders for the same use cases. This got me confuzed. Am I completely misunderstanding both technologies?

Re: Silly arguments

You're right ,every server and client will support Websocket.However,is it enough to ensure
that websocket will always work ? Unfortunately, no. Should not forget the network infrastructure between the client and server !
So,solution such as socket.io or others supporting different transports including websocket and potentially SPDY are certainly a better solution instead of betting on one transport.

Claude Hussenet
Close

#### by

on

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

4 Discuss

Login to InfoQ to interact with what matters most to you.