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

Question

网络套接字检测代理服务器的存在，并自动设置隧道通过代理。隧道是通过向代理服务器发出HTTP语句来建立的，代理服务器请求代理服务器打开到特定主机和端口的TCP/IP连接。一旦隧道建立，通信可以畅通无阻地通过代理。由于HTTP/S以类似的方式工作，所以SSL上的安全Web套接字可以利用相同的HTTP连接技术。1

好吧，听起来很有用！但是，在我到目前为止看到的客户机实现(Go 2，Java 3)中，我没有看到任何与代理检测相关的东西。

我是遗漏了什么，还是这些实现太年轻了？我知道WebSockets是非常新的，客户端实现可能同样年轻和不成熟。我只想知道我是不是遗漏了一些关于代理检测和处理的东西。

1

2

3

Answer 1

答案是，这些客户端根本不支持代理。-Occam

Answer 2

让我解释一下你们可能遇到的不同成功率。虽然HTML5网络套接字协议本身不知道代理服务器和防火墙，但它具有与HTTP兼容的握手功能，以便HTTPS可以与WebSockets网关或服务器共享其默认的HTTPS端口(80和443)。

WebSocket协议定义了ws://和wss://前缀，分别表示WebSocket和WebSocket安全连接。这两种方案都使用HTTP升级机制升级到Web套接字协议。有些代理服务器是无害的，可以很好地使用Web套接字；另一些代理服务器将阻止Web套接字正常工作，从而导致连接失败。在某些情况下，可能需要额外的代理服务器配置，某些代理服务器可能需要升级以支持Web套接字。

如果未加密的WebSocket流量在其WebSocket服务器的途中通过显式或透明的代理服务器，那么，无论代理服务器是否按其应有的方式运行，连接几乎肯定会在今天失败(将来，代理服务器可能会意识到WebSocket套接字)。因此，未加密的WebSocket连接只应在最简单的拓扑中使用。

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

查看它的一种方法是下载并安装Kaazing WebSocket网关--这是一种高度优化的、具有代理意识的WebSocket网关，它提供本地WebSocket支持，以及对旧浏览器的标准进行完全模拟。

Answer 3

当WebSocket协议进入现场时，通信信道已经建立。WebSocket是建立在TCP和HTTP之上的，所以您不必关心这些协议已经完成的事情，包括代理。

当建立WebSocket连接时，它总是以HTTP/TCP连接开始，该连接在WebSocket的“握手”阶段被“升级”。此时隧道已经建立，所以代理是透明的，没有必要去关心它们。