Websocket Structure
Each websocket frame is split into a series of segments as follows:
Contains information pertaining to websocket attributes
If set this marks the frame as the last in a series of frames. If not set it instructs the server to continue listening for additional frames.
The next 3 bits are used to specify the use of extensions. As extensions require browser support it is unlikely we will be using these. As such they should always be set to 0.
4-bit designation of the type of data being passed. Valid codes are 0x0 through 0x2 for data types or 0x8 through 0xA representing special control frames.
- 0x0: continuation frame - this frame is a continuation of a previous message and its contents should be concatenated to the associated stream buffer
- 0x1: text - contents are text (UTF-8 encoding)
- 0x2: binary - contents are raw binary
- 0x8: close - this frame is a notification that the websocket is closing.
- 0x9: ping - this frame is a ping to an endpoint
- 0xA: pong - this frame is a pong returned to the server
The mask bit signals whether or not the frame contains a payload mask. Note that this should always be set if the frame is being sent from the client to the server.
The next 7 bits of the first payload byte hold the first segment of the payload size. This contains two special cases.
- Case One: The bits are set to 1111110 - if this is the case the following 16 bits represent the payload length
- Case Two: The bits are set to 1111111 - if this is the case the following 64 bits represent the payload length
If the masking bit was set then, following the payload length, interpret the next four bytes as a payload mask. The mask is structured such that the i'th decoded bit can be found by XORing the associated i'th encoded bit with bit i mod 4 of the mask bytes. In other words:
DECODED[i] = ENCODED[i] ^ MASK[i % 4];
Contains the actual data of a length specified by the payload length bytes.
Information taken from: https://developer.mozilla.org/en-US/docs/WebSockets/Writing_WebSocket_servers