2. $ whoami
David Lindkvist
kontain.com/david-lindkvist
twitter.com/ffdead
Application Developer @F_i
Web development is my passion!
Drummer
myspace.com/vildhjarta
myspace.com/terminalfunction
2
3. Agenda
Why do we need WebSockets?
What is it?
How does it work?
When can we use it?
3
5. Why?
Today’s web apps demand reliable event-driven
communications
“Real-time” (minimal latency)
Full duplex
Examples:
Social networking
Online games
Collaborative platforms
Financial applications
etc...
5
6. Why? Problems with HTTP...
It’s hard to achieve real-time apps, primarily due to the
limitations of HTTP
HTTP is half-duplex (traffic flows in only one direction
at a time)
HTTP adds latency and message overhead
6
7. Why? Simulate real-time?
Polling (AJAX)
Poll server for updates, wait at client
Long polling (Comet)
Poll server for updates, wait at the server; uses two
connections and requires unnecessary complexity
Used in Ajax applications to simulate real-time
Leads to poor resource utilization...
7
9. Why? Long Polling
#$%&'($))*%&+,-./*01.02-1
(picture from Kaazing)
!"#$"%$!$
3+!""4+5 6778*%&+9$-:$-70*$%
!"#$"%$!$ !"
!"
9
10. Why? HTTP req/res overhead
GET /PollingStock//PollingStock HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5)
Gecko/20091102 Firefox/3.5.5
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us
Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300 691 chars
Connection: keep-alive
Referer: http://localhost:8080/PollingStock/
Cookie: showInheritedConstant=false;
showInheritedProtectedConstant=false; showInheritedProperty=false;
showInheritedProtectedProperty=false; showInheritedMethod=false;
showInheritedProtectedMethod=false; showInheritedEvent=false; showInheritedStyle=false;
showInheritedEffect=false
HTTP/1.x 200 OK
X-Powered-By: Servlet/2.5 Server: Sun Java System Application Server 9.1_02
Content-Type: text/html;charset=UTF-8
Content-Length: 321
Date: Sat, 07 Nov 2009 00:32:46 GMT
Total 871 chars
(example from Kaazing)
10
11. Why? Header traffic analysis
Example network throughput for Polling HTTP req/resp
headers:
Use case A: 10,000 clients polling every 60 seconds
Network throughput is (871 x 10,000)/60 = 145,166 bytes =
1,161,328 bits per second (1.1 Mbps)
Use case B: 10,000 clients polling every second
Network throughput is (871 x 10,000)/1 = 8,710,000 bytes =
69,680,000 bits per second (66 Mbps)
Use case C: 100,000 clients polling every 10 seconds
Network throughput is (871 x 100,000)/10 = 8,710,000 bytes =
69,680,000 bits per second (66 Mbps)
(example statistics from Kaazing)
11
13. What is a WebSocket?
W3C/IETF Standard
Uses the WebSocket protocol instead of HTTP
True full-duplex communication channel
Both UTF-8 strings and binary frames can be sent in any
direction at the same time
It’s not a raw TCP socket
13
14. What is a WebSocket?
Connection established by “upgrading” from HTTP to
WebSocket protocol
Runs via port 80/443 - Proxy/Firewall friendly
HTTP-compatible handshake
Integrates with Cookie based authentication
WebSockets and Secure WebSockets
ws://
wss://
14
15. What? Upgrade handshake
// browser request to the server
GET /demo HTTP/1.1
Upgrade: WebSocket
Connection: Upgrade
Host: example.com
Origin: http://example.com
WebSocket-Protocol: sample
// server response
HTTP/1.1 101 Web Socket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
WebSocket-Origin: http://example.com
WebSocket-Location: ws://example.com/demo
WebSocket-Protocol: sample
15
16. What? Reduces Network Traffic
Each message (“frame”) has only 2 bytes of overhead
No latency from establishing new TCP connections for
each HTTP message
No polling overhead - only sends messages when
there is something to send
16
17. What? Header traffic analysis
Example network throughput for WebSocket req/res
headers:
Use case A: 10,000 frames every 60 seconds
Network throughput is (2 x 10,000)/60 = 333 bytes = 2,664 bits
per second (2.6 Kbps) [was 1.1 Mbps]
Use case B: 10,000 frames every second
Network throughput is (2 x 100,000)/1 = 20,000 bytes = 160,000
bits per second (156 Kbps) [was 66 Mbps]
Use case C: 100,000 frames every 10 seconds:
Network throughput is (2 x 100,000)/10 = 20,000 bytes = 160,000
bits per second (156 Kbps) [was 66 Mbps]
(example statistics from Kaazing)
17
18. What? Overheard
"Reducing kilobytes of data to 2 bytes...and reducing
latency from 150ms to 50ms is far more than marginal.
In fact, these two factors alone are enough to make
WebSocket seriously interesting to Google.“
- Ian Hickson (Google, HTML5 spec lead)
18
20. How? The WebSocket interface
[Constructor(in DOMString url, in optional DOMString protocol)]
interface WebSocket {
readonly attribute DOMString URL;
// ready state
const unsigned short CONNECTING = 0;
const unsigned short OPEN = 1;
const unsigned short CLOSING = 2;
const unsigned short CLOSED = 3;
readonly attribute unsigned short readyState;
readonly attribute unsigned long bufferedAmount;
// networking
attribute Function onopen;
attribute Function onmessage;
attribute Function onerror;
attribute Function onclose;
boolean send(in DOMString data);
void close();
};
WebSocket implements EventTarget;
20
21. How? The Javascript client
connect: function () {
try {
this.ws = new WebSocket(’ws://www.example.com’);
this.ws.onopen = function (event) {/*...*/};
this.ws.onclose = function (event) {/*...*/};
this.ws.onmessage = messageListener;
}
catch(exception) {}
},
messageListener: function (event) {
alert(’New message: ’ + event.data)
},
send: function (message) {
if (this.ws) {
this.ws.send(message);
}
},
21
22. How? The server
Server implementations (mostly experimental):
Kaazing WebSocket Gateway (production since april 2009)
phpwebsockets
web-socket-ruby
mod_pywebsocket
JWebSocket
Jetty WebSocketServlet
and many more...
22
23. How? Jetty server example
public class MyServlet extends HttpServlet implements Servlet
{
// trigger on HTTP GET request
public void doGet(HttpServletRequest req, HttpServletResponse res) {}
// trigger on HTTP POST request
public void doPost(HttpServletRequest req, HttpServletResponse res) {}
// doWebSocket() ???
}
23
24. How? Jetty server example
public class ChatServiceServlet extends WebSocketServlet implements Servlet
{
public void doGet(HttpServletRequest req, HttpServletResponse res) {}
public void doPost(HttpServletRequest req, HttpServletResponse res) {}
// trigger on request to upgrade to WebSocket connection
protected WebSocket doWebSocketConnect(HttpServletRequest req, String arg) {
return new ChatWebSocket();
}
// shared resource - needs to be thread safe!
Set<ChatWebSocket> clients = new CopyOnWriteArraySet<ChatWebSocket>();
class ChatWebSocket implements WebSocket {
/* impl on next slide... */
}
}
24
25. How? Jetty server example
class ChatWebSocket implements WebSocket {
Outbound outbound;
public void onConnect(Outbound outbound) {
this.outbound = outbound;
clients.add(this);
}
public void onMessage(byte frame, String data) {
for (ChatWebSocket socket : clients) {
try {
socket.outbound.sendMessage(frame, data);
}
catch(IOException e) {}
}
}
public void onDisconnect() {
clients.remove(this);
}
}
25
26. How? It’s not a silver bullet
How should we handle the “close” event?
Application must be prepared to reopen connection if
close event was triggered unexpectedly
Idle timeout
Network errors
26
27. How? It’s not a silver bullet
Keep-alives
Sending keep-alive messages to prevent closing due to an idle
timeout
No timeout discovery available on the WebSocket
Keep-alives don’t avoid the need for handling “close” events
WiFi connections and mobile devices
27
28. How? It’s not a silver bullet
Queues
Buffer messages that failed to send due to a transient network
problem
Resend queue when connection is restored
Important for both server and client
28
29. How? It’s not a silver bullet
Timeouts
Not all network problems are transient
Can’t allow queues to grow for ever
Applications need a timeout when user is considered to be
disconnected
Need to implement an explicit close message for application to
distinguish between network failures and an orderly close
29
30. How? It’s not a silver bullet
Message Retries
Even with queues we can’t know for sure messages are
delivered due to race condition
If close event is triggered soon after a message was sent?
For quality of service to be guaranteed an acknowledge
message would have to be sent for each message
Ideally a future version of WebSockets would support an
orderly close event
30
31. How? It’s not a silver bullet
onclose handing, keep-alives, message queues,
timeouts and retries, introduce more problems:
If server goes down client will loop trying to reconnect
Needs a retry backoff algorithm to reduce retries over time
Message size can cause connection to die if it exceeds some
resource limit on client or server
Looks like a transient network error...
Connection is restored and retries to send same message from
queue...
Infinite loop!
31
34. When? Browser support
Status of native WebSocket support for other browsers
(2010-04-11):
Firefox - targeted for the v3.7 release but not yet in 3.7a4pre
Safari - announced for 4.x but no target date yet
Opera - 10.x already 95% HTML5 compatible but WebSockets
missing
IE 8.x - 9.x unknown
(reference: jWebSocket project)
34
35. When?
Graceful degradation for the next ~10 years....
Realtime apps:
Java Applet TCP Socket
Flash XMLSockets over TCP
Long polling over HTTP
Not so realtime apps:
Polling using periodical pulls over HTTP
35
36. When?
Providing fallbacks mean more work.
More works sucks..
Solution: Look for a client library which implements the
WebSocket interface!
Kaazing
jWebSocket
Users will be able to take advantage of true WebSockets when
their browser supports it
36
37. When?
Or... roll your own!
Introducing the Graceful WebSocket:
A jQuery plugin implementing the WebSocket interface
One interface = one implementation
Uses the native WebSocket if available
Automatic fallback on HTTP polling
37
38. Get involved?
Visit the Graceful WebSocket project over at Google
Code:
http://code.google.com/p/jquery-graceful-websocket/
38
39. Summary
Allows us to write real-time, event driven applications
Better resource utilization, less latency, less network
overhead
Browser support so far is poor
Specification is not finalized
39
40. References?
W3C The WebSocket API
HTML5 Communications - Frank Greco (Kaazing)
jfokus 2010
http://en.wikipedia.org/wiki/Web_Sockets
Greg Wilkins Jetty WebSocket Server
Greg Wilkins Websocket Chat
http://jwebsocket.org/
40