WebSockets allow for full-duplex communication between clients and servers for real-time web applications. The document discusses how HTTP limitations led to the development of WebSockets and covers considerations for designing real-time applications using WebSockets such as reliability, testing challenges, and integrating with other technologies. WebSockets are best suited for real-time aspects of applications while REST can be used for non-real-time functionality.

1. WebSockets
Messaging For Real-time Web Applications.
Tiju Titus John
Oct 21, 2016

2. Agenda
 Real-time web applications
 HTTP Challenges
 WebSocket
 Design Considerations
 Tooling
 Testing
 Alternate Considerations
 Summary
 Q&A

3. Real-time Web Applications
 Timely nature to the data /event
 Timely nature to the user experience
 Bit-Directional Message
 Peer-2-Peer
 Users to Systems
 Asynchronous
 Frequent and Chatty
Examples
• Web Telephony
• Web Conferencing
• Collaborative Rooms / Channels
• IM / Chats /
• Games
• Real-time Dashboards

4. HTTP wasn’t enough!
 Request-Response
 High amount of data in Headers
 Http 1.1 Keep Alive provide persistent connections.
 One Request at a Time  HTTP Pipelining (HOL Blocking –
problem)
 Bi-directional approaches
 Call back URLS (Works in server to server integration with
limitations)
 Polling and Long Polling
 Http Streaming
 SSE – Server Sent Events

5. Http Upgrade - WebSockets
 RFC6455 – Dec 2011
 Allows full duplex communication.
 Wide support of tools and browsers in short time.
 ws:// and wss://
 Post handshake is made each party can send message as
frames
 W3C WebSocket API
 Support Binary and Text Data
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key:
dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Version: 13
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept:
s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

6. Design Considerations
 Use Higher abstraction API’s
 Socket.io
 SockJS
 SDK vs Messages
 JS SDK (Twilio) (Good only browser clients)
 WebSocket Message API (Slack) – Interface definition's are bit tricky.
 Message Reliability – Application need to built it.
 Only a Delivery Mechanism – No Reliable delivery
 At-most-once.
 Using Multiple WS Channels.
 Big messages can delay other events as messages are delivered in order.
 Subscribe to only necessary data.
 Non Functional Aspects.
 Authentication / Authorization / Message-Auditing
 Webserver logs may not work.

7. Tool Support
 Chrome Developer console
 WebSocket Monitor – Firefox add-ons
 Non – Blocking io based libs
 Message bus Gateways
 Spring STOMP broker
 Database Gateways
 Caching and CDN’s

8. Testing Challenges
 Lack of support of the shelf testing tools.
 Use Asynchronous Testing Framework
 Mocha / should.js
 Perf Test – Jmeter Websocket sampler

9. REST Replacement?
 Non Real-time apps and services REST or Web Service
 Standardized / Templated frameworks
 Use mix of Both REST & Web Socket
 Non real-time / stateless with REST
 Real-time aspects with Web Sockets
 Scale the real-time and non-real-time services separately and differently.

10. Server side Integrations ?
 Using as an integration Framework between services.
 Not an Ideal one due lack of reliability
 Message bus / Message Brokers might be best.
 Can use to traverse via firewall ( Can use it as Message Bus gateways)

11. Similar Technologies
HTTP 2 Server Push
 Send multiple Response for single
Request
 Good for sending images/CSS/JS
WebRTC
 Focus on A/V, but also has data
channel
 Focus on P2P, but one peer be a
server.
 Data Streams are SCTP
 NAT and Firewall problems
 Good for rich content streams
 Many WebRTC solutions uses
WebSockets for signaling.

12. Summary
 Technology for Real-time web applications.
 Not a replacement for REST / Web Services
 Not ideal for service integrations.