HyBi Working Group J. Tamplin
Internet-Draft T. Yoshino
Intended status: Standards Track Google, Inc.
Expires: April 23, 2012 October 21, 2011
A Mulplexing Extension for WebSockets
draft-tamplin-hybi-google-mux-00
Abstract
The WebSocket Protocol [WS] requires a new transport connection for
every WebSocket connection. This presents a scalability problem when
many clients connect to the same server, and is made worse by having
multiple clients running in different tabs of the same user agent.
This extension provides a way for separate logical WebSocket
connections to share an underlying transport connection.
Please send feedback to the hybi@ietf.org mailing list.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 23, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Tamplin & Yoshino Expires April 23, 2012 [Page 1]
Internet-Draft A Mulplexing Extension for WebSockets October 2011
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Interaction with other Extensions / Framing Mechanisms . . . . 4
3. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Multiplex Control Frames . . . . . . . . . . . . . . . . . . . 8
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 12
9. Buffering . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
12. Nesting . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
13. Security Considerations . . . . . . . . . . . . . . . . . . . 17
14. Normative References . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Tamplin & Yoshino Expires April 23, 2012 [Page 2]
Internet-Draft A Mulplexing Extension for WebSockets October 2011
1. Overview
This document describes a MUX extension to the WebSocket protocol.
Initially, it will be identified by the private-use token "x-google-
mux". A client that supports this extension will advertise support
for it in the initial handshake using the "Sec-WebSocket-Extensions"
header. If the server supports this extension and supports
parameters compatible with the client's request, it accepts the use
of this extension in the handshake response.
Tamplin & Yoshino Expires April 23, 2012 [Page 3]
Internet-Draft A Mulplexing Extension for WebSockets October 2011
2. Interaction with other Extensions / Framing Mechanisms
Any compression extensions negotiated apply only to the channel they
are negotiated on -- therefore, any compression extension in the
initial handshake applies only to logical channel 1. If WebSocket
payload data is masked by a per-frame key, such masking is applied to
frames for each logical channel separately.
If other negotiated extensions define extension data, the other
extension defines whether it applies to just one logical channel (it
is expected that most extensions will do so) or the physical channel.
If the other extension applies to one logical channel, it always
comes after the MUX extension data; otherwise the order depends on
the order the extensions were listed during the handshake response.
Tamplin & Yoshino Expires April 23, 2012 [Page 4]
Internet-Draft A Mulplexing Extension for WebSockets October 2011
3. Channels
The MUX extension maintains separate logical channels, each of which
is fully the logical equivalent of an independent WebSocket
connection, including separate handshake headers. If the MUX
extension is successfully negotiated, the headers on the initial
handshake are automatically taken to mean channel 1, which is
implicitly opened by completing the handshake. New channels are
added by the client issuing the AddChannel command (note that only
the client may initiate new WebSocket connections), including any
request headers which do not have the same value as the initial
handshake. The server's AddChannel response likewise includes any
response headers which are different from the initial handshake (the
details of this are TBD, but a simple suggestion for a delta encoding
is given below). Channel 0 is reserved for mux control messages and
does not contain payload data from any logical channel. A client
which attempts to add a channel to an existing connection that is not
accepted by the server SHOULD attempt a new WebSocket connection.
Once the MUX extension is negotiated on a connection, all frames must
be prefixed with a channel number in the extension data field.
Control frames with a channel id 0 refer to the physical connection,
other control frames MUST be delivered on the logical channel in
order with data frames for that logical channel. Control frames
SHOULD be sent only on channel 0 where possible, though control
frames for other extensions in particular may need to apply to
individual logical channels.
A receiver MUST fail the physical connection and all open logical
channels if any of these rules are violated by the sender.
Tamplin & Yoshino Expires April 23, 2012 [Page 5]
Internet-Draft A Mulplexing Extension for WebSockets October 2011
4. Flow Control
Each logical channel, including the implicitly created channel 1, is
initially given a quota of bytes that may be transmitted in each
direction without acknowledgement. It is illegal to send more bytes
than the remaining quota, and the receiver MUST fail the logical
channel for any sender that does so. This quota is replenished via
control messages as the receiver processes the data.
The initial quota is specified with the "quota" extension parameter,
and defaults to 64k (TBD) if it is not specified. The client and
server each may specify a "quota" parameter and these are unrelated
-- each specifies how many bytes the other side may send without
acknowledgement. The quota values in the initial handshake apply to
the implicitly opened channel 1.
Tamplin & Yoshino Expires April 23, 2012 [Page 6]
Internet-Draft A Mulplexing Extension for WebSockets October 2011
5. Framing
If the extension is successfully negotiated during the handshake, all
frames have a channel id in the extension data. The channel ID is
encoded as a variable number of bytes, as follows:
0 1 2 3 4 5 6 7
+-+-------------+
|0|channel id(7)|
+-+-------------+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+---------------------------+
|1|0| channel id (14) |
+-+-+---------------------------+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-----------------------------------------+
|1|1|0| channel id (21) |
+-+-+-+-----------------------------------------+
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
+-+-+-+---------------------------------------------------------+
|1|1|1| channel id (29) |
+-+-+-+---------------------------------------------------------+
The base spec requires that a sequence of frames on the wire be a
frame with an opcode other than 0, zero or more frames with opcode 0
and the FIN bit clear, and terminated by a frame with the FIN bit set
(which may be the initial frame in the case of an unfragmented
message). The MUX extension relaxes this requirement to be for just
frames of one logical channel, and that frames of other logical
channels may be interleaved arbitrarily.
All frames with a non-zero channel id must be delivered to the
specified logical channel in the order they are received, though
fragmentation may be changed if appropriate. Control frames with a
non-zero channel id may also trigger additional processing by the MUX
extension.
Control frames with a channel id of 0 refer to the physical
connection, and may also trigger additional processing - for example,
a close frame on the physical channel will close all logical channels
as well (details TBD).
Tamplin & Yoshino Expires April 23, 2012 [Page 7]
Internet-Draft A Mulplexing Extension for WebSockets October 2011
6. Multiplex Control Frames
Data frames with a channel id of 0 are MUX control frames. Unless
another negotiated extension defines a meaning for them, any frames
on channel 0 with an opcode other than "binary" MUST trigger a
failure of the physical connection. Binary frames on channel 0 are
MUX control frames, and the payload consists of a zero or more MUX
control blocks, each defined as follows:
o a channel number encoded the same as that in the extension data
(designated as ctrl-channel)
o an opcode and data interpreted according to that opcode as
follows:
0 1 2 3 4 5 6 7
+-----+---------+
| opc | opcdata |
+-----+---------+
o zero or more bytes defined by the opcode
The opcodes defined are:
0 - AddChannel request (only from client) Create a new logical
channel as ctrl-channel, exactly as if a new connection were
received on a separate transport connection, except for the
encoding of the headers. opcdata is interpreted as follows:
3 4 5 6 7
+-+---+---+
|R|enc|len|
+---------+
R is reserved for future use, len is the number of bytes used to
represent the length of following headers minus 1, and enc is an
encoding type:
0 - uncompressed The header bytes that follow are uncompressed,
and constitute the complete set of headers that would have been
sent on a WebSocket connection request
1 - delta-encoded The header bytes that follow are delta-encoded,
where any header that is not given is assumed to have the same
value as that given on the initial request of the physical
connection. A header with an empty value means that header is
not inherited from the initial connection. (TBD: this means
Tamplin & Yoshino Expires April 23, 2012 [Page 8]
Internet-Draft A Mulplexing Extension for WebSockets October 2011
that valueless headers cannot be encoded with this scheme).
2-3 - reserved Reserved for future use
The following n bytes, where n is the value of len inside opcdata
plus 1, are an 8-32 bit length of the request header data that
follows, in network byte order. The request header data consists
of a series of lines, separated by a CR-LF pair and terminated by
an extra CR-LF pair. The first line is the full URI for the new
connection, and the remaining lines are the request headers,
encoded in UTF8 and as defined by the enc value in opcdata.
The initial quota for the new connection is 0, so the client may
not send any data for this connection until the AddChannel
response is received.
The server always responds with an AddChannel response message,
described below.
1 - AddChannel response (only from server) opcdata is defined as
follows:
3 4 5 6 7
+-----+---+
|F|enc|len|
+-----+---+
RSV is reserved for future use, F is true if this response
indicates a failure to add the requested channel, len is the of
bytes used to represent the length of following headers minus 1,
and enc is an encoding scheme defined as in the AddChannel
request.
If F is set, then the server has rejected the request to add a new
channel and this should be treated exactly the same as if a
separate connection was attempted and the handshake failed. enc is
ignored in this case, and the following n bytes, where n is the
value of len inside opcdata plus 1, are an 8-32 bit length of the
request header data that follows, in network byte order. The
request header data consists of a series of lines, separated by a
CR-LF pair and terminated by an extra CR-LF pair. These lines
should be treated as the response to an HTTP Upgrade request for
the WebSocket URI, For example:
HTTP/1.1 404 Not found
Tamplin & Yoshino Expires April 23, 2012 [Page 9]
Internet-Draft A Mulplexing Extension for WebSockets October 2011
404 message body...
If F is not set, then the server has accepted the request. The
following n bytes, where n is the value of len inside opcdata plus
1, are an 8-32 bit length of the request header data that follows,
in network byte order. The request header data consists of a
series of lines, separated by a CR-LF pair and terminated by an
extra CR-LF pair. These are encoded according to enc as defined
in the AddChannel request, and the complete set of headers after
decoding is treated exactly as if it was received in response to a
handshake on a separate connection.
2 - FlowControl opcdata is defined as follows:
3 4 5 6 7
+-----+---+
| RSV |len|
+-----+---+
RSV is reserved for future use, and len is the number of bytes in
the quota minus 1.
The following n bytes, treated as an unsigned integer in network
byte order, is added to the quota of the number of bytes the
receiver can have outstanding towards the sender of the
FlowControl message. (TBD: is it worth having some non-linear
encoding to reduce the average bits required to represent these
values?)
3-7 - reserved Reserved for future use (TBD: do we need some support
for quiescence?)
Tamplin & Yoshino Expires April 23, 2012 [Page 10]
Internet-Draft A Mulplexing Extension for WebSockets October 2011
7. Examples
_This section is non-normative._
The examples below assume the handshake has already completed and the
x-google-mux extension was negotiated.
01 06 01 "Hello" 81 04 02 "bye" 80 07 01 " world"
This is a fragmented text message of "Hello world" on channel 1
interleaved with a text message of "bye" on channel 2. Note that
the sequence of opcodes/FIN bits cannot be understood without
considering the channel id of each frame.
Tamplin & Yoshino Expires April 23, 2012 [Page 11]
Internet-Draft A Mulplexing Extension for WebSockets October 2011
8. Client Behavior
When a client is asked to make a new WebSocket connection, it MAY
choose to use an existing WebSocket connection if all of the
following are true:
o the MUX extension was successfully negotated on that connection
o the scheme portions of the URIs match exactly
o the host portions of the URIs either match exactly or resolve to
the same IP address (TBD: consider DNS rebind attacks)
o the port portions of the URIs (either explicit or implied by the
scheme) match exactly
o the connection has an availablle logical stream id
If the client chooses to reuse an existing MUXd connection, it sends
an AddChannel message as described above. If the AddChannel is
successful, WebSocket frames may be sent over that channel as normal.
If the server rejects the AddChannel, the client SHOULD attempt to
open a new physical WebSocket connection (for example, in a shared
hosting environment a server may not be prepared to multiplex
connections from different customers despite having a single IP
address for them).
Tamplin & Yoshino Expires April 23, 2012 [Page 12]
Internet-Draft A Mulplexing Extension for WebSockets October 2011
9. Buffering
There will be lots of small frames sent in this protocol
(particularly replenishing send quotas), so a sender SHOULD attempt
to aggregate MUX blocks into larger WebSocket frames. However, care
must be taken to avoid introducing excessive latency - the exact
heuristics for delaying in order to aggregate blocks is TBD.
Tamplin & Yoshino Expires April 23, 2012 [Page 13]
Internet-Draft A Mulplexing Extension for WebSockets October 2011
10. Fairness
A MUX implementation MUST ensure reasonable fairness among the
logical channels. This is accomplished in several ways:
o by restricting the send quota of a logical channel, the receiver
can make sure that sender cannot dominate its buffer space
o when sending data, the sender MUST use a fair mechanism for
selecting which logical channel's data to send in the next
WebSocket frame. Simple implementations may choose a round-robin
scheduler, while more advanced implementations may adjust priority
based on the amount or frequency of data sent by each logical
channel.
o logical channel frames that are sent SHOULD be limited in size
(such as by refragmenting) when there is contention for the
physical channel to minimize head-of-line blocking
Tamplin & Yoshino Expires April 23, 2012 [Page 14]
Internet-Draft A Mulplexing Extension for WebSockets October 2011
11. Proxies
Proxies which do not mux/demux are not affected by the presence of
this extension -- they simply process WebSocket frames as usual.
Proxies which filter or monitor WebSocket traffic will need to
understand the MUX extension in order to extract the data from
logical connections or to terminate individual logical connections
when policy is violated. Proxies which actively multiplex
connections or demultiplex them (for example, a mobile network might
have a proxy which aggregates WebSocket connections at a single cell
to conserve bandwidth to the main gateway) will require additional
configuration (perhaps including the client) that is outside the
scope of this document.
Tamplin & Yoshino Expires April 23, 2012 [Page 15]
Internet-Draft A Mulplexing Extension for WebSockets October 2011
12. Nesting
TBD: Should we allow nesting of MUX'd channels, or should we require
that an intermediary MUXing channels flatten it? The advantage of
nesting is it is conceptually cleaner and less work for an
intermediary, while the disadvantage is that flow control messages
will get amplified by nesting and the ultimate server's job is a bit
more complicated to keep a tree of channel mappings.
Tamplin & Yoshino Expires April 23, 2012 [Page 16]
Internet-Draft A Mulplexing Extension for WebSockets October 2011
13. Security Considerations
TBD
Tamplin & Yoshino Expires April 23, 2012 [Page 17]
Internet-Draft A Mulplexing Extension for WebSockets October 2011
14. Normative References
[WS] Fette, I. and A. Melnikov, "The WebSocket Protocol",
draft-ietf-hybi-thewebsocketprotocol-17 (work in progress),
September 2011, <http://tools.ietf.org/html/
draft-ietf-hybi-thewebsocketprotocol-17>.
Tamplin & Yoshino Expires April 23, 2012 [Page 18]
Internet-Draft A Mulplexing Extension for WebSockets October 2011
Authors' Addresses
John A. Tamplin
Google, Inc.
Email: jat@google.com
Takeshi Yoshino
Google, Inc.
Email: tyoshino@google.com
Tamplin & Yoshino Expires April 23, 2012 [Page 19]