Due to the too-strict filtering in Iran by its government, any proxy I've ever used has been blocked.
I used L2TP, IPSec, Shaddowsocks, V2ray (Vmess, Vless), and many VPN applications like StarVPN, X-VPN, HotspotShield and etc, but they've been blocked recently.
V2ray was working until yesterday, but today it has been blocked. I even changed the server and it's not still working.
I don't know how exactly the government blocks these protocols, but I think they are recognizable, so I'm looking for an unrecognizable proxy protocol. Do you have any suggestions?
Thanks in advance
Related
In the past, websockets were not supported by all browsers and networks.
We were required to provide fallback solutions like HTTP Long Polling.
This situation appeared to change.
At least the browsers support looks great now: https://caniuse.com/#feat=websockets
I could not find any statistics about networks blocking websockets.
Do we have any data proving that there is still a justification for websocket fallback solutions?
Last year, I had an issue using Trello at work. While the page was initially shown, some changes were not reflecting on the page. I investigated using the Chrome debugger and found out that WebSockets connection was blocked (at least for that website).
After a few exchanges with IT, and some firewall black magic on their side, the issue was resolved and now Trello works fine.
So, in a few corporate environments, some WebSockets scenarios still need a fallback IMHO.
I have recently been sharing the connection of my mobile device to my laptop, when i'm out and about, through the use of an app called netshare. It provides a https proxy I believe through which it acts as a network repeater?(not sure about this part). I can access webpages and such quite easily. However, I have realised that I cannot connect to some apps. For example, I cannot use spotify. Installing some other apps like games etc also prove to fail. I have done a bit of research and found that apparently I could only surf the web with a https proxy. However, I found this to be unambiguous. Does this mean that I can only make https requests? Or is this because of https using TCP over UDP? What are the limitations and what can I do to possibly solve it?
Thanks
Need to be able to continuously receive calls when a Chrome webpage is open. How do I do that even for users who are inside a strict enterprise network?
WebSockets? (but there's the proxy problems that doesn't know what wss:// is)
HTTP? (but will I have to poll?)
Other?
Since you included the "vLine" tag, I'll reply with some information on how our WebRTC platform will behave in an enterprise network. vline.js will use a secure WebSocket by default if the browser supports it and fall back to HTTPS long polling. As described here, the secure WebSocket may work depending on the exact proxy configuration. Feel free to test it out by using GitTogether or creating your own vLine service for testing.
My scenario is this:
I have a web-service (hosted in US) that is being accessed by our users. I have a new users from China and my web-service might get blocked by Great Firewall of China. My question is, is it possible that my web-service will use some kind of proxy or something(i don't know exactly what technology it is) that will have my service a Chinese IP Address (hoping to not get blocked) without having each users (web service consumer) to modify their browser settings of some sort?
Thanks in advance.
Technically, you could setup another server (IP) that port forwards to your service. That is a little awkward though, as you could just provide your service via that IP. There's not really a way to automatically proxy a user (that would be scary).
Also consider speed when serving to China. If your potential clientele warrants it, you may consider getting a Chinese I.P. Address & server. There are some tax issues and legal documents to sign though. I actually just went through the process with ChinaNetCloud.
The main thing to get a Chinese server is the SIR form. Here is a sales pitch from CNC... Just remember that China is HUGE and you may even want to co-locate. Even a server in Hong Kong is slow in Beijing. HK is on the other side of the Great Firewall.
Possibly look at this: firewall. https://serverfault.com/questions/147232/port-forwarding-with-multiple-ips
I'm looking into getting an openfire server started and setting up a strophe.js client to connect to it. My concern is that using http-bind might be costly in terms of performance versus making a straight on XMPP connection.
Can anyone tell me whether my concern is relevant or not? And if so, to what extend?
The alternative would be to use a flash proxy for all communication with OpenFire.
Thank you
BOSH is more verbose than normal XMPP, especially when idle. An idle BOSH connection might be about 2 HTTP requests per minute, while a normal connection can sit idle for hours or even days without sending a single packet (in theory, in practice you'll have pings and keepalives to combat NATs and broken firewalls).
But, the only real way to know is to benchmark. Depending on your use case, and what your clients are (will be) doing, the difference might be negligible, or not.
Basics:
Socket - zero overhead.
HTTP - requests even on IDLE session.
I doubt that you will have 1M users at once, but if you are aiming for it, then conection-less protocol like http will be much better, as I'm not sure that any OS can support that kind of connected socket volume.
Also, you can tie your OpenFires together, form a farm, and you'll have nice scalability there.
we used Openfire and BOSH with about 400 concurrent users in the same MUC Channel.
What we noticed is that Openfire leaks memory. We had about 1.5-2 GB of memory used and got constant out of memory exceptions.
Also the BOSH Implementation of Openfire is pretty bad. We switched then to punjab which was better but couldn't solve the openfire issue.
We're now using ejabberd with their built-in http-bind implementation and it scales pretty well. Load on the server having the ejabberd running is nearly 0.
At the moment we face the problem that our 5 webservers which we use to handle the chat load are sometimes overloaded at about 200 connected Users.
I'm trying to use websockets now but it seems that it doesn't work yet.
Maybe redirecting the http-bind not via Apache rewrite rule but directly on a loadbalancer/proxy would solve the issue but I couldn't find a way on how to do this atm.
Hope this helps.
I ended up using node.js and http://code.google.com/p/node-xmpp-bosh as I faced some difficulties to connect directly to Openfire via BOSH.
I have a production site running with node.js configured to proxy all BOSH requests and it works like a charm (around 50 concurrent users). The only downside so far: in the Openfire admin console you will not see the actual IP address of the connected clients, only the local server address will show up as Openfire get's the connection from the node.js server.