6 ms·

Before I ask my question, let me ask a "am i right or wrong." WebSockets is a small layer on top of HTTP. And HTTP is a protocol on top of TCP. Right or wrong?

Before I ask my question, let me ask a "am i right or wrong." 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 https://github.com/jpillora/chisel Edit: above project is also using websockets. okay, i think i understand why you would do this.

icebraining 10y ago
WebSockets is not really a layer over HTTP as such; it uses an HTTP request format to set up the connection, but then it's mostly just a raw socket (with message framing, like in UDP). Your question is still valid, I'm just dispelling the myth that WS is like TCP-over-DNS or something similarly inefficient.
- peterwwillis 10y ago
  It's almost exactly like TCP-over-DNS. Both are stateful protocols on top of stateless ones. The only difference is HTTP responses can essentially go on forever, whereas DNS ones are typically UDP with an upper bound on size, and TCP ones have a timeout on the order of seconds, and thus need to re-encapsulate further messages. 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.
  - icebraining 10y ago
    Are you talking about WS itself, or this tunnel thing? Because I was just talking about WS itself, which doesn't have any TCP over it, it's just framed data over regular TCP. Anyway, looking at the code of this tool, it doesn't seem like there's any actual TCP being tunneled; from what I can tell, the raw TCP terminates in the application, and the data is piped directly into the WS connection. That's why you have to choose a static target, whereas with a TCP tunneling system like iodine, you can use it as an open gateway. Fair enough on the raw socket, I meant a TCP socket.
    - peterwwillis 10y ago
      I kind of jumbled the two things together in that comment, but WS itself is basically a stateful UDP over HTTP, so i'll compare it to that. (TCP has too many features to be compared to WS) Comparing it to stateful UDP over DNS is a totally fair thing because in practice that is how you use it. You steal the ports of a completely different application to send data for your own different application, and do the hokey-pokey of one protocol before you then encode a payload in a completely different protocol before sending and after receiving it, and the application protocols it abuses to tunnel its data aren't even of the same state or connection mode. Saying WS is "just framed data over regular TCP" is like saying stateful UDP over DNS is "just framed data over regular UDP". The only difference is that DNS has message reply limits. If you could keep sending one long DNS response payload, WS would be virtually identical to stateful UDP over DNS (when using tcp for the DNS). And yeah you're right, this app is not encapsulating TCP packets, but it tunnels applications which use TCP. A lot of tunnels do this, although I don't think they advertise themselves as "tunneling TCP through X".
wfunction 10y ago
My understanding is it's because there's no API for dealing with raw sockets in JS. Or rather, there is, and it's called WebSockets. (Depending on how you want to look at it...)
- Buge 10y ago
  Well this thing is written in js, and needs to use raw sockets in its implementation. See "tcpSocket" and "pipe" in the code. Sure browsers don't have a js raw socket API, but no browsers are involved in this thing.
- deleted 10y ago
  [deleted]
- netgusto 10y ago
  Nope, there is actually a core API for dealing with raw sockets in NodeJS : https://nodejs.org/api/net.html#net_class_net_socket https://nodejs.org/api/net.html#net_class_net_socket Pretty straightforward to use, at that : const net = require('net'); const client = new net.Socket(); client.connect(port, host, function() { client.write("hello !"); });
  - deleted 10y ago
    [deleted]
  - wfunction 10y ago
    Interesting, thanks! So what is the benefit of WebSockets?!
    - detaro 10y ago
      In general: That you can use them from the browser. For this use case: That they are an extension of HTTP, and thus can pass modern HTTP proxies.
      - wfunction 10y ago
paulddraper 10y ago
#1 reason is browsers. They expose HTTP and Websocket abilities, but nothing beneath that. 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.
- dragonwriter 10y ago
  > #1 reason is browsers. They expose HTTP and Websocket abilities, but nothing beneath that. More specifically, web pages. Browsers usually support more protocols (FTP, for instance) but don't expose the protocols to scripts running on web pages.
