What does "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" means in WebSocket Protocol

Question

I don't understand the meaning of "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" in RFC 6455. Why does the server need this magic string? And why does the WebSocket protocol need this mechanism?

Answer 1

The RFC explains it. It is a GUID, selected because it is "unlikely to be used by network endpoints that do not understand the WebSocket Protocol". See RFC 6455.

If you're interested in the specifics of the format for GUIDs like that, see RFC 4122.

Answer 2

From the Quora answer:

There is no reason for choosing the magic string. The particular magic string GUID was chosen to add some level of integrity to the WebSockets protocol, because the string is globally unique.

The RFC (RFC 6455 - The WebSocket Protocol) only says:

...concatenate this with the Globally Unique Identifier (GUID, [RFC4122]) "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" in string form, which is unlikely to be used by network endpoints that do not understand the WebSocket Protocol.

Hope that answers your question.

Answer 3

Why does the WebSocket protocol need this mechanism?

---

1. A WebSocket connection is asked by a browser, simply with the code below

new WebSocket("wss://echo.websocket.org")

From the debugger we can see a 101 GET, and by inspecting the request header, we can see this particular entry:

Sec-WebSocket-Key: qcq+klmT4W41IrmG3/fseA==

This is a unique hash, identifying the browser.

---

2. On the server side the $client_key hash is received. Only the hash value is kept. The return value looks like this using PHP:

"Sec-WebSocket-Accept: " . base64_encode(sha1( $client_key . "258EAFA5-E914-47DA-95CA-C5AB0DC85B11",true))

3. The browser gets back the response, (example). This is the SHA1 of the sent key concatenated with the 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 WebSocket unique GUID.

Sec-WebSocket-Accept: r1Km05q03xuNRYy7mxkCRRgbh2M=

The browser then checks if the hash matches his own calculation, done under the hood. If so, the handshake is complete (the remote server is actually a real WebSocket server) and hence the tunnel has been created and kept alive.

---

https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers