WebSocket 端口 80 / 443 EC2 和 Erlang 的牛仔

Question

WebSocket 端口 80 / 443 EC2 和 Erlang 的牛仔

我的生产环境是基于 EC2 实例的 CentOS 6.0，这些天我正在编写一个视频通信应用程序，我决定使用 Erlang，因为它是基于通信的应用程序的最佳语言。

我正在使用 Cowboy 的 WebSocket 进行实时通信，我决定使用端口 80，因为它在公司网络上具有高可用性，几天前它可以正常工作，但最近它停止工作了。

当我将它切换到 80 / 443 / 21 或 22 以外的任何其他端口时，它就像魅力一样工作，但不适用于这些标准端口，我禁用了所有防火墙并允许来自亚马逊安全组的所有类型的流量，但没有任何效果对我来说。

但是这个问题只发生在 WebSocket 上，我安装并使用了 apache，它在端口 80 上工作正常，我尝试的另一件事是我在端口 80 上安装了 haproxy 列表，并在不同的端口上设置了 WebSocket 请求的转发在这种情况下，端口是 8088，我注意到我在套接字服务器上收到了请求，但是一旦收到它就会自动断开连接。

请帮忙。

Answer 1

我把我的想法作为答案而不是写一系列的 cmets，所以主要思想会更加清晰和扎实。

最初的假设是在您和您的服务器之间存在一些“透明代理”（如果您在工作，可能在 ISP 或公司的网闸上）。这里的“透明”一词意味着它甚至无需询问您即可拦截您的网络流量。通常，ISP 使用这种透明代理来缓存客户端的流量，因此使用较少的网络带宽。您可以在 google 上搜索关键字“squid transparent proxy”了解更多技术细节。

现在，如果代理配置不正确，它只会破坏 WebSockets 协议，因此您的应用程序无法按预期工作。这里的关键时刻是这是一个HTTP代理，所以它只拦截与HTTP协议相关的流量（默认为80端口），不拦截其他端口的流量, - 这就是您的应用程序在其他端口上运行良好的原因。

不幸的是，除了使用不同的端口之外，没有可靠的方法来解决这个问题。

就个人而言，我建议您只使用 TLS/SSL 连接。 WebSockets 确实支持 TLS（因为 WS 在 HTTP/HTTPS 中工作）。透明代理通常不配置为拦截 TLS 流量：您写道，您的应用程序通过端口 443 工作正常，因此这意味着该端口上没有透明代理。如果您不想（或不能）使用 TLS 连接（用于 websockets 的 wss://），您可以使用未加密连接的应用程序，但仅使用端口 443 - 这在应用程序架构的意义上是不正确的，但在你的情况下它是可以接受的并且可能是安全的。

更新

关于 8080 等替代 HTTP 端口，如果有一个透明代理拦截端口 80 上的流量，那么这些人很有可能也想拦截 8080 或 81 或 8081 等替代 HTTP 端口。因此，即使应用程序通过 8080 运行正常，也无法保证它明天会继续运行，因此如果发生这种情况，您将需要再次更改端口。

在我看来，让它通过 TLS 工作（因此默认情况下它将通过端口 443 工作）是最正确的想法。或者，如果您不能引入 TLS，只需使其通过 443 工作而无需加密（按原样） - 同样，此选项实际上并不正确，但它可以工作并且几乎不会被代理破坏。