Google SPDY vs WebSocket Protocol

Summer Greetings!

It's been while since I wrote my last blog. Obviously doing a startup is pretty intensive and is more if it's a HPC cloud platform! (commercial: check out www.ciespace.com for our product)

The HTTP protocol is the core of the web today and it touches millions of people all over the world, no matter what country/language on a daily basis. But it has got it's own problem as the original design was to transport simple text over the wide area network. Now it's over-used or abused and clearly needs a fix. The problem is the huge success of HTTP itself- you can't simply rip and replace something like HTTP. So how do you fix it? The simple answer is to complement with additions to fix the broken pieces.

The Google SPDY and WebSocket protocols are complimentary to each other and to HTTP. SPDY and WebSocket are are fixing 2 different problems in the HTTP protocol. There are some elements that may overlap each other but the core design is different.

Le's take a look at all 3 protocols - HTTP, SPDY and WebSocket.

1) HTTP Protocol
Typical web page needs 10's(even 100's) of resources(text, data, images, audio, video,etc) to construct and display to the end user. The client has to make separate HTTP request to server to get each resource. If the web page needs 25 resources then client has to make 25 separate HTTP requests over TCP connections. This is inefficient. There are some techniques like HTTP-pipelining available to multiplex requests but it's of limited use. This network latency creates a poor user experience.

2) Google SPDY Protocol
To fix the above problem of sending multiple requests to get multiple resources from the server, Google folks introduced a session level protocol called SPDY to group many requests in a single connection! So instead of making 10 different separate HTTP requests to server, SPDY can help to put all 10 HTTP requests in a single TCP connection. SPDY helps to reduce network latency by grouping HTTP requests.

Here is the diagram from Google:

In a nutshell, SPDY is a session level protocol. It's a layer below HTTP and above TCP. SPDY "groups HTTP" requests and sends over a single TCP connection. So it's clear that SPDY is a session level protocol for HTTP and enables grouping of HTTP requests.

3)WebSocket Protocol
HTTP is a request/response protocol. If you want to stream data (text & binary) bidirectionally over a single TCP connection with much less overhead, then the answer is WebSocket protocol. The WebSocket protocol starts with HTTP connection between client(browser) and server. Then the connection gets upgraded to WebSocket (technically it's getting downgraded to TCP level for browser/server communication) for bi-directional streaming of data. So it's clear that WebSocket is an extension to HTTP and enables streaming of data.

Here is the network diagram:

Summary
HTTP - Request/Response Protocol
SPDY - Session Level Protocol( to "group HTTP" requests to reduce network latency)
WebSocket - Extension to HTTP protocol for bi-directional communication between client and server

Many Google properties are already using SPDY and end users may not even know about it! Other leading web properties like Twitter, Facebook, etc are starting to support SPDY. Most modern web browsers (Chrome, Firefox, Safari, IE) are all supporting SPDY now.

It's the same with WebSocket. Many web properties including some wall street apps are usingWebSocket protocol. All the modern web browsers supports WebSocket now.

There is no need to explain about the mobile ecosystem adopting these 2 great protocols. They are on fire now!

Welcome SPDY and WebSocket! Good bye, HTTP!