Web Real-time Communications
-
Upload
alexei-skachykhin -
Category
Technology
-
view
505 -
download
1
description
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