The Websocket Protocol: Ietf 80 Hybi WG Takeshi Yoshino Tyoshino at Google Dot Com
The Websocket Protocol: Ietf 80 Hybi WG Takeshi Yoshino Tyoshino at Google Dot Com
The Websocket Protocol: Ietf 80 Hybi WG Takeshi Yoshino Tyoshino at Google Dot Com
IETF 80 HyBi WG
Takeshi Yoshino
tyoshino at google dot com
Background
• Evolution of web apps
– Dynamic and real-time application
– Webmail, Chat, word processing, etc.
• HTTP is not designed for web apps
– Large overhead
– Hanging-GET is necessary for real-time server push
WebSocket is (1)
• New protocol over TCP
– Opening handshake
• HTTP-esque request and response
– Newly defined WebSocket frame
• New API for JavaScript
var ws = new WebSocket("ws://example.com/foobar");
ws.onmessage = function(evt) { /* some code */ }
ws.send("Hello World");
…
WebSocket is (2)
• Intended to replace hanging-GET based
bidirectional channel
– Two XMLHttpRequest One WebSocket
• Full duplex
• Smaller overhead
• Fewer TCP connection
• Simpler API
Other Requirements
• Coexist with HTTP on the same port
– Use 80/443 which are rarely blocked
• Work with HTTP infrastructure
– Proxy and firewall
• Allow cross origin connection
– http://example.com/foo.js establish WebSocket to
ws://example.org/chat
• Fit JavaScript programming model
Security Concern
• Cross protocol attack
– Abuse of WebSocket on browser
• By malicious JavaScript
• To attack HTTP server, cache, …
– Abuse of XMLHttpRequest
• To attack WebSocket server
• Port scanning
Protocol Overview
• User-agent establishes TCP
– Order, reliable transmission, congestion control
are guaranteed by TCP
• Opening handshake
• Exchange WebSocket frames
• Closing handshake
Opening Handshake (1)
Example
• Client GET /chat HTTP/1.1
Host: server.example.com
sends Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Origin: http://example.com
• Example
– 5 0x5
– 256 0x7E 0x0100
– 65536 0x7F 0x0000000000010000
Framing (6)
Opcodes
• 0x0 Continuation frame
• 0x1 Connection close
• 0x2 Ping
• 0x3 Pong
• 0x4 Text frame
• 0x5 Binary frame
• 0x7-0xF Reserved
Framing (7)
Room for Extension
• 4 reserved bits in header
– RSV1, RSV2, RSV3, RSV4
• 9 undefined opcodes 0x7-0xf
• Extension data field
Framing – Open Issue
• Single opcode for control frames or
Multiple opcodes for each control frames
– Single control opcode
1 leading octet of payload is control type
• Easy to tell intermediaries the frame cannot be
fragmented
– Define the range of control opcodes
– Multiple opcodes for each control type
• How to specify extension field length
Ping and Pong
• Built-in ping
– For keep alive, health check, …
Masked data
Frame Masking – Open Issue
• Mask frame or mask payload
– In-frame masking is less secure?
– Making whole frame is bad for intermediaries?
• Mask only client-to-server or both direction
– Debugging is easier if symmetric
• Mask extension field or not
Fragmentation (1)
• Enable sending part of message separately
– Useful for dynamically generated contents
– Flush partial data to vacate buffer
• Similar concept as HTTP chunked encoding
• Planned to be used for multiplexing
• Example
– For message "abcdefg..."
– Frame1
• !FIN, opcode=<original opcode>, payload=abc...
– Frame2
• !FIN, opcode=CONTINUATION, payload=ijk...
– Frame3
• FIN, opcode=CONTINUATION, payload=stu...
Extension (1)
• Negotiate on opening handshake
• Modify payload or even whole frame
• Attach some information
– as RSV1-4, new opcode or
per-frame extension data field
Extension (2)
Negotiation Example
Sec-WebSocket-Extensions: deflate-stream
Sec-WebSocket-Extensions: mux; max-channels=4;
flow-control, deflate-stream
Sec-WebSocket-Extensions: x-private-extension
TCP FIN
• A peer can close TCP once
TCP FIN
both received and sent close
Alice Bob
Closing Handshake (3)
• What this assures for Alice
– Alice received all data sent from Bob
• wasClean parameter of onclose handler
– It's safe for Alice to close TCP connection
• No more data coming from Bob No RST hazard