根据以下帖子,某些网络只允许连接到端口80和443: Socket IO fails to connect within corporate networks
编辑:为了澄清,问题是当最终用户在公司防火墙后面使用浏览器时。我的服务器防火墙设置在我的控制之下。
我已经阅读过Nginx使用proxy_pass来监听另一个端口上的Socket.io(我已经读过它的缺点),还使用nodejitsu / node-http-proxy反向代理将非节点流量传递给Nginx(其中还有其他缺点)。我有兴趣考虑所有可能的选择。
经过多次搜索,我没有找到有关socket.io监听端口443的可能性的讨论,如下所示:
var io = require('socket.io').listen(443);
客户端会像这样连接:
var socket = io.connect('http://url:443/', {secure: false, port: '443'});
除了在该服务器上放弃使用https之外,还有其他任何缺点吗? (例如,企业网络是否阻止通过端口443进行非SSL通信?)
答案 0 :(得分:3)
端口443上的非加密流量可以正常工作,但是如果你想要与具有偏执和不太合适的安全策略的网络兼容,你应该假设有人已经“保护”了它们。
无论愚蠢的防火墙如何,您都应该使用SSL加密的WebSockets,因为WebSocket协议与HTTP不兼容(它伪装成这样,但这还不够)并且无法与HTTP代理可靠地协同工作。
例如,O2 UK(可能还有许多其他移动ISP)通过其代理管道所有非加密连接,以重新压缩图像和审查网站。他们的代理断开WebSocket连接,唯一的解决方法是使用SSL(除非你对Socket.IO回到jsonp轮询感到满意......)
答案 1 :(得分:2)
这实际上取决于设置的防火墙类型。如果端口刚刚被阻止,那么几乎任何东西都可以在端口80和443上运行。我自己使用它来通过80端口的防火墙工作时通过端口80获得ssh会话。
但是,有一些防火墙具有更高级的过滤选项。除了常规端口过滤之外,这些还可以基于协议过滤掉流量。我甚至遇到了服务器前面的一个防火墙,它会以某种方式阻止通过ssh隧道的https流量。到目前为止,这些先进的过滤技术是罕见的例外,因此对于大多数情况,只需要在443上进行监听就可以了。
答案 2 :(得分:1)
我认为您应该阅读有关Socket.IO和阻止端口的整个wiki文章(通过防病毒软件,防火墙等):
https://github.com/LearnBoost/socket.io/wiki/Socket.IO-and-firewall-software