websocket - 为什么当前的 websocket 客户端实现不支持代理？

Question

A Web Socket detects the presence of a proxy server and automatically sets up a tunnel to pass through the proxy. The tunnel is established by issuing an HTTP CONNECT statement to the proxy server, which requests for the proxy server to open a TCP/IP connection to a specific host and port. Once the tunnel is set up, communication can flow unimpeded through the proxy. Since HTTP/S works in a similar fashion, secure Web Sockets over SSL can leverage the same HTTP CONNECT technique. [1]

好的，听起来很有用!但是，在我迄今为止看到的客户端实现中(Go [2]、Java [3])我没有看到任何与代理检测相关的内容。

我错过了什么还是这些实现还很年轻？我知道 WebSockets 是非常新的，客户端实现可能同样年轻和不成熟。我只想知道我是否遗漏了有关代理检测和处理的内容。

[1] http://www.kaazing.org/confluence/display/KAAZING/What+is+an+HTML+5+WebSocket

[2] http://golang.org/src/pkg/websocket/client.go

[3] http://github.com/adamac/Java-WebSocket-client/raw/master/src/com/sixfire/websocket/WebSocket.java

Answer 1

让我试着解释一下您可能遇到的不同成功率。虽然 HTML5 Web Socket 协议(protocol)本身不知道代理服务器和防火墙，但它具有与 HTTP 兼容的握手功能，因此 HTTP 服务器可以与 Web Sockets 网关或服务器共享其默认的 HTTP 和 HTTPS 端口(80 和 443)。

Web Socket 协议(protocol)定义了一个 ws://和 wss://前缀，分别表示一个 WebSocket 和一个 WebSocket 安全连接。两种方案都使用 HTTP 升级机制来升级到 Web Socket 协议(protocol)。一些代理服务器是无害的，并且可以与 Web Socket 一起正常工作；其他将阻止 Web Sockets 正常工作，导致连接失败。在某些情况下，可能需要额外的代理服务器配置，并且某些代理服务器可能需要升级以支持 Web 套接字。

如果未加密的 WebSocket 流量在到达 WebSocket 服务器的途中流经显式或透明的代理服务器，那么，无论代理服务器是否按应有的方式运行，今天的连接几乎肯定会失败(将来，代理服务器可能成为 Web Socket 感知)。因此，未加密的 WebSocket 连接应仅用于最简单的拓扑。

如果使用加密的 WebSocket 连接，则在 Web Sockets Secure 连接中使用传输层安全性 (TLS) 可确保在将浏览器配置为使用显式代理服务器时发出 HTTP CONNECT 命令。这会在 Web Sockets Secure 客户端和 WebSocket 服务器之间建立一个隧道，通过 HTTP 代理提供低级别的端到端 TCP 通信。在透明代理服务器的情况下，浏览器不知道代理服务器，因此不会发送 HTTP CONNECT。但是，由于有线流量是加密的，中间透明代理服务器可能会简单地允许加密流量通过，因此如果使用 Web Sockets Secure，WebSocket 连接成功的可能性会大得多。当然，使用加密不是免费的，但通常可以提供最高的成功率。

一种查看实际效果的方法是下载并安装 Kaazing WebSocket 网关——一个高度优化、代理感知的 WebSocket 网关，它提供原生 WebSocket 支持以及对旧浏览器标准的完整模拟。