HTML and CSS Reference
Sec-WebSocket-Key: <request key>
The request includes information about the address of the client and the protocol that it supports. You can
see in this example that 13 is specified for Sec-WebSocket-Version. A request key is generated by the browser and
will be different each time a connection request is made.
In return, the server will send back a response like this:
HTTP/1.1 101 Switching Protocols
Sec-WebSocket-Accept: <response key>
The response key is generated by the server and is based on the request key that was specified. I will explain
the algorithm for this later in the chapter.
Building WebSocket Frames
Once the handshaking is complete and the protocols have been negotiated, messages can be exchanged between
the client and server. These messages are sent using the websocket protocol. Messages are always one-way; no
response is required. Of course, you can send a response but that is just another one-way message in the opposite
direction. Both endpoints are always listening for messages.
A message is sent as a frame. The frame consists of a series of bytes that indicate how the message should
be processed. The remainder of the message contains the actual data being sent, which is often referred to as the
payload. The layout of the frame is shown in Figure 13-2 .
Figure 13-2. The websocket frame
The initial portion of the frame consists of up to 14 bytes. The first two bytes will be used on all frames. The
first bit indicates if this is the final frame. A message can be transmitted in multiple frames and this bit should be
set on the last frame to signal the message is complete. The next three bits are reserved for future use. The last
half of the first byte contains an opcode that specifies what type of message this is. The values 0x3 - 0x7 and
0xB - 0xF are reserved for future control frames but the following values are currently defined:
0x0 indicates this is a continuation frame
0x1 specifies the payload contains text