SPDY versus WebSockets?
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.
Netty: Using SPDY and HTTP transparently
Hasn't anybody paid attention to the power of ubiquity on the web?
Cameron Purdy | Oracle
(Opinions expressed are my own.)
Do I have to choose one over another?
Re: Silly arguments
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.
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015