WebSocket-Daten-Frames und Nachrichten

When you send data over a network, it's not just a raw stream of bits. It needs structure! Think of it like sending a letter:

• You need an envelope (the frame).
• You need a stamp (protocol headers).
• You need the actual message inside.

WebSockets use a similar concept called data framing.

A WebSocket frame is the basic unit of data transfer over a WebSocket connection. Instead of sending one big message, WebSockets break data into smaller, manageable frames.

This allows for:

• Sending parts of a message over time.
• Mixing different types of data.
• Controlling the connection itself.

Every WebSocket frame starts with a header containing crucial information. Let's look at the first byte:

• FIN bit (1 bit): Is this the final frame of a message?
• RSV bits (3 bits): Reserved bits, usually 0.
• Opcode (4 bits): What kind of data is in this frame?

These bits tell the receiver how to interpret the frame.

The Opcode is a 4-bit field that tells the receiving endpoint what type of data is contained in the frame's payload. It's like a label for the content.

Common opcodes include:

• 0x1: Text Frame
• 0x2: Binary Frame
• 0x8: Connection Close
• 0x9: Ping
• 0xA: Pong

When you send a regular string, like a chat message, it's typically sent as a Text Frame (Opcode 0x1). The payload of this frame contains UTF-8 encoded text data.

A single text message can be split across multiple frames. Only the last frame of a message will have the FIN bit set to 1.

For non-textual data, like images, audio, or custom data structures, WebSockets use Binary Frames (Opcode 0x2).

The payload in these frames is raw binary data. This makes WebSockets very flexible for different application needs, from gaming to streaming.

Besides data, WebSockets also have Control Frames to manage the connection:

• Close (0x8): Initiates or responds to a connection close.
• Ping (0x9): Sent to check if the remote endpoint is alive.
• Pong (0xA): Response to a Ping, confirming liveness.

Control frames must have their FIN bit set and cannot be fragmented.

After the first byte, the frame header includes the Payload Length, which indicates how long the actual data is. It can be 7, 16, or 63 bits long, depending on the message size.

For client-to-server messages, there's also a Masking Key (4 bytes). This key XORs with the payload to hide data from intermediaries. The server must unmask the data.

This simple Java program conceptually shows how you might interpret the first two bytes of a WebSocket frame. It simulates a frame for the text "Hello".

In reality, the payload would be unmasked and decoded.

We've explored how WebSockets package data into frames. Each frame has a header with a FIN bit, RSV bits, and a crucial Opcode.

Opcodes define the frame's purpose, whether it's for text (0x1), binary (0x2), or control (0x8, 0x9, 0xA). This framing mechanism allows for robust and flexible bidirectional communication.