2

我遇到了这个stackoverflow 问题，然后通过这个问题阅读了这篇文章。

据我了解，加密/非加密的 websocket 连接都依赖于通过正确的标头发送的代理服务器。

来自关于未加密的 websocket 连接的文章

如果未加密的 WebSocket 流量在到达 WebSocket 服务器的途中经过透明代理，则实际上连接很可能会失败，因为在这种情况下浏览器不会发出 CONNECT 方法。当代理服务器将请求转发到 >(WebSocket) 服务器时，预计会剥离某些标头，包括连接 >标头。因此，一个表现良好的透明代理服务器将导致 WebSocket >upgrade >handshake 几乎立即失败。并非所有代理服务器都符合有关预期代理行为的 HTTP 标准。例如，某些代理服务器配置为不删除 Connection: Upgrade 标头并将其传递给 WebSocket 服务器，WebSocket 服务器反过来发送 101 Web Socket Protocol Handshake 响应。当客户端或服务器开始发送第一个 WebSocket 帧时，就会出现问题。由于该帧与代理服务器可能期望的任何内容（例如常规 HTTP 流量）不同，因此可能会发生一些异常，除非代理服务器专门配置为处理 WebSocket 流量。

在加密的 Web 套接字连接上

在透明代理服务器的情况下，浏览器不知道代理服务器，因此不发送 HTTP CONNECT 方法。但是，由于有线流量是加密的，中间透明代理服务器可能会简单地允许加密流量通过，因此如果使用 Web Sockets Secure，WebSocket 连接成功的可能性会大得多。

如果预计未加密的连接会失败，而加密的连接只有更好的成功机会，它是如何工作的？！！

我很可能把整个事情弄错了，但我很想了解这是如何工作的。

4

2 回答 2

3

在加密连接中，代理看不到 HTTP 内容，因此它们只是传递消息。但是在非加密连接中，HTTP 消息（例如标头）可能会被代理检查和更改（在某些情况下），因此在某些情况下，它们需要支持 WebSocket，因为 WebSocket 消息看起来不像 HTTP-消息（例如，没有 HTTP 标头）。

于 2012-07-03T20:10:55.090 回答
1

值得注意的是，您所引用的文章是由为一家生产旨在解决这些问题的产品的公司工作的人撰写的。因此，作者可能有动机夸大问题的严重程度。

例如，作者说：

[一个透明代理]预计会剥离某些标头，包括 Connection 标头

这不是真的。根据 RFC2616：

“透明代理”是一种不会修改超出代理身份验证和识别所需的请求或响应的代理

当然，许多代理并不完全遵循 RFC，因此使用加密连接仍然是一个好主意。

TLS 加密专门用于防止中间服务器干扰您的流量。如果中间代理服务器导致安全 WebSockets 连接出现问题，那么您可能会遇到更大的问题，因为它还可能干扰其他安全流量，例如您与网上银行之间的连接。

于 2014-03-26T12:29:40.060 回答