WebSocket协议中的"258EAFA5-E914-47DA-95CA-C5AB0DC85B11"是什么意思？

Question

我不理解 "RFC 6455" 中的 "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" 的含义。 服务器为什么需要这个神奇的字符串？ WebSocket协议为什么需要这个机制？

- Hakju Oh

Answer 1

RFC文件解释了这个问题。它是一个GUID，之所以选择它，是因为它“不太可能被不理解WebSocket协议的网络端点使用”。请参见RFC 6455。

如果您对像这样的GUID格式的具体细节感兴趣，请参见RFC 4122。

- David Schwartz

---

为什么WebSocket协议需要这个机制？ - Hakju Oh

@DavidSchwartz 我认为这是服务器使用的全局唯一标识符，用于验证传入连接是否为WebSocket。 - C graphics

@DavidSchwartz：除非它确实如此。1.3是该机制的简明概述，它们不是规范。4.2.2节中同一机制的技术详细说明是规范。GUID出现在第5步的子步骤4下。 - Jesper

Answer 2

来自Quora答案:

选择魔术字符串没有任何理由。特定的魔法字符串GUID被选择是为了为WebSockets协议添加一定程度的完整性，因为该字符串是全局唯一的。

RFC(RFC 6455 - WebSocket协议)只是说：

...与以字符串形式表示的全球唯一标识符(GUID, [RFC4122])“258EAFA5-E914-47DA-95CA-C5AB0DC85B11”连接起来，这个GUID不太可能被不理解WebSocket协议的网络端点使用。

希望这回答了你的问题。

- chaudharyp

---

当然它是全局唯一的，除了可能这个网站的HTML，其中恰好包括相同的纯文本GUID。 - Rekin

Answer 3

为什么 WebSocket 协议需要这个机制？

---

1. 浏览器只需用以下代码请求 WebSocket 连接：

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

从调试器中，我们可以看到一个101 GET请求，并通过检查请求头来查看这个特定的条目:

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

这是一个唯一的哈希值，用于标识浏览器。

---

2. 服务器端接收到$client_key哈希值。只保留哈希值，使用PHP返回的值如下：

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

3. 浏览器获得响应（示例）。这是发送密钥与websocket唯一GUID 258EAFA5-E914-47DA-95CA-C5AB0DC85B11连接后的sha1值。

   Sec-WebSocket-Accept: r1Km05q03xuNRYy7mxkCRRgbh2M=

浏览器随后检查哈希是否与其自己的计算相匹配。如果匹配，则握手完成，远程服务器实际上是一个真正的websocket服务器，因此隧道被创建并保持活动状态。

---

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

- NVRM

---

为什么它被设计成这样？如果协议不将GUID连接起来，而只是简单地编码客户端密钥，会怎样呢？ - K.Miao

这是为了确保服务器是真正的WebSocket服务器。您必须向IETF https://tools.ietf.org/html/rfc6455询问他们为什么选择了这个特定的密钥和过程。绝对不可能快速记住！当浏览器收到响应“Sec-WebSocket-Accept”时，它会计算哈希值，因为它知道发送的密钥和GUID。 “Sec-WebSocket-Accept”必须匹配。 - NVRM

这是启动 http 101 切换协议 的指令，否则它将无法工作。接受密钥 + sha1 中的 guid，在 base64 中编码。这是通用的。 - NVRM

我猜这只是一种盐，即通过查找彩虹表来防止揭示原始的客户端密钥。 - Sergey Ponomarev

注意：echo.websocket.org服务不再可用 - perrocallcenter