通过 3G 连接的 WebSocket
我一直在使用 Socket.io、node.js 和 WebSockets，所有这些我都可以通过 wifi 连接正常工作。
然而，当我通过 3G 连接（例如在我的 iPhone 上）测试支持 WebSocket 的应用程序时，似乎回到长轮询是唯一可行的解决方案。
对于 Socket.io，连接失败并显示“WebSocket 连接无效或来源未验证”，然后返回到长轮询。
我不知道 WebSocket 是否应该在 3G 上工作 - 有没有人成功地让它们像这样工作？我尝试了多种不同的方法，但似乎都失败了，这让我觉得我正在尝试不可能的事情。
I've been playing with Socket.io, node.js and WebSockets, all of which I can get working fine over a wifi connection.
However, when I test out a WebSocket-enabled app over a 3G connection (on my iPhone, for example) then it seems like falling back to long polling is the only workable solution.
With Socket.io the connection fails with "WebSocket connection invalid or Origin not verified" before falling back to long polling.
I don't know if WebSockets are meant to work over 3G - has anyone had success getting them to work like that? I've tried a number of different methods and the all seem to fail, which makes me think that I'm attempting the impossible.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
一些移动电话运营商以设置完全损坏的透明代理而闻名，您被迫通过这些代理。这是 WebSocket 工作组从一开始就必须处理的一个真正的烦恼。该协议旨在确保在存在此类产品时它会很快失败，以便您的应用程序可以立即回退到其他方法。如果您发现需要很长时间才能检测到异常并回退，请向 IETF 的 hybi 工作组报告，以便诊断和解决问题。
同时，您可以联系您的移动电话运营商，询问他们如何在不通过损坏的透明代理的情况下访问网络，或者至少知道他们希望何时修复损坏的代理以根据规范支持 HTTP。其中一些可能会为您提供多种访问选项。
Some mobile phone operators are notoriously known for setting up utterly broken transparent proxies that you're forced to pass through. This is a real annoyance that the WebSocket working group has had to deal with since the very beginning. The protocol is designed to ensure that it will fail very quickly in presence of such products so that your application can immediately fall back to other methods. If you find that it takes a long time to detect the anomaly and fall back, please report it to the hybi working group at the IETF so that the issue can be diagnosed and addressed.
In parallel, you can contact your mobile phone operator and ask them how you can access the net without passing through their broken transparent proxies or at least to know when they expect to get their broken proxies fixed to support HTTP according to specifications. Some of them might offer you multiple access options.
正如威利·塔罗（Willy Tarreau）所说，它破坏了移动运营商使用的透明代理。我确信这也不是他们独有的（例如公司防火墙）。您可以通过使用不同的端口号（至少在移动运营商上）来解决此问题。除端口 80 之外的其他端口。使用 SSL 也可能有效，但我还没有尝试过。
然后你会遇到防火墙后面的人阻止端口 80 和 80 之外的所有内容的问题。 443.
编写您的 websockets 应用程序，以便在每次连接尝试时在端口 80 和其他端口之间切换，并让您的主机侦听这两个端口。然后你就有很好的机会连接到服务器。如果您使用 Linux 同时监听两个端口，请使用 iptables port REDIRECT。
As Willy Tarreau says, it's broken transparent proxies used by the mobile operators. I'm sure it's not exclusive to them either (corporate company firewalls for example). You can get around this by using a different port number (on the mobile operators at least). Something other than port 80. Using SSL might also work, but I have not tried it yet.
Then you will run into problems with folk behind firewalls blocking everything outside ports 80 & 443.
Write your websockets app to flip between port 80, and some other port on each connection attempt, and have your host listen on those two ports. Then you have a good chance of connecting to the server. Use iptables port REDIRECT if your using linux to listen to two ports simultaneously.
您可以使用服务器发送事件协议而不是WebSocket。
SSE 更简单，兼容 HTTP，并且可以通过代理。
You can use Server-Sent Events protocol instead of WebSockets.
SSE is a simpler, HTTP-compatible and can go through proxies.
由于某些移动网络上的 Web 套接字连接不良而出现相同的错误。解决了它们；
移动端口：将 Websocket 的服务器和客户端移至 SSL 端口（端口 443）
Ping keep -alive：每隔 X 秒从客户端向服务器发送定期“ping”消息，并等待“pong”从服务器返回。如果服务器在 Y 秒内没有返回“pong”，则重新启动客户端上的连接。
实施（1）将让你大部分成功。
Had these same errors with a bad web socket connection over certain mobile networks. Solved them by;
Moving ports: Moving over server and client for websocket over to the SSL port (port 443)
Ping keep-alive: Sending periodic "ping" messages from client to server every X seconds, and waiting for a "pong" to return from server. If server doesn't give "pong" back within Y seconds, restart the connection on client.
Implementing (1) will get you most of the way there.