Background
The W3C has developed the Websocket API proposal for HTML5, that enables web pages to perform two-way communication with a remote host. There is also a proposed IETF draft websocket protocol to transport the websocket messages.
I believe that there are significant deficiencies in the proposed websocket protocol and this paper looks at how they can be rectified.
Specification Style
Let /b_v/ be integer corresponding to the low 7 bits of/b/ (the value you would get by _and_ing /b/ with 0x7F). Multiply /length/ by 128, add /b_v/ to that result, andstore the final result in /length/. If the high-order bit of /b/ is set (i.e. if /b/ _and_ed with 0x80 returns 0x80), then return to the step abovelabeled _length_.
I challenge the reader to confirm that the client side framing and the server side framing are symmetric and implement the same data framing!
Rather than such verbose means, IETF specifications typically use the precise language of augmented Backus-Naur Form (ABNF RFC5234) to formally describe protocols in a way that is not open to confusion or mis-implementation. To illustrate the clarity possible, I’ve translated section 4.2 into BNF:
ws0-frame = sentinel-frame / length-frame
sentinel-frame = %x00-7F ; frame type *( %x00-FE ) ; utf-8 data %xFF ; the sentinel
length-frame = %x80-FF ; frame type frame-length octet-data ; binary data
frame-length = unlimited-integerunlimited-integer = *( %x80-FF ) %x00-7F ; concatenate 7 low order bits from each octet ; to form a binary integeroctet-data = *( %x00-FF ) ; the number of octets is exactly the length determined ; by the frame-length
This is a precise specification and requires only an interpretation of the frame length field to provide an implementation independent definition of websocket data framing.
Simplified Framing
Now that we can clearly see and understand websocket data framing, we can see that it really has two types of data framing: one for UTF-8 content and one for binary content. As the binary framing is perfectly able to carry the utf-8 data, then the protocol can be greatly simplified by removing the sentinel framing as follows:
ws1-frame = frame-length
frame-type
octet-data
frame-type = 0x00 ; utf8 frame
/ 0x01-FF ; undefined binary frame
frame-length = unlimited-integer
unlimited-integer = *( %x80-FF ) %x00-7F
; concatenate 7 low order bits from each octet
; to form a binary integer
octet-data = *( %x00-FF )
; the number of octets is exactly the length determined
; by the frame-length
Learn from HTTP
It is always wise to consider the past when looking to the future. HTTP/1.1 introduced pipelining as a mechanism to reduce the latency and improve the throughput when using a TCP/IP connection. The mechanism allows multiple HTTP messages to be sent on a connection, without waiting for any response or state change resulting from one message to the next. Unfortunately HTTP pipelines have several short comings that have prevented their widespread adoption and more unfortunately the websocket protocol proposal has made similar mistakes:
3>Orderly Close
So if a connection closes, a websocket application does not know which messages sent have been recieved, short of acknowledging every message (which is a significant overhead and thus not practicable as a solution for all). However, if websocket can be improved with a mechanism to orderly close connections, then the delivery status of messages can be well known for normal operation and will only be uncertain if there is a real failure of a network or node. Orderly close requires a connection life-cycle to be defined and maintained by exchanging control messages between the end points:
ws2-frame = frame-length
frame-type
octet-data
frame-type = 0x00 ; utf8 frame
/ 0x01 ; control frame
/ 0x02-FF ; undefined binary frame
frame-length = unlimited-integer
unlimited-integer = *( %x80-FF ) %x00-7F
; concatenate 7 low order bits from each octet
; to form a binary integer
octet-data = *( %x00-FF )
; the number of octets is exactly the length
; determined by the frame-length
Message Fragmentation
Another issue with HTTP/1.1 pipelining is that the time taken to transmit/receive/process one message in the pipeline can unreasonably delay the handling of subsequent messages. While websocket is not hampered in this regard by request response semantics, it still suffers from the issue that the sending of a large websocket message may unreasonably delay the transmission of other messages.
A common protocol technique to deal with this issue is to implement message fragmentation, where a single message is transmitted in several frames and the frames of unrelated messages can be interleaved on a single connection. Either a message ID or a channel (== virtual connection) ID is needed to determine which fragments are part of the same message. The following improvement adds fragmentation and a channel ID to websocket:
ws3-message = 1*(ws3-frame)
ws3-frame = frame-length
message-length
channel-id
frame-type
octet-data
frame-type = 0x00 ; control frame
/ 0x01 ; utf8 frame
/ 0x02-FF ; undefined binary frame
frame-length = 0x00 ; last frame of message
/ unlimited-integer ; frame-length
message-length = 0x00 ; unknown message length
/ unlimited-integer ; known message length
channel-id = unlimited-integer
unlimited-integer = *( %x80-FF ) %x00-7F
; concatenate 7 low order bits from each octet
&nb
sp; ; to form a binary integer
octet-data = *( %x00-FF )
; the number of octets is exactly the length determined
; by the frame-length
A message is terminated when all octets have been sent for a known message length, or when a zero length frame is sent for an unknown message length. Related messages are sent on the same channel id and are strictly ordered. The creation and orderly close of channel-ids can be coordinated by control frames sent on the channel. The implementations of the protocol end points will be responsible for fragmenting and interleaving messages. A simple endpoint may choose not to fragment messages sent, but should be capable of assembling fragmented messages received.
Multiplexing
It is frequently desirable to aggregate (aka multiplexing) message streams from multiple clients and/or components into a single stream of messages, so that resources can be shared and/or load from a single source policed as a single entity. Luckily the machinery needed for multiplexing over a transport protocol is exactly the machinery needed from message fragmentation and channels. Thus the improvements already proposed can accommodate multiplexing.
Flexibility and Extensibility
- compressed content using compress, gzip, or some future compression algorithm
- UTF-16 may be more predictable and/or efficient if messages contain significant numbers of multi-byte characters
These additional content encodings could be handled by allocating additional frame-type octets. However, such an approach would need coordination by a standards body for every new type and could rapidly consume the available octet space when the product of content encodings, transport encoding, character sets and/or content types is calculated.
Luckily there already exists a standard extensible system for describing content encodings, transport encoding, character sets and/or content types. The IETF standards for Mime Type are widely used by web protocols and have good mappings to existing software components that can encode, decode, compress, decompress, validate, sign and/or display an unlimited and growing family of media types.
Mime types and associated encodings are typically represented by 1 or more name value pairs of ISO-8859-1 strings (aka meta data). It would possible to extend websocket by replacing the fixed octect mapping of content encoding with a per message set of mime-type name value pairs. However, to do so would be to repeat another mistake of HTTP, namely to have verbose highly redundant meta-data transmitted with every message.
A more efficient and equally flexible solution is to associate meta-data fields such as mime type with a channel rather than with a message, so that the meta data need only be sent once and will apply to all subsequent messages in a channel, or until it is replaced by updated meta data:
ws5-message = 1* (ws5-frame)
ws5-frame = frame-length
message-length
channel-id
frame-type
octet-data
frame-type = 0x00 ; control frame
/ 0x01 ; meta-data name+value headers
/ 0x02 ; data frame
/ 0x03-FF ; undefined frame
frame-length = 0x00 ; last frame of message
/ unlimited-integer ; frame-length
message-length = 0x00 ; unknown message length
/ unlimited-integer ; known message length
channel-id = unlimited-integer
unlimited-integer = *( %x80-FF ) %x00-7F
; concatenate 7 low order bits from each octet
; to form a binary integer
octet-data = *( %x00-FF )
; the number of octets is exactly the length
; determined by the frame-length
An application using this transport would be free to send as little or as much meta data as appropriate. If the content types and encodings can be assumed or known in advance, then only control and data frames need be sent.
Other Websocket improvements
Semantic Specification
Another poor aspect of the websocket protocol proposal is its usage of strict ordering and binary equivalence rather than semantic equivalence when handshaking to establish a websocket connection. The specification expects implementations to send/receive exact sequences of bytes, for example:
5. Send the following bytes to the remote side (the server):
47 45 54 20
Send the /resource name/ value, encoded as US-ASCII.
Send the following bytes:
20 48 54 54 50 2F 31 2E 31 0D 0A 55 70 67 72 61
64 65 3A 20 57 65 62 53 6F 63 6B 65 74 0D 0A 43
6F 6E 6E 65 63 74 69 6F 6E 3A 20 55 70 67 72 61
64 65 0D 0A
GET /resource name/ HTTP/1.1 CRLF
Upgrade: WebSocket CRLF
Connection: Upgrade CRLF
A semantically equivalent HTTP request could have the headers order differently, an absolute URL for the resource additional headers for authentication, load balancing and/or cookies. There is no reason to reject semantically equivalent messages because a HTTP request that happens to have the correct semantics is correct. The insistence of strict binary ordering and equivalence will break many proxies, load balancers and server implementations that are used to more flexible interpretations of network specifications.
HTTP transport
This paper has highlighted several existing issues with HTTP/1.1, such as pipeline limitations and verbose redundant headers. The improved websocket protocol addresses the main limitations of HTTP while providing equivalent or superior capabilities to carry both the data and meta data needed for HTTP. It is entirely possible that with some additional minor improvements that improved websocket (or similar) could transport HTTP messages and become the basis of HTTP/2.0
BWTP IETF draft
Either approach significantly improves upon the current websocket proposal and provides a transport protocol that would truly be a step forward.
8 Comments
clara williams · 10/11/2009 at 13:35
thanks!
William · 11/11/2009 at 16:49
Nice work Greg.
I don’t think it possible to express the changes required to the WebSocket proposal more clearly.
uberVU - social comments · 23/11/2009 at 13:20
[Trackback] This post was mentioned on Twitter by f0rth: http://bit.ly/28mL7c # How to improve Websocket
William Pietri · 24/11/2009 at 02:00
Wow! Nicely put.
I’ll confess to knowing zip about WebSocket, but as a frequent reader of RFCs, I’m fully behind you on the issue of clarity. The “Learn from HTTP” section also makes great sense to me.
Thanks for taking the time for this.
Aaron Digulla · 24/11/2009 at 06:48
I just read the spec and this tripped me: “No exception is raised if the connection was once established but has subsequently been closed, however.”
This means you get an error in send() when there is no connection, yet, but none if the connection is already closed. WTF?
Timo · 01/12/2009 at 06:45
I read the websocket spec and thought it was easy to understand, although it did have a weird style.
I would otherwise agree with moving the UTF-8 part on top the binary frames, but the UTF-8 frames have a property which the binary frames lack: the sender doesn’t need to know in advance how much data it’s sending.
James Hutton · 30/12/2009 at 15:23
Your examination/improvements to websocket seam more workable than what is there, and less likely for developers waiting on an improved spec that would come out years after WS does to fix it’s problems.
Don Park · 03/01/2010 at 11:48
Great input on the websockets protocol. I read this and think yeah that should be implemented right away.
As far as BWTP, and websockets is guilty of this too to some degree, why not use XMPP? Seems that already has a lot of investment to do two-way message passing.
Comments are closed.