In more detail
A WebSocket starts as an ordinary HTTP request that asks to "upgrade" (status 101 Switching Protocols). The server proves it understood by hashing the client's Sec-WebSocket-Key with a fixed GUID (SHA-1, then Base64) and returning it as Sec-WebSocket-Accept. After that, data flows both ways in small text or binary frames with very little overhead, which suits chat, live prices, collaborative editing and games. Ping and pong frames keep the link alive. URLs begin with ws:// or, encrypted, wss://.
Why it matters
Long-lived connections need care: proxies and load balancers may close idle ones, so apps send heartbeats and must reconnect themselves. Browsers do not apply CORS to WebSockets, so the server has to check the Origin header itself or another site can open a connection with the user's cookies.
Example
The handshake from RFC 6455:
GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=