Skip to main content

1. Introduction

The WebSocket Protocol enables full-duplex communication between a client and a server over a single TCP connection. The protocol consists of an opening handshake followed by basic message framing, layered over TCP.

The goal of this specification is to provide a mechanism for browser-based applications that need bidirectional communication with servers that does not rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or <iframe>s and long polling).

1.1 Background​

Historically, creating web applications that require bidirectional communication between a client and a server (e.g., instant messaging and gaming applications) has required an abuse of HTTP to poll the server for updates while sending upstream notifications as distinct HTTP calls.

This results in a variety of problems:

  • The server is forced to use a number of different underlying TCP connections for each client: one for sending information to the client and a new one for each incoming message
  • The wire protocol has high overhead, with each client-to-server message having an HTTP header
  • The client-side script is forced to maintain a mapping from the outgoing connections to the incoming connection to track replies

A simpler solution would be to use a single TCP connection for traffic in both directions. This is what the WebSocket Protocol provides. Combined with the WebSocket API, it provides an alternative to HTTP polling for two-way communication from a web page to a remote server.

1.2 Protocol Overview​

The protocol has two parts: a handshake and the data transfer.

The handshake from the client looks as follows:

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

The handshake from the server looks as follows:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat

Key points of the handshake:

  • The client request is a valid HTTP Upgrade request
  • Multiple WebSocket-specific headers are added
  • The server responds with status code 101

Once the connection is established, the client and server can send data back and forth in both directions at any time.

1.3 Design Philosophy​

The WebSocket Protocol is designed based on the following principles:

  1. Frame-based rather than stream-based protocol: A frame-based protocol allows metadata to be associated with each frame and allows the protocol to preserve message boundaries to the application layer
  2. Origin model: Uses the browser origin model to ensure security
  3. Single TCP connection: To work over HTTP ports 80 and 443
  4. Independent from HTTP: Although the handshake is interpreted by HTTP servers as an Upgrade request, the protocol itself is independent
  5. Extensibility: Supports future extensions through extension and subprotocol mechanisms

1.4 Security Model​

The WebSocket Protocol uses the origin model commonly used by web browsers. The protocol includes an origin header field that the server can use to decide whether to accept a WebSocket connection from a given origin.

Additionally:

  • TLS encrypted connections (wss://) are recommended
  • Frames from client to server must be masked
  • The protocol includes frame types, opcodes, etc., to prevent cache poisoning
Last updated on