HTML and CSS Reference
Table 3-3. Defined Opcodes
Type of Message Payload
The data type of the message is text.
The data type of the message is binary.
The client or server is sending a closing
handshake to the server or client.
The client or server sends a ping to
the server or client (see Chapter 8 for
more details on using pings and pongs).
10 (hex 0xA)
The client or server sends a pong to the
server or client (see Chapter 8 for more
details on using pings and pongs).
With four bits used for opcodes, there can be up to 16 different values. The
WebSocket Protocol defines only five opcodes, and the remaining opcodes are reserved
for future use in extensions.
The WebSocket Protocol encodes frame lengths using a variable number of bits, which
allows small messages to use a compact encoding while still allowing the protocol to carry
medium-sized and even very large messages. For messages under 126 bytes, the length is
packed into one of the first two header bytes. For lengths between 126 and 216, two extra
bytes are used. For messages larger than 126 bytes, eight bytes of length are included. The
length is encoded in the last seven bits of the second byte of the frame header. The values
126 and 127 in that field are treated as special signals that additional bytes will follow to
complete the encoded length.
Text WebSocket messages are encoded with UCS Transformation Format—8 bit, or
UTF-8. UTF-8 is a variable-length encoding for Unicode that is also backward compatible
with seven-bit ASCII. UTF-8 is also the only encoding allowed in WebSocket text
messages. Keeping the encoding to UTF-8 prevents the babel of different encodings
found in the myriad “plain text” formats and protocols from hindering interoperability.
In Listing 3-4, the deliverText function uses the buffer.toString() API from
default encoding for buffer.toString() , but is specified here for clarity.