要打开 Websocket，客户端连接到服务器上的 tcp 套接字，然后开始握手。
客户端的握手包含一个 base64 编码的密钥（Sec-WebScoket-Key）。
服务器应该以 SHA-1(key + magic_constant) 进行响应，base64 编码。magic_constant 是一个特定于协议的字符串（Sec-Websocket-Accept）。
这样做的目的是什么？我没有看到任何明显的安全原因。它不对任何一方进行身份验证。单个 SHA-1 计算对于工作量证明来说并不多。
这部分握手的目的是确保连接的双方都是真正的 WebSocket 参与者。它被设计为易于实现真正的 WebSocket 客户端和服务器，但攻击者很难欺骗 HTTP 客户端、服务器或代理伪装成 WebSocket 参与者。特别是，如果在浏览器中运行的一段恶意 JavaScript 可以打开与普通 HTTP 服务器的 WebSocket 连接，那就太糟糕了，因为一旦建立连接，JavaScript 就会完全控制通过通道发送的内容，并且可以尝试各种格式错误的超大数据，试图破坏或关闭服务器。
更新：
正如@notallama 指出的那样，创建恶意 WebSocket 客户端或仅使用 telnet 发送恶意数据很容易。不同之处在于，使用 WebSockets，攻击来自受信任的上下文（用户的浏览器和用户的网络）。浏览器从 Internet 加载不受信任的代码，但通常用于连接到未暴露于 Internet 的 HTTP 服务器和中介。作为一个极端的例子，想象一下如果浏览器可以打开原始 TCP 连接（没有强制 CORS、哈希检查等），而不是 WebSockets。现在，一段恶意的 JavaScript 可以在用户的家庭网络（或者更糟糕的是，他们的工作场所内联网）上为所欲为。
特别是，HyBi 工作组花费了大量时间来解决 HTTP 中介中的一个理论漏洞，该漏洞通过使用 WebSocket 连接来欺骗中介，使其认为他们正在与普通的 HTTP 客户端通信，从而导致缓存污染。