要打开Websocket，客户端连接到服务器上的tcp socket，然后开始握手。
客户端握手包含一个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连接，而不是WebSockets(没有强制CORS，哈希检查等)。现在，恶意的JavaScript片段可以在用户的家庭网络(或者更糟的是，他们的工作场所内部网)上做任何事情。
特别是，HyBi工作组花了大量的时间来解决HTTP中介体中的一个理论上的漏洞，该漏洞可以通过使用WebSocket连接来欺骗中介体，使其认为他们正在与正常的HTTP客户端对话，从而导致缓存污染。