Web Real-time Communications

Post on 11-May-2015

503 views 1 download

Tags:

description

This presentation aggregates common approaches of real-time client-server communications provided by Web Standards. It focuses on comparison of different techniques like polling, comet, Web Sockets, Server-Sent Events.

Transcript of Web Real-time Communications

Real-time CommunicationClient-Server

Alexei Skachykhin – Software EngineeriTechArt, 2014

Pull model

Xhr

Xhr Xhr

Real-timeUse cases

Live feeds

Real-timeUse cases

Multiplayer games

Real-timeUse cases

Live sync applications

Pull & push model

Xhr

Xhr Xhr

?

? ?

Real-timeWorkarounds

PollingLong

PollingHTTP

Streaming

Comet

Polling

Periodic XHR requests aimed to simulate push model

PollingInteraction diagram

Server

Client

PollingRequest & response

POST http://q90.queuev4.vk.com/im705 HTTP/1.1Accept: */*X-Requested-With: XMLHttpRequest

HTTP/1.1 200 OKServer: nginx/1.2.4Date: Tue, 21 Jan 2014 23:22:31 GMTContent-Type: text/javascript; charset=UTF-8Content-Length: 180Connection: keep-alivePragma: no-cacheCache-Control: no-store

[{"ts":"1103498799","events":["14<!>like_post<!>-30602036_99896<!>2802<!>738<!>261"]}]

DemoPolling

PollingProtocol overhead

Actual overhead of HTTP headers in case of VK.com is 1.4K

PollingNetwork throughput

Overhead, K

Polling interval, s

Number of clients

Throughput, Mbps

1.4 60 10000 1.1

1.4 1 10000 66

1.4 10 100000 66

(example statistics for vk.com)

PollingCharacteristics

- High latency- High server workload- High protocol overhead (HTTP headers)- Potential cause of high battery drain

+ High degree of support across different browsers

Comet

Periodic long-lived XHR requests aimed to simulate push model

CometTypes

Long polling

HTTP Streaming

Long PollingInteraction diagram

Server

Client

DemoLong Polling

Long PollingCharacteristics

- Tricky server configuration- Possible difficulties with intermediaries- Can cause stoppage of all requests until long polling returns

+ Reduced latency+ Reduced server workload+ Reduced protocol overhead (HTTP headers)

HTTP Streaming

Comet technique similar to long polling but instead of closing connection,

infinitely pushing data into it

HTTP StreamingInteraction diagram

Server

Client

HTTP StreamingRequest & response

GET /events HTTP/1.1Accept: application/json

HTTP/1.1 200 OKContent-Type: multipart/x-mixed-replace;boundary=separatorTransfer-Encoding: chunked

--separator { “id": 1, "x": 137, "y": 21 }

--separator{ “id": 2, "x": 18, "y": 115 }

--separator{ “id": 7, "x": 99, "y": 34 }

Invented in 1994 by Netscape

DemoHTTP Streaming

HTTP StreamingBrowser compatibility

10

HTTP StreamingCharacteristics

- Patchy browser support (Issue 249132)- Tricky server configuration- Possible difficulties with intermediaries- Can cause stoppage of all requests until long polling returns

+ Reduced latency+ Reduced server workload+ Reduced protocol overhead (HTTP headers)

HTML5Pave the Cowpaths

When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something

new.

Server-Sent Events

Comet mechanism build directly into Web browser

www.w3.org/TR/eventsource

Server-Sent EventsAPI

var source = new EventSource(‘/events');

source.addEventListener('message', function (e) { console.log(e.data);});

source.addEventListener('open', function (e) { // Connection was opened.});

source.addEventListener('error', function (e) { if (e.readyState == EventSource.CLOSED) { // Connection was closed. }});

Server-Sent EventsRequest & response

GET /events HTTP/1.1Accept: text/event-stream

HTTP/1.1 200 OKContent-Type: text/event-stream

id: 12345data: GOOGdata: 556

retry: 10000data: hello world

data: {"msg": "First message"}event: userlogon

DemoServer-Sent Events

Server-sent EventsBrowser compatibility

caniuse.com/#feat=eventsource

5.0

Server-sent EventsAdvantages

+ Complexity is hidden from developer+ Built-in reconnect+ Standardized an agreed upon implementation

Pull & push model

Xhr

Xhr Xhr

Xhr

XhrXhr

Pull & push modelFlaws

- HTTP one request – one resource semantics- Semi-duplex communications- Some degree of non-networking latency- Protocol overhead (HTTP headers)

Full-duplex model

?

? ?

Web Sockets

Low-latency bi-directional client-server communication technology

www.w3.org/TR/websockets

Web Sockets

Full-duplex socket connection

Web Socket protocol v13 (RFC 6455) instead of HTTP

Uses HTTP for connection establishment

Web SocketsConnection

Runs via port 80/443 to simplify firewalls traversal

Pseudo schemes: ws, wss

Connection established by “upgrading” from HTTP to WebSocket protocol

var connection = new WebSocket('ws://html5rocks.websocket.org/echo');

Web SocketsConnection handshake

GET /chat HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Origin: http://example.com Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 13

Client sends GET or CONNECT request to Web Socket endpoint

Upgrade header indicates willing to upgrade connection from HTTP to Web Socket

Web SocketsConnection handshake

HTTP/1.1 101 Switching ProtocolsUpgrade: websocketConnection: UpgradeSec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

Server responds with 101 status code and connection upgrade header

From now on Web Socket protocol will be used instead of HTTP

Web SocketsAPI

var connection = new WebSocket('ws://html5rocks.websocket.org/echo');

// When the connection is open, send some data to the server. connection.onopen = function () { // Send the message 'Ping' to the server. connection.send('Ping');};

// Log errorsconnection.onerror = function (error) { // Log messages from the server console.log('WebSocket Error ' + error);};

connection.onmessage = function (e) { console.log('Server: ' + e.data);};

DemoWeb Sockets

Web SocketsServer compatibility

IIS8 + Native Web Sockets NodeJS + Socket.io Apache + apache-websocket

Web SocketsBrowser compatibility

caniuse.com/#feat=websockets

6.0

10

Web SocketsCharacteristics

- Multiple versions of protocol to support - Possible difficulties with intermediaries- Requires up-to-date browser

+ Low latency+ Low server workload+ Low protocol overhead+ Full-duplex

What to choose?

Simplicity Efficiency

PollingComet /

Server-Sent Events

Web Sockets WebRTC

Bleeding Edge

All in one

It is possible to abstract communication details away from developer into libraries

DemoSocket IO & SignalR

Caveats

1. Some network topologies may prohibit long-lived connections

2. Intermediaries are still barely aware of Web Sockets

3. Long-lived connections are subject to spontaneous shutdown

4. Long-lived connections can prevent some browsers from spanning parallel HTTP requests

5. Web Sockets spec has bunch of legacy versions

Links

Code samples:https://github.com/alexeiskachykhin/web-platform-playground

LinksSocket IO: http://socket.io/

SignalR: http://signalr.net/

Live Sync Demos: http://www.frozenmountain.com/websync/demos/

Web Socket – TCP bridge: http://artemyankov.com/tcp-client-for-browsers/

Server-Sent Events: http://www.html5rocks.com/en/tutorials/eventsource/basics/

Web Sockets: http://www.websocket.org/

Thank you!Forward your questions

to alexei.skachykhin@live.com