Enterprise Application PerformanceServer Push Technologies - WebSockets

Solution Architect - Experts Team

Tito Moreira

Performance Hurdles

• Application code○Too many accesses to database○Poor client-side programming (Client-side polling, JS, CSS, HTML)

• Infrastructure○Database○Network

Long polling (pull)

Pull - Long Polling using Web requests

Since HTTP is stateless, the Session and other data might need to be read from the database

Pull vs Push technologies

Information about the connection (IP, port and identifier of the recipient) is stored in memory(stateful)

WebSockets

A brief History of WebSockets...

1973TCP/IP design

1969ARPANET

1989WWW, HTML, HTTP created by CERN to reference documents in the Internet

20091st draft of WebSocket protocol (hixie)

2010Chrome, Safari, Firefox, Opera adds support for WebSockets

2011 DecWebSocket protocol gets Internet Standard classification.RFC published

1997HTTP/1.1RFC published

2015HTTP/2.0 RFC published(TCP connection reuse)

Time

WebSocket (RFC 6455) Browser support

WebSockets

• WebSocket is a protocol ○Allows two-way communication between a client and a

server over TCP/IP○The goal of WebSockets is to provide a mechanism to

browser applications that need two-way communication with servers to avoid opening multiple HTTP connections or using long polling (AJAX, iframes, etc)

HTTP requests vs WebSockets

Client Server

Request

Request

Response

Response

Client Server

Handshake

Bi-directional messages

Acknowledgement

Connection end

Connection Lifecycle (TCP/IP)

HTTP/REST requests

WebSockets

For requests not sent in the same TCP connection

ping! (0x09)pong!(0xA)

close (0x8)

WebSocket vs standard HTTP requests

Source: http://blog.arungupta.me/rest-vs-websocket-comparison-benchmarks/

• Constant payload 1KB, increasing number of messages

WebSocket vs standard HTTP requests

Source: http://blog.arungupta.me/rest-vs-websocket-comparison-benchmarks/

• Performance with ≠ payload size for constant number of messages (1000)

WebSockets

• WebSocket handshake is initiated from an HTTP request

• Sub-protocols can be negotiated

When to use Server Push technologies (WebSockets) ?

Recommended uses for WebSockets

• To implement Functional Requirements○ When Web Apps need server data that is constantly changing

■ High volatile data change events (Tickers, Price updates, Real Time data, etc)■ Results from background processing tasks■ User notifications■ Communication between Users (collaborative scenarios)

○ Present “small” bits of information to Users as soon it is available

■ Auction prices, Sports updates, tickers, location based data, etc

Recommended uses for WebSockets

• To address Architectural restrictions○ To get around the infamous 6 connections per host limit.○ To allow Browsers to access local resources (native)

■ Browser ActiveX/Java plugin migrations■ Installation of a local service (with a WebSocket server) for providing

Biometric authorization or other events

How to integrate WebSockets with OutSystems?

For Cloud based WebSocket services

• Pick a WebSocket Cloud service that exposes a server-side API.

■ The Server-side API allows OutSystems Apps to push data• Usually provide authorization (token based) and

transport security (TLS/SSL) ■ Secure WebSockets (WSS)

• Choose a Cloud Service that implements fallback mechanisms

■ The Client-side script should have fallback to older (more mainstream) technologies

• Pick the Cloud service that has the lower latency ■ For your target Users ■ For the OS Infrastructure

Integration with OutSystems Cloud Pusher.com service (example)

Client(Browser)

Standard AJAX or Page view request (HTTP 1.1)

Front End

Load Balancer

OutSystems FrontEnd Servers

WebSocketServer

(pusher.com)

Pusher.com usesWS/WSS protocol To push data to clients

Client(Browser)

By using Pusher server-side REST API, a background process can publish data to a Client or group of Clients

Pusher client scriptClient

(Browser)

Pusher client scriptClient

(Browser)

Pusher client script

HTTP Web request

WebSocket protocol

REST API request

Source: http://www.asp.net/signalr/overview/performance/scaleout-in-signalr

Known WebSocket Cloud services

• Pusher• PubNub• Fanout (also works as Reverse Proxy)• Google App Engine with Channel API• Hydna• Firebase + Fire# (server-side C# API)• Azure Web Apps support WebSockets

...

For self-hosted WebSocket server

• The WebSocket cluster should be in a dedicated infrastructure ○ Don’t install WebSockets server software in the OS FrontEnd

Servers○ It has different resource needs (scales differently than OS FEs)○ The WebSocket server maintenance and support tasks won’t

affect OS servers and vice-versa○ Can be migrated to another environment (3rd Party Cloud

services)• Use a WebSocket server that exposes a REST service

○ OS apps will call this service to push data to browser clients• Implement authorization (tokens or API keys)

○ WebSocket servers that are exposed to the public, should check for an API Key or Token that is sent by the Client to verify authorized access.

Integration with OutSystemsSelf-hosted HA SignalR (example)

Client(Browser)

A background process can call an ASP.NET Web API REST service to publish data to a Client or group of Clients

Standard AJAX or Page view requests (HTTP 1.1)WS/WSS protocol

ASP.NET SignalR 2.0WebSocket Servers

SQL Server Backplane

Load Balancer

Source: http://www.asp.net/signalr/overview/performance/scaleout-in-signalr

OutSystems FrontEnd Servers

Client(Browser)

SignalR client scriptClient

(Browser)

SignalR client script

HTTP Web request

WebSocket protocol

REST API request

SQL Query

Known self-hosted WebSocket servers

• NodeJS ○Socket.io, sockJS, FAYE, etc

• ASP.NET SignalR (>= Windows 2012 R2)• IISNode (Yes! Node inside IIS on a ≠ App pool)• Jetty (Java)• websocketd (Linux only)• SuperSocket (library for custom server in C#)

...

WebSockets considerations

• Compatibility problems with HTTP proxies○ The WebSocket HTTP Upgrade (normally used for HTTP/SSL) request can be dropped by some

(old) Proxies, making it impossible to establish a connection.• Security (to prevent man-in-the-middle) for

WebSockets○ Use TLS/SSL for the Web Applications. Most WebSocket frameworks will use the wss:// (TLS/SSL)

for the WebSocket connection too.• DoS

○ Most Browsers impose a limit between 200-3000 WebSockets. A malicious Site can exhaust the max connections of the Browser. It’s also possible for a client to DoS a server.

• Authorization/Authentication○ The WebSocket protocol doesn’t handle authorization or authentication. ○ WebSocket opened from a page with auth doesn’t “automatically” receive any sort of auth

WebSockets considerations (cont.)

• Some WebSocket servers don’t allow cross site connections although they can be configured (CORS)

○ SignalR (by default) checks Origin header to verify if the Script origin is the same • Check that you are effectively using WebSockets

instead of a Pull fallback mechanism○ Most frameworks will fallback quietly to Long Polling if the Browser or Server (SignalR)

don’t support the WebSocket protocol ○ Use Developer Browser tools to check if

WS protocol is effectively used• Standard not implemented the same

way or not supported by all browsers○ That’s why using an abstraction client framework (with fallback mechanism) is a good idea!

WebSockets in Action!(demo)

We’ll be back in 5 min to answeryour questions

Thank you!