tghw 10y ago
Because of the nature of HTTPS, combined with Websockets, would give you a really easy way to proxy yourself out of restrictive internet situations. Use an HTTPS connection to Google to domain front to an App Engine instance that has this running on it. Now you can TCP to anywhere from anywhere and it just looks like HTTPS traffic to Google.
- derhuerst 10y ago
  if i understand you correctly, you want to set up the tunnelling server on the App Engine instance and the client on your local machine, right? 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.
  - tghw 10y ago
    There's no need for an Origin header and the SSL cert would match. That's the whole premise of domain fronting. You send the request to whatever IP resloves as Google.com, but when you make the request, your Host header is for the AppEngine instance. Because of the way Google (and AWS and I'm sure many others) route requests, they don't care that you're using the cert for Google.com, they just happily route you to whatever Host you specify. You may have to spoof some headers to do the 101 Switching Protocol correctly, but you have all the information you need to do it.
derhuerst 10y ago
thanks for mentioning chisel!

icebraining 10y ago

WebSockets is not really a layer over HTTP as such; it uses an HTTP request format to set up the connection, but then it's mostly just a raw socket (with message framing, like in UDP). Your question is still valid, I'm just dispelling the myth that WS is like TCP-over-DNS or something similarly inefficient.

peterwwillis 10y ago
It's almost exactly like TCP-over-DNS. Both are stateful protocols on top of stateless ones. The only difference is HTTP responses can essentially go on forever, whereas DNS ones are typically UDP with an upper bound on size, and TCP ones have a timeout on the order of seconds, and thus need to re-encapsulate further messages. 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.
- icebraining 10y ago
  Are you talking about WS itself, or this tunnel thing? Because I was just talking about WS itself, which doesn't have any TCP over it, it's just framed data over regular TCP. Anyway, looking at the code of this tool, it doesn't seem like there's any actual TCP being tunneled; from what I can tell, the raw TCP terminates in the application, and the data is piped directly into the WS connection. That's why you have to choose a static target, whereas with a TCP tunneling system like iodine, you can use it as an open gateway. Fair enough on the raw socket, I meant a TCP socket.
  - peterwwillis 10y ago
    I kind of jumbled the two things together in that comment, but WS itself is basically a stateful UDP over HTTP, so i'll compare it to that. (TCP has too many features to be compared to WS) Comparing it to stateful UDP over DNS is a totally fair thing because in practice that is how you use it. You steal the ports of a completely different application to send data for your own different application, and do the hokey-pokey of one protocol before you then encode a payload in a completely different protocol before sending and after receiving it, and the application protocols it abuses to tunnel its data aren't even of the same state or connection mode. Saying WS is "just framed data over regular TCP" is like saying stateful UDP over DNS is "just framed data over regular UDP". The only difference is that DNS has message reply limits. If you could keep sending one long DNS response payload, WS would be virtually identical to stateful UDP over DNS (when using tcp for the DNS). And yeah you're right, this app is not encapsulating TCP packets, but it tunnels applications which use TCP. A lot of tunnels do this, although I don't think they advertise themselves as "tunneling TCP through X".

wfunction 10y ago

My understanding is it's because there's no API for dealing with raw sockets in JS. Or rather, there is, and it's called WebSockets. (Depending on how you want to look at it...)

Buge 10y ago
Well this thing is written in js, and needs to use raw sockets in its implementation. See "tcpSocket" and "pipe" in the code. Sure browsers don't have a js raw socket API, but no browsers are involved in this thing.
deleted 10y ago
[deleted]
netgusto 10y ago
Nope, there is actually a core API for dealing with raw sockets in NodeJS : https://nodejs.org/api/net.html#net_class_net_socket https://nodejs.org/api/net.html#net_class_net_socket Pretty straightforward to use, at that : const net = require('net'); const client = new net.Socket(); client.connect(port, host, function() { client.write("hello !"); });
- deleted 10y ago
  [deleted]
- wfunction 10y ago
  Interesting, thanks! So what is the benefit of WebSockets?!
  - detaro 10y ago
    In general: That you can use them from the browser. For this use case: That they are an extension of HTTP, and thus can pass modern HTTP proxies.
    - wfunction 10y ago

paulddraper 10y ago

#1 reason is browsers. They expose HTTP and Websocket abilities, but nothing beneath that. 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.

dragonwriter 10y ago
> #1 reason is browsers. They expose HTTP and Websocket abilities, but nothing beneath that. More specifically, web pages. Browsers usually support more protocols (FTP, for instance) but don't expose the protocols to scripts running on web pages.

tghw 10y ago

Because of the nature of HTTPS, combined with Websockets, would give you a really easy way to proxy yourself out of restrictive internet situations. Use an HTTPS connection to Google to domain front to an App Engine instance that has this running on it. Now you can TCP to anywhere from anywhere and it just looks like HTTPS traffic to Google.

derhuerst 10y ago
if i understand you correctly, you want to set up the tunnelling server on the App Engine instance and the client on your local machine, right? 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.
- tghw 10y ago
  There's no need for an Origin header and the SSL cert would match. That's the whole premise of domain fronting. You send the request to whatever IP resloves as Google.com, but when you make the request, your Host header is for the AppEngine instance. Because of the way Google (and AWS and I'm sure many others) route requests, they don't care that you're using the cert for Google.com, they just happily route you to whatever Host you specify. You may have to spoof some headers to do the 101 Switching Protocol correctly, but you have all the information you need to do it.

derhuerst 10y ago

thanks for mentioning chisel!