WebSockets is a small layer on top of HTTP. And HTTP is a protocol on top of TCP. Right or wrong?
So then why would do this? To get TCP running over port 80 to get through a firewall? Why not just do TCP over port 80?
Like this project https://github.com/jpillora/chisel
Edit: above project is also using websockets. okay, i think i understand why you would do this.
Your question is still valid, I'm just dispelling the myth that WS is like TCP-over-DNS or something similarly inefficient.
The biggest difference there is that while TCP-over-DNS just has TCP->DNS->UDP as overhead, the WS method has TCP->WS->TCP. Because the connection is stateful and the WS encapsulation is minimal, it's more efficient (and HTTP tunneling is almost always more functional than DNS or ICMP, anyway)
It's still inefficient. And it's not a raw socket, it's an application layer socket, essentially.
If, say, I wanted to connect to a (probably read-only) public database from my browser, I could not.
This isn't a surprise to anyone, of course. By most definitions, Web == HTML over HTTP.
More specifically, web pages. Browsers usually support more protocols (FTP, for instance) but don't expose the protocols to scripts running on web pages.
in this case, accessing google over HTTPS locally would not work properly, as the `Origin` header as well as the SSL cert wouldn't match.
Sure browsers don't have a js raw socket API, but no browsers are involved in this thing.
Pretty straightforward to use, at that :
const net = require('net');
const client = new net.Socket();
client.connect(port, host, function() {
client.write("hello !");
});But if this is not needed, then long-polling is perfectly sufficient for push delivery.
I don't see why? Just have N multiple outstanding requests to the server (with N being large enough to achieve whatever communication rate you can accept). When the server wants to send you something, it picks one and replies to it. While you're busy processing it the server can still reply to anther one and send more data. When you're done you send more outstanding requests to the server to reach N again.
And if you ever run out of outstanding requests, then that's equivalent to your socket not being able to accept a new connection because there are too many pending already, which can always happen.
That said...You could just use corkscrew.
https://wiki.archlinux.org/index.php/HTTP_tunneling
Corkscrew + SSH has been helping individuals escape restrictive corporate networks for years.
Pretty sure SSH for remote server on port 443 plus corkscrew offers more than this solution. (Socks proxy, etc. Very flexible. No need for DNS muckery you would need with this solutions example etc.)
And it's all about the web browser, so...
It's encrypted so firewalls shouldn't be able to tell the difference.
I would indeed find it surprising if any commercial firewalls distinguish websockets over TLS versus raw bytes over TLS. Not that it's impossible, but I wouldn't think it would be done commercially.
Sigh. Of course I develop network virtualization software so I'm just as guilty of it.
How's your buffer bloat? — Fine, how's yours? — Great, thanks for asking!
(I also run a semi-related project, without the decentralized magic of ZeroTier)
HTTPS VPNs require TLS, and some proxies don't let you use TLS, because you might tunnel with it. It's pretty easy to block most HTTP tunneling because they typically use the CONNECT method. Ones that simply do an HTTP handshake and then pass the socket to a tunneling program can be detected or simply terminated after the session has gone on for a while or transferred a certain number of bytes. BOSH connections are a little more reliable, and I don't know off the top of my head if any tunneling apps support chunked encoding/multipart/etc, but it's possible to implement a tunnel using only valid HTTP methods, but it would be inefficient. Basically, most tunnels can be defeated without negative impact to regular users because HTTP isn't supposed to be used that way.
In comes WebSockets. Since it's a part of the modern web, and disabling them would negatively affect user experiences on the web, you can abuse them to tunnel random crap and proxies can't really do anything about it. The protocol even allows for obfuscation to make it difficult to see what's going over the socket (though it was intended to prevent cache poisoning attacks).
So in theory, if you can reach a target HTTP server, WebSockets may be the most reliable method to tunnel a connection over HTTP. The fact that it also supports multiple streams may make it faster than alternatives. And the fact that you don't need to use TLS may make it even faster, assuming the app you're tunneling does its own encryption.
built on WebSockets
built on HTTP
built on TCP
This is like where newborn babies and the elderly have a lot in common.
In other words, WebSockets is a TCP protocol that mimicks HTTP during the handshake in order to be left alone by proxies and whatnot.
I was told by the developer that he uses it also to maintain hundreds of machines which don't have a public IP.
https://github.com/derhuerst/tcp-over-websockets/blob/master...
You can pass PPP or SLIP via WebSockets and connect to the Internet that way. That's already used for connecting DOSBox running in a web browser to the Internet: http://blog.vrcade.io/2017/03/setting-up-a-visp-using-pppow/