This talk is non-normative.
Fuzzy Buzz-words: Real-time Interactive Collaborative Bidirectional
Coordinates
- Twitter: @VipulMathur
- LinkedIn: https://in.linkedin.com/in/VipulMathur
- Various forms of communication
- Web protocols
- Overview using plain HTTP
- RFC6202: Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP
- RFC6455: The WebSocket Protocol
- A quick demo of WebSockets
- Pointers to frameworks/ libraries
- Not the focus for #RFCsWeLove
- Unicast (1 to 1, simplex)
- e.g. letter (snail-mail)
- Multicast (1 to many, simplex)
- e.g. email
- Broadcast (1 to any, simplex)
- e.g. TV/ radio
- Request-response (1 to 1, half duplex)
- e.g. Q&A like in an interview
- Conversation (1 to 1, full duplex)
- e.g. chat between friends
- Omnidirectional (many to many)
- e.g. honking in Bangalore traffic :)
- Web protocols are mostly 4, increasingly 5
- Web applications are of all types, built on top of Web protocols
- request-response based
- plain-text headers, body
- pipelining (multiple requests without waiting for response on same TCP connection)
- persistent connections (multiple request-response pairs on same TCP connection)
- chunked transfer encoding (allow response to be broken into chunks, allow headers after body)
Approaches
- polling
- long poll
- streaming
- HTTP/2
Pointers
- BOSH
- Comet
- Bayou
- The client makes an initial request and then waits for a response.
- The server defers its response until an update is available or until a particular status or timeout has occurred.
- When an update is available, the server sends a complete response to the client.
- The client typically sends a new long poll request, either immediately upon receiving a response or after a pause to allow an acceptable latency period.
- Header overhead
- Unnecessary maximal latency (RTT)
- Frequent TCP connections (persistence helps)
- Resource overhead at client and server
- Unneeded buffering during higher loads
- Timeouts
- Caching
- The client makes an initial request and then waits for a response.
- The server defers the response to a poll request until an update is available, or until a particular status or timeout has occurred.
- Whenever an update is available, the server sends response back to the client.
- The data sent by the server does not terminate the request or the connection. The server returns to step 3.
- Network intermediaries (proxies, gateways) may buffer response.
- Unnecessary maximal latency (RTT)
- Client buffering
- Framing requriements not met by chunking (due to re-chunking)
- Proposed ~2009
- W3C Recommendation ~2015
- JavaScript EventSource API part of HTML5
- Built over HTTP streaming
- Good support by modern browsers
- Not supported by IE
- 'Under Consideration' for Edge 16
- Uses
Content-Type: text/event-stream
- Old ~2002
- Publish/ subscribe mechanism
- Push JavaScript snippets from server to client using HTTP streaming
- whitepaper
Historically, creating web applications that need bidirectional communication between a client and a server (e.g., instant messaging and gaming applications) has required an abuse of HTTP to poll the server for updates while sending upstream notifications as distinct HTTP calls
~ RFC6455, referring to RFC6202
(emphasis mine)
- Server resources: multiple TCP connections per client (up/ down)
- Protocol overhead: long header per HTTP message
- Client complexity: track pair of connections and state to one server
Use a single TCP connection for traffic in both directions.
- Low latency, high throughput
- Bi-directionaly communication
- Either client or server can send a message anytime
- Compatible
- WebSocket protocol
- Defined in RFC6455
- Status: Proposed Standard ~2011
- JavaScript WebSocket API
- Part of HTML5
- W3C Candidate Recommendation ~2012
Pointer
- Watch the excellent talk Inside WebSockets by Leah Hanson.
- Designed to work well with existing Web infrastructure
- Start with HTTP and 'upgrade' to WebSocket
- Uses ports 80 and 443 for WS and WSS
- Can tunnel through HTTP proxies via HTTP CONNECT
- Opening handshake
- Data exchange
- Closing handshake
- Text (UTF-8) and binary data
- Messages (note: no interleaving)
- Sub-protocols (e.g. chat)
- Extensions (e.g. deflate compression)
- https://www.websocket.org/echo.html
- Ctrl/Cmd + Shift + I
- Network > WS
Firefox WebSocket Monitor extension
- Extend developer tools with better WS support
- Visualize WS sessions
- https://github.com/firebug/websocket-monitor
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len | Extended payload length |
|I|S|S|S| (4) |A| (7) | (16/64) |
|N|V|V|V| |S| | (if payload len==126/127) |
| |1|2|3| |K| | |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
| Extended payload length continued, if payload len == 127 |
+ - - - - - - - - - - - - - - - +-------------------------------+
| |Masking-key, if MASK set to 1 |
+-------------------------------+-------------------------------+
| Masking-key (continued) | Payload Data |
+-------------------------------- - - - - - - - - - - - - - - - +
: Payload Data continued ... :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Payload Data continued ... |
+---------------------------------------------------------------+
- Masking
- Ping, Pong
- Behaviour with proxies and caches
- HTTP CONNECT
Socket.IO: Realtime JavaScript framework
- HTTP long-poll first
- Later upgrade to WebSocket if possible
- Handles disconnects
SockJS: WebSocket emulation
- WebSocket-like API even without WebSocket transport
- Focus on cross-browser compatibility
- Try native WebSocket first
- Automatically fall back to other transports (WS > streaming > polling)
- Multiple languages (JavaScript, Python, Java, Scala, Ruby, Go, ...)
- Twitter: @VipulMathur
- LinkedIn: https://in.linkedin.com/in/VipulMathur