Cybersecurity glossary
What is a WebSocket?
Learn what a WebSocket is, how the HTTP upgrade handshake creates a full-duplex channel, how WS differs from SSE and HTTP polling, and which operational basics matter before hardening.
Definition
A WebSocket is a communications protocol that provides a full-duplex, persistent channel between client and server over a single TCP connection—typically established via an HTTP Upgrade handshake and often secured as WSS over TLS.
Why WebSockets matter
HTTP’s request/response model is awkward for continuous conversation. Chat apps, multiplayer cursors, live trading boards, and collaborative editors need either wasteful polling or a channel where either side can speak at any time.
WebSockets provide that channel: after a short HTTP handshake, the connection becomes a bidirectional message pipe that stays open for minutes or hours.
How a WebSocket connection is established
Client opens a standard HTTP(S) connection
Often to a path like /ws with cookies or tokens available for authentication.
Client requests an upgrade
Headers include Upgrade: websocket, Connection: Upgrade, and a Sec-WebSocket-Key.
Server validates and accepts
It checks auth, Origin, and endpoint policy, then returns 101 Switching Protocols.
Protocol switches to WebSocket framing
Messages become frames (text/binary/control) instead of HTTP requests.
Either peer may send anytime
Full-duplex traffic continues until close frames or network failure.
Application defines message meaning
JSON commands, protobuf events, or custom schemas ride inside frames.
WebSocket vs related approaches
| Approach | Direction | Notes |
|---|---|---|
| WebSocket | Bidirectional | Upgrade handshake; custom app protocol in frames |
| SSE | Server → client | Stays on HTTP text/event-stream |
| Short polling | Client asks repeatedly | Simple but chatty and higher latency |
| Webhook | Provider → your server | Server-to-server events, not browser sockets |
Common use cases
Chat and presence
Deliver messages and online status without waiting for the next poll.
Collaborative editing
Stream cursors, ops, and awareness events with low latency.
Live dashboards
Push metrics and alerts as soon as backends observe them.
Interactive games and trading
Exchange frequent small messages where HTTP overhead hurts.
Operational basics (before security deep-dives)
Prefer WSS
Encrypt the channel so tokens and messages are not exposed on the path.
Configure proxies for Upgrade
Idle timeouts and buffering settings differ from ordinary HTTP requests.
Plan horizontal scale
Sticky sessions or a pub/sub backplane are needed when users hit different nodes.
Define heartbeats
Ping/pong or app-level keepalives detect half-open connections.
For authentication, Origin checks, per-message authorization, and abuse controls, see the dedicated WebSockets Security glossary entry—those risks are where most production incidents happen.
Practical checklist
- Use WSS on the public internet; redirect or reject cleartext WS.
- Confirm CDN/load balancer WebSocket support and idle timeout margins.
- Authenticate during the handshake; authorize again on sensitive messages.
- Design a versioned message schema with size limits.
- Add heartbeats and max connection lifetimes.
- Build a fan-out strategy (Redis, NATS, Kafka) for multi-instance deployments.
- Monitor open connections, message rates, and abnormal disconnects.
- Load-test reconnect storms after deploys or regional failovers.
The practical takeaway
A WebSocket turns an HTTP connection into a long-lived, bidirectional message channel after a 101 upgrade. It is the right tool when both client and server must push frequently with low overhead.
Treat the handshake as the door, the frame protocol as your application API, and production scale as a messaging problem—not just a single-server socket demo. Pair this primer with WebSockets Security guidance before shipping.
Related security terms
WebSockets Security
Dedicated guidance on authenticating, authorizing, and hardening WebSocket apps.
Protocol Upgrade
The HTTP mechanism commonly used to switch into the WebSocket protocol.
Server-Sent Events (SSE)
A one-way HTTP streaming alternative for server-to-client updates.
HTTP Keep-Alive
HTTP persistence that still uses request/response semantics—unlike WebSocket framing.
Reverse Proxy
Must explicitly support Upgrade headers and long-lived WebSocket connections.
Frequently asked questions
What is a WebSocket in simple terms?
It is a lasting two-way connection between browser and server so both sides can send messages anytime—ideal for chat, live collaboration, and streaming updates.
What is the difference between WS and WSS?
WS is WebSocket over cleartext TCP. WSS is WebSocket over TLS. Use WSS in production.
How does a WebSocket start?
The client sends an HTTP request with Upgrade: websocket. If the server agrees, it responds 101 Switching Protocols and both sides switch to WebSocket frames.
Is a WebSocket the same as HTTP/2 streams?
No. HTTP/2 multiplexes HTTP messages. WebSockets are a different protocol with message frames after an upgrade (browsers also have WebSocket variants over HTTP/2 in some stacks).
When should I use SSE instead?
When you only need server-to-client updates and want to stay on ordinary HTTP streaming with simpler proxy behavior.
Do load balancers support WebSockets?
Most modern ones do if configured—idle timeouts, sticky sessions (sometimes), and Upgrade forwarding must be set intentionally.
Can I send binary data?
Yes. WebSocket frames support text and binary payloads, unlike classic SSE text streams.
References
Explore authoritative guidance and frameworks related to websocket.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.