SPDY and WebSockets

The Web is growing at an unprecedented rate, with the number of connected devices climbing rapidly towards an estimated 50 Billion by 2020 while end-users are expecting much more interactivity from their Web and mobile applications than ever before. As the industry attempts to move forward to address these challenges, innovative solutions span across all layers of our Web architecture. Both SPDY and WebSocket work together to provide the most efficient means of communication for our Living Web applications.

SPDY: Optimizing HTTP Request-Response

SPDY aims to optimize HTTP’s use of the transport layer such that many HTTP request-response conversations can flow in parallel between the same browser and Web server, changing the syntax to reduce the number of bytes used to represent each logical HTTP request-response. This is a positive step forward that has a number of technical advantages over direct use of HTTP/1.1.

While SPDY is a protocol that can be used instead of HTTP, it still represents a transparent optimization, so the logical programming model for application developers remains unchanged and the HTTP request-response interaction pattern remains in effect.

There is a significant challenge then to deploy such optimizations over the public Internet where intermediaries are not already aware of SPDY. This is precisely why SPDY leverages TLS to seamlessly navigate through HTTP intermediaries that already facilitate HTTPS end-to-end encrypted conversations.

During the initial TLS handshake, client and server negotiate the use of SPDY instead of HTTP using the TLS extension called Next-Protocol-Negotiation (NPN). Using negotiation in this way allows both clients (browsers) and servers to add support for SPDY independently, without introducing backwards incompatibility for clients and servers supporting HTTP/1.1 only.

Note that in more privately controlled environments, where Web intermediaries can be managed effectively, it would be possible to use SPDY in the clear over TCP as a direct replacement for HTTP, however systems are not typically deployed that way in practice.

SPDY does not aim to eliminate the benefits of Web intermediaries, such as shared Web content caching, but instead to support only authorized Web intermediaries. This effectively introduces a degree of control over Web intermediaries deployed in the public Internet.

WebSocket: Unlocking Event-Driven Web Architecture

WebSocket optimizes the interaction patterns used by Web application developers, such that they are no longer constrained to client-initiated request-response. The WebSocket handshake achieves this by upgrading a specific HTTP request-response to become a full-duplex, bidirectional channel, such that information can be sent in either direction from client-to-server or server-to-client at any time, without being constrained to request-response interaction patterns. The upgrade to a WebSocket connection unlocks the ability to deliver a truly event-driven or message-oriented architecture not only in the privately controlled data center, but also over the public Web to include browsers and mobile devices as first-class participants in that architecture.

Each WebSocket connection starts out as an HTTP request-response, making the end-user authentication and authorization of a WebSocket consistent with HTTP in general. For example, the HTML5 browser sandbox security model defines the trust boundary as an Origin which consists of a protocol scheme, such as http or https, a fully qualified host name, and a port (which may be implicit: port 80 for ws://, and port 443 for wss://). JavaScript code in the browser, including the HTML5 WebSocket API, is constrained to execute inside this sandbox. WebSocket addresses are URLs, such as ws://websocket.org/echo, making them ideally suited to integrate with the browser sandbox security model, unlike raw TCP support offered by browser plugin technologies like Flash, Java and Silverlight.

WebSocket over SPDY: A Powerful Combination

Given the HTTP-centric design of the WebSocket handshake, it fits perfectly within the HTTP-centric focus of running many HTTP request-response conversations in parallel over SPDY. As defined in SPDY version 3, WebSockets can flow in parallel over the same SPDY connection, offering a clean separation of responsibility between the layers. In fact, traditional HTTP request-response conversations and WebSocket connections to the same target Origin can flow over the same SPDY connection.

The SPDY connection itself acts as a secure transport, having established machine-to-machine trust between the browser and the server. Each HTTP request-response, whether or not it upgrades to use WebSocket, establishes end-user trust such that it can act on behalf of the person using the Web application. This separation of security roles is a fundamental difference between SPDY and WebSocket that allows them to complement each other’s strengths without competing.

WebSockets over SPDY represents a significant leap forward for the foundation of our Web architecture. SPDY improves performance, while WebSocket enables bi-directional continuous communication between the client and the server. The two together are giving us the ability to deliver more compelling Living Web applications than ever before, without breaking the bank at the data center.

This entry was posted in SPDY, TLS, WebSocket. Bookmark the permalink.

2 Responses to SPDY and WebSockets

  1. jonasjacobi says:

    Here is another blog discussing the complimentary nature of SPDY and WebSocket – https://blogs.akamai.com/2012/07/spdy-and-websocket-support-at-akamai.html

  2. SPDY reinvents framing already defined in WebSocket and will need to invent multiplexing which WS has already at draft stage. See: http://tools.ietf.org/agenda/84/slides/slides-84-hybi-0.pdf
    You can run SPDY over WS reinventing less. Also: WS does not require TLS, which is great for limited devices .. think of Arduino: it runs WS on 8-Bit CPU / 4KB RAM. It won’t run TLS.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s