TCP Socket to Websocket?

Question

There are plenty of websocket -> socket wrappers around there (like websockify) but is there an opposite available out there? Specifically, I want to be able to connect to a TCP socket with an application, and have the proxy translate to websocket and over to another websocket server.

score 13 · Accepted Answer · answered Feb 18 '13 at 16:39

13

Bridging from WebSocket client to TCP server is a generic solution that encapsulates the lower level TCP protocol into the higher level WebSocket protocol. It allows browsers (or other websocket clients) to communicate with arbitrary TCP servers. Note that the the client (JavaScript) application must still be able to decode/encode the protocol that the TCP server speaks.

The reverse operation is not generic and would require a special framing of the messages from the TCP client application to the bridge so that the bridge would know how to encode the WebSocket messages to the TCP server. WebSockets is a message based transport while TCP is a lower-level streaming transport. The TCP transport layer does not have a concept of messages in the protocol itself so this has to be handled at a high layer. In other words, you will have to do almost as much work to enable your TCP client application to communicate with the bridge application as it would take to implementing the a WebSocket client directly in your application. Actually, it's probably less to implement directly, because there are already WebSocket client libraries available for most popular languages.

You won't be able to connect a pre-existing TCP client via the bridge to an existing WebSocket server without changing either the client and bridge (to add message boundary and opcode information) or you will need a special WebSocket server that ignores the WebSiocket message boundaries and treats the incoming data as a stream (with message parsing handled at a higher layer).

Perhaps you could give an use-case where you think this might be useful?

Disclaimer: I made websockify.

answered Feb 18 '13 at 16:39

kanaka

70,845
23
144
140

2

Well, for example, your websockify is used on a VNC server to make use of noVNC. I need to actually attach a native client to that VNC server, but only the websockified portion is exposed to the internet. So looks like I might actually have my work cut out for me.. – Morty Kirk Feb 18 '13 at 23:03
Marking this as the answer since it was most applicable at the time. Thanks for the help, kanaka. – Morty Kirk Mar 06 '13 at 18:59
2

@kanaka , didn't you already have to implement non-boundary data streams in websockify? The data going back from the TCP server to the browser client is, by nature, originally a data stream. – Circuit in the wall Oct 31 '14 at 15:37
I was hoping websockify would be able to do it and was disappointed to see it couldn't. Then I found this thread. In your last paragraph you have mentioned the obvious use case that has led us here --- we don't care about the websocket specific message boundaries. That said, your evaluation is wrong. It makes so much sense to have such a reverse proxy in cases where just a raw communication stream is required. – Hyena Jan 25 '21 at 11:35
1

@Hyena I'm interested to know more about your use case. If I understand, you have a server that can only speak WebSockets but treats the payload as normal TCP such that a regular TCP client could connect to it if only the data was WebSockets wrapped (and can tolerate arbitrary boundaries in cases of fragmentation)? That's a really strange use case and I'm interested in hearing more about it (both because I'm really curious about this, but also maybe if I understand the "why" I could suggest a solution). – kanaka Jan 25 '21 at 17:45
@kanaka thanks for asking. There are many situations where this would be useful but I will give you the most practical one as an example. Let's say your raw TCP server is already running behind websockify and using a 3rd party webhosting plan who provides the TLS and respective certificates. You now want to connect to your own server from a custom client, but the server only accepts WSS connections. You know that behind websockify there is a raw TCP server. Why implement your own encryption if you could just utilize the WSS that is already provided by hosting provider? – Hyena Jan 27 '21 at 08:38
@Hyena Okay. So what you want is essentially tunneling TCP within WebSockets. I haven't touched websockets/websockify stuff much in the past year. But the websockify basic functionality isn't that complicated (and there is no additional framing). For example, the JS version is only a couple of hundred lines (a good chunk of which is logging and argument processing): https://github.com/novnc/websockify-js/blob/master/websockify/websockify.js Flipping it around probably wouldn't be too big of a task. – kanaka Jan 29 '21 at 20:59
1

@Hyena agreed, it is not very complicated if you're OK with just simple tunnelling. An implementation is here: https://github.com/jimparis/unwebsockify/ – Jim Paris Aug 20 '21 at 16:33
Here's another solution (not tested personally): https://github.com/simonwalz/websocket-tcp-bridge – bitinerant Apr 29 '23 at 18:33

score 6 · Answer 2 · answered Dec 16 '15 at 16:43

I am not sure what u were looking for but in case that helps someone in the future I will write what I did to solve my problem.

My problem: I wanted to be able to host noVNC on my web application's server and I wanted non websocket vnc servers to be able to understand it without using websockify.

My solution: I used ws-tcp-bridge node.js module to bridge the websocket port<--lport> where the noVNC client would connect to with the vnc tcp server's host.

Example: This happens by running the following command from the vncserver's machine:

ws-tcp-bridge --method=ws2tcp --lport=5555 --rhost=127.0.0.1:5902

That way I was able to host a non websocket vncserver at port 5902 and connect with it via noVNC at port 5555.

Haven't tested this very much but works very well with x11vnc vnc server.

score 0 · Answer 3 · answered Feb 18 '13 at 08:45

I'm not entirely clear on what you're asking, but the WebSocket API applies mainly to the client side.

How you code the server-side script and what language you use to do so is entirely up to you. When coding your server-side script, you should be able to choose whether to use a TCP socket or not, etc.

Jim Paris · Answer 4 · 2021-08-26T14:59:04.893

Here is a basic implementation of such a proxy that I wrote: https://github.com/jimparis/unwebsockify/

As @kanaka described, going to TCP to Websockets is not a generic operation, but this will work if you're just looking to send a plain byte stream to a server that expects that.

From the README:

Unwebsockify is a TCP to WebSocket proxy/bridge. It accepts a plain TCP connection and connects to a WebSocket server, effectively adding WS support to a client that does not natively support it. It is essentially the opposite of websockify.

And an example of where it's useful:

Eclipse Mosquitto supports WebSockets on the server side, but not on the client side (for bridging). To bridge two MQTT instances via websockets, run unwebsockify on the client:

venv/bin/python unwebsockify.py --port 13232 --subproto mqtt wss://server/

and configure and run the MQTT client instance with e.g.

address 127.0.0.1:13232

You might want to indicate that you own or manage the project. — randomuser5215, Aug 24 '21 at 10:02

TCP Socket to Websocket?

4 Answers4

Linked