我知道了。 事实证明，我当初采用的代码放在一个NULL字符后的握手响应报头的新行后，我没有注意到这一点。 它看起来像一个)浏览器移动所有所接收的WebSocket消息通过离开单个NULL字符在前一次的认证响应被处理的字符缓冲区，以及b)，这不是一个问题，直到-next-消息收到了。
流：
1)浏览器(Chrome和Firefox)接收握手响应与在端部的额外NULL。
2)浏览器批准握手响应。
3)浏览器发送消息(在这种情况下，“文本”的操作码，而不是它一定事项)到服务器。
4)服务器正确解码帧。
5)服务器通过已建立的会话的WebSocket将消息发送回。
6)客户抱怨具有意外延续帧。
在某些情况下，我相信我是能够操纵以抑制来自浏览器的错误消息，但仍然没有收到服务器的消息在浏览器中。
正如上面的例子，我相信，原来，服务器已发送“响应”的自动文本响应，并得到了上述消息。 我后来改变了这种以“1234”，并仍然得到了上述消息。 不过，我把它改为“123”，而不再得到了错误，但仍然没有得到在JavaScript中的消息事件。
达斯汀奥普雷亚
