Websockets握手问题答案

【问题标题】：Websockets handshake problemWebsockets握手问题
【发布时间】：2011-07-21 21:18:20
【问题描述】：

我在 Python (based in this gist) 中创建了一个 websockets 服务器，它可以在 localhost 中运行，但不能在生产服务器中运行。

例如，在 localhost 我有以下握手消息：

//Message from webbrowser client

GET / HTTP/1.1
Upgrade: WebSocket
Connection: Upgrade
Host: 127.0.0.1:8080
Origin: null
Sec-WebSocket-Key1: ]2 415       401   032v
Sec-WebSocket-Key2: 2y7   9Y2o 80049 5
Cookie: (...)

t��t`��


//Response of server

HTTP/1.1 101 Web Socket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
WebSocket-Origin: null
WebSocket-Location: ws://127.0.0.1:8080/
Sec-Websocket-Origin: null
Sec-Websocket-Location: ws://127.0.0.1:8080/

�@2�J��3@5��ƶ

当我在生产中运行同一个 webssocket 的服务器时，连接失败。在 Chrome 的控制台中，我收到以下错误：“WebSocket 握手期间出错：'Connection' 标头值不是'Upgrade'” - 但在服务器和客户端之间的握手消息中，连接（来自服务器）是正确的价值：

//Message from webbrowser client

GET / HTTP/1.0
Host: myserver.com
X-Forwarded-Host: myserver.com
X-Forwarded-Server: myserver.com
X-Forwarded-For: 189.6.133.224
Connection: close
Upgrade: WebSocket
Origin: http://myserver.com
Sec-WebSocket-Key1: 2 1)Gz 11919la 978
Sec-WebSocket-Key2: c94Q6b9^ef#`6 2v {652
Cookie: (...)


//Response of server

HTTP/1.1 101 Web Socket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
WebSocket-Origin: http://myserver.com
WebSocket-Location: ws://myserver.com/websocket/server
Sec-Websocket-Origin: http://myserver.com
Sec-Websocket-Location: ws://myserver.com/websocket/server

yz�~�r}��+�4J

在生产中，我在客户的消息中得到了一些陌生人值：

消息末尾的疯狂代码在哪里？
'Connection'标头的值是'close'？！

有人知道我为什么会收到此错误以及为什么客户端握手具有这些值吗？

【问题讨论】：

标签： python html websocket

【解决方案1】：

消息末尾的疯狂代码是什么？

客户端握手结束时的 8 个原始字节本质上是第三个键值。服务器发回的 16 个原始字节是从客户端握手中的 3 个键值生成的摘要。这就是摘要在当前 Hixie-76 版本的协议中的工作方式。在新的 IETF/HyBi 协议版本（即将在浏览器中发布）中，摘要机制不再使用特殊的原始字节。

为什么'Connection'标头的值设置为'close'？

在我看来，有一个中介（即 Web 代理或透明代理）正在修改来自客户端的握手，然后再到达服务器。不仅是 Connection 标头错误，而且客户端握手也缺少第三个键值。事实上，HyBi 版本的协议使用不同的摘要机制的原因之一是为了与中介更兼容。

建议：

如果您的客户端和服务器在同一网络上，并且您在 Chrome 中有代理设置，请尝试暂时禁用代理，看看是否有效。

如果客户端和服务器不在同一个网络上，并且您可以控制同一网络上的两台机器，请尝试在一台上运行客户端，在另一台上运行服务器（并且仍然确保您在其中没有代理设置）铬合金）。这应该消除了透明代理/中介搞乱握手的可能性。

如果您确定 Chrome 有问题，而不是中间人，您可以通过在建立连接时在客户端上运行 wireshark 来确定并检查实际数据包。如果 Chrome 确实发送了确切的握手，那么您的配置可能会触发 Chrome 错误。

【讨论】